Relationships between SAF and IT management

The primary mapping rule is: one real-world subject may have several records with different purposes and identifiers. The architecture model, service catalog, CMDB, asset register, and ITSM system should neither copy nor absorb one another automatically.

Five entity classes

Class	What it contains	Authoritative question
Architectural object	The 13 SAF types and canonical relationships	What exists, why is it needed, and how is it persistently connected?
Service management	Catalog, service offering, consumer, provider, owner, SLA/SLO	What is provided, and under which conditions?
Configuration and assets	CI, configuration record, asset, contract, license	What is controlled in operations, and what is its lifecycle or cost?
Operational record	Event, request, incident, problem, change, release, deployment record	What happened or must be performed?
Management artifact	Policy, measure, runbook, knowledge article, decision, and evidence	Which rule governs the work, and what proves the outcome?

A solid line means a management definition or application of a rule. A dashed line means referential mapping between repositories or possible feedback. Color only aids orientation; numbers, labels, and line types carry the same meaning.

Identity boundaries

A CI is not a Component

A configuration item is the role of a subject in configuration management. A CI may represent a Service, System, Component, Interface, Deployment, Compute Resource, Network Segment, document, or another controlled item. A SAF Component is a logical part of one System. Therefore, the common CI → Component mapping is partial, not universal.

An asset is not a CI

An asset is managed because of its value, cost, risk, contract, license, or lifecycle. A CI is managed because the service configuration and dependencies must be controlled. One server may simultaneously be a SAF Compute Resource, a CI in a CMDB, and an asset in an accounting system. The records are linked, but each retains its own identifier.

An operational record is not an architectural object

An event, request, incident, problem, change, or release has a transactional lifecycle. These records refer to a Service and affected objects, but they do not extend the catalog of 13 types. A SAF Information Object may describe the business meaning or schema of such a record, not every instance.

Deployment and deployment activity are different concepts

A SAF Deployment is a running or planned instance of a Component in an environment and configuration. A deployment activity, pipeline run, or deployment record in ITSM/DevOps is work or evidence that creates or changes that instance. The delivery record should refer to deployment_id, not replace it.

Minimum mapping contract

A relationship between repositories should store at least:

Field	Purpose
mapping_id	Identifier of the mapping itself.
source_repository / source_id	Authoritative source and source record.
target_repository / target_id	Related repository and target record.
mapping_type	same-real-world-subject, specializes, supports, observes, or a locally defined type.
valid_from / valid_to	Validity period of the relationship.
confidence	Confirmed, assumed, or disputed correspondence.
last_verified_at / verified_by	Currency check and accountability.

This is a non-normative contract from the study. It shows the minimum information without which a matching name becomes an unmanaged assumption.

End-to-end CRM example

Architectural identifiers persist through every operational activity. INC-1042 and CHG-221 complete their lifecycles, while SVC-CUSTOMER-SUPPORT and DEP-CASE-API-PROD-RU1 continue to exist and receive new verified states.

Canonical bridges

Source	Relationship	Target	Status
Service offering	specializes terms	SAF Service	Non-normative external relationship.
Technical service	supports	SAF business Service	External service decomposition.
CI	represents managed configuration	SAF object	Mapping with its own identity.
Asset	accounts for the same real-world subject	SAF object or CI	Mapping, not a canonical core relationship.
Operational record	affects	Service or CI	Transactional external reference.
Change/release/deployment record	changes or creates	CI and SAF Deployment	Evidence of a state transition.
SLI/SLO/SLA	defines or measures a level	Service	Management artifact.