How can traces, metrics, logs, changes, and services share stable identity?

Scope

Use this contract when joining observability signals with catalogs, CMDB records, deployments, changes, incidents, owners, and cloud inventory. It establishes shared identity pivots. It does not require one physical database or one ontology technology.

Why it happens

Operational systems identify objects for their own purpose. Tracing knows resource attributes, a metrics backend has label sets, logs contain free-form service names, CI has repository and deployment IDs, and the CMDB has configuration-item records. A join on payments looks obvious until several environments, regions, clusters, or generations use that label.

Teams then promote a correlation key into identity. A trace ID correlates operations; an IP address can be reused; a pod UID identifies an ephemeral instance; a display name can change. Each can help a query while denoting a different kind of thing.

Diagnosis

Select one service and follow it through a rename, deployment, scale event, and incident. Inventory every source-native key and its scope. Ask:

• Does the key identify a logical service, deployment, instance, process, request, or record?
• Is it unique within tenant, namespace, region, and environment?
• Can it be reused after deletion?
• Is it immutable, or merely observed as stable?
• Which authority created it and for what lifecycle?
• How are aliases, splits, merges, and uncertain mappings represented?

A join that cannot answer these questions needs an explicit mapping record rather than a hidden string-normalization rule.

Solution

Define canonical entity types first: logical service, deployable, deployment, runtime instance, resource, change, incident, and request. Assign or adopt stable IDs within declared scopes. Keep source-native IDs and create mapping entities with method, evidence, valid time, confidence/status, and reviewer.

Separate immutable identifying fields from mutable description such as owner, version, region, and health. Never overwrite history when an entity changes. Correlation events—trace participation, log emission, metric observation, deployment, and incident involvement—connect identities without merging them.

Validate mappings continuously. Conflicting strong sources should create a review case, not last-write-wins truth.

Artifact

The cross-signal identity contract contains:

Field	Meaning
Canonical entity type/ID	Governed subject and stable identifier
Identity scope	Tenant, namespace, environment, provider, and lifecycle
Source system/record	Authority, native type, native key, and record version
Mapping relation	Exact, alias, derived, candidate, supersedes, split, or merge
Mapping evidence	Rule, provenance, reviewer, confidence/status, and limitation
Valid/record time	When relation held and when it was recorded
Mutable attributes	Owner, version, region, state, and their source/time
Correlation IDs	Trace, request, session, deployment run, change, and incident—not identity aliases
Lifecycle	Created, active, renamed, replaced, merged, retired, and deleted
Conflict/repair	Competing mappings, decision owner, correction, and downstream invalidation

Common mistakes

• Joining by display name without tenant, environment, or time.
• Treating a request correlation ID as an entity identifier.
• Overwriting a renamed or replaced entity and losing history.
• Discarding source-native keys after canonical mapping.
• Hiding probabilistic identity resolution behind a Boolean match.