I'm looking at things from a model-based and system (not only software) development perspective. Why am I saying this?
- model based: we developed a configuration management model that is applied to all artifacts (CIs) that are results of process activities - no matter what the nature; be it a document, a drawing, a product structure node etc.
all these artifacts are results of value added efforts of a core process (e.g. development process) and should therefore be traceable, especially because they directly relate to the overall result of the core process (e.g. a product).
The model provides all requirements, attributes, relations and functions that are applied to CIs (e.g. versioning, UID, change control etc.)
- system development: sure, SCM systems have special features and, finally, usually are author-group-specific authoring / team data management tools (TDM = data that can be shared between multiple persons/roles and provides configuration management capabilities).
However, for systems development, you usually have different TDMs, depending on the disciplines involved: DOORS (RM), Windchill (CAD interface / product structure, drawings), Integrity (software/RM), ... that all together must considered as a configuration management system (or, as we like to call it: Configuration Management Infrastructure)
Having said that, and to come back to the question on what should be considered a CI, it is logical to me to consider any artifact that contributes to traceability of core process activies to be a CI.
Yes, even meeting minutes or mails, if they contain important decisions. (They should usually end up as an attachment of a change request, of course.)