How should I model incidents, changes, deployments, and dependencies over time?

Scope

Use this schema for operational knowledge graphs, CMDBs, catalogs, and investigation systems that must answer historical questions about incidents, changes, deployments, and dependencies. It focuses on semantics; implementation may be relational, event-sourced, graph-based, or hybrid.

Why it happens

Inventory systems store current state because it is efficient for dashboards. When an incident occurs, investigators query today’s owner, dependency, and deployment graph and assume it describes the event. Later corrections silently rewrite what the agent appeared to know.

Time is also reduced to one timestamp. A deployment started, progressed, paused, completed, and rolled back. A dependency existed only for one traffic cohort. A change was approved earlier than it was committed and observed later. One timestamp cannot preserve these meanings.

Diagnosis

Take a historical incident and ask the system twice:

1. What was operationally true during the impact interval?
2. What evidence had been recorded and was available to the investigator at that time?

Different answers are expected. If the model cannot express them, later knowledge can leak into incident replay and causal claims.

Review each timestamp field and name its clock, source, precision, timezone, and semantic role: proposed, approved, started, committed, observed, valid from, valid to, recorded, corrected, or invalidated.

Solution

Keep durable entity identity separate from state assertions. Model a dependency as a versioned assertion or observation with subject, object, relation type, valid interval, record interval, source, discovery method, confidence/status, and evidence. Do the same for ownership and configuration state.

Represent changes as proposals and commits; deployments as activities with target, artifact version, stages, and outcomes; incidents as impact and coordination records with observed intervals. Link them through provenance and identity without collapsing temporal proximity into causality.

Support as-of queries along both axes. Corrections append a new record and close the prior record-time interval; they do not erase the historical view used by an earlier decision.

Artifact

Use this relation shape:

assertion_id: rel-...
subject: {type: service, id: svc-17}
predicate: depends_on
object: {type: service, id: svc-42}
valid_time: {from: 2026-08-25T09:00Z, to: 2026-08-25T11:30Z, precision: minute}
record_time: {from: 2026-08-25T09:04Z, to: 2026-08-26T02:10Z}
source: {system: trace-derived-topology, record: ..., observed_at: ...}
method: observed_requests
status: supported
confidence: {value: 0.82, meaning: mapping-policy-v3}
superseded_by: rel-...
limitations: [sampling, only-us-east-traffic]

Use analogous typed records for change, deployment, incident, and observation events rather than one generic event table with opaque payloads.

Common mistakes

• Overwriting current topology and using it for historical RCA.
• Naming every timestamp created_at or event_time.
• Treating approval, commit, rollout, observation, and impact as one change time.
• Storing confidence without its method or interpretation.
• Using a later correction during replay without labeling hindsight.