Temporal graph modeling is the representation of entities, relationships, states, and events with explicit time semantics so a graph can reconstruct what was true, when it became true, when it ceased to be true, and when the system learned or corrected each fact. Bitemporal modeling adds both valid time and record time, enabling point-in-time analysis and decision replay.
Identify which facts need temporal graph modeling #
Not every attribute deserves a temporal history. Begin with the decisions and audits that require reconstruction. Relationships such as employment, ownership, entitlement, supply, coverage, and policy applicability almost always need validity windows. Prices, limits, risk ratings, certifications, and operational states may also require history when they affect decisions.
Classify each fact type as static, slowly changing, event-derived, interval-based, or high-frequency state. This classification drives storage, ingestion, and query design. A legal identifier may be effectively static; a role assignment has a start and end; a sensor reading is an event stream; a policy threshold is a versioned object.
Stage 1 artifact. Build a temporal semantics register listing the fact type, valid-time rule, record-time requirement, expected correction pattern, retention period, authoritative source, and point-in-time questions it must support.
Choose the right temporal pattern for each concept #
Use intervals for facts that remain true over a period, such as “employee assigned to role” or “supplier approved for category.” Use events for discrete occurrences, such as a payment, inspection, approval, or ownership transfer. Use versioned objects for policies, contracts, and reference definitions whose text and applicability change together.
Avoid using only a last-updated timestamp. It says when a row changed, not what period the underlying fact describes. Similarly, overwriting a relationship end date destroys what the system previously believed. A bitemporal graph preserves the original assertion, the correction, and the lineage of both.
The Context Graph Engine should normalize source-specific dates into explicit temporal semantics. Effective date, posting date, event time, ingestion time, and correction time are not interchangeable.
Model valid time and record time separately #
Valid time answers when a fact was true in the enterprise. Record time answers when the platform stored or revised that assertion. Both are needed when late-arriving data, backdated contracts, corrections, or disputed records are possible.
A useful implementation stores valid-from, valid-to, recorded-from, and recorded-to on temporal facts or edges, with open-ended intervals represented consistently. Every correction closes the prior record-time interval and creates a new version. The valid-time interval may remain the same or be corrected independently.
This pattern enables two different questions: “Who owned the account on March 31?” and “Who did the bank believe owned the account when it approved the transaction on March 31?” The difference is often the entire point of an audit.
Connect events to state transitions #
Events explain why intervals begin or end. A signed contract activates a supplier relationship; a termination event closes employment; a regulatory publication creates a new policy version; an incident changes an asset state. Store the event as evidence and link it to the state transition it caused.
This design improves reasoning. The Decision Layer can distinguish a planned future state from a confirmed event, and the Context Harness can enforce policies based on effective dates rather than ingestion order. The Execution Grid can also subscribe to future-dated transitions and trigger actions when they become valid.
Checklist. Every transition should have a cause, source, actor where relevant, event time, processing time, and links to the facts it created, changed, or invalidated.
Design point-in-time queries and temporal SLOs #
Write the temporal queries before finalizing the schema. Typical patterns include current-as-of, historical-as-of, known-as-of, overlap, sequence, duration, and change-between. Test them at realistic traversal depth through policy enforcement, not only in isolated database benchmarks.
Materialized current views may be useful for speed, but they must be derived from the temporal source of truth. Caches should expose their freshness and record-time cutoff. A consumer must know whether “current” means source event time, ingestion time, or last completed reconciliation.
Operationally, define SLOs for event lag, correction processing, historical replay, and interval consistency. Temporal modeling fails when history exists but cannot be queried reliably under production load.
Three industry examples #
Insurance. Coverage, beneficiaries, limits, and policy wording all change over time. A claim decision may need the policy version and coverage relationships valid on the loss date, not those current today.
Workforce. Role assignments, reporting lines, skills, certifications, and location eligibility have validity periods. Staffing and compliance decisions require the employee situation as of the assignment date.
Supply chain. Approved suppliers, component substitutions, route availability, and contractual commitments change asynchronously. A product-risk analysis must reconstruct the dependency graph for the relevant production window.
Query pattern framework #
| Query pattern | Question answered | Temporal predicate | Typical use |
|---|---|---|---|
| Current as of | What is true at time T? | valid_from ≤ T < valid_to | operational situation assembly |
| Known as of | What did the system know at time R? | recorded_from ≤ R < recorded_to | decision audit |
| Bitemporal replay | What was believed about time T at record time R? | valid and record predicates together | regulatory reconstruction |
| Overlap | Which relationships intersect a period? | interval overlap | coverage and exposure analysis |
| Sequence | What happened before or after event E? | ordered event traversal | incident investigation |
| Change between | What changed from T1 to T2? | version or edge diff | monitoring and notification |
A realistic enterprise scenario #
A multinational insurer investigates a disputed claim filed in July for a loss that occurred in March. The current policy graph shows a lower coverage limit because the contract was amended in May. A current-state system would incorrectly apply the May terms. In the temporal graph, the coverage edge and policy version valid on the March loss date remain available. Record time shows that a backdated endorsement was received in April and corrected in June. The Decision Layer reconstructs both the business truth and what the claims team knew when it made the initial decision. The Context Harness applies the policy rules effective at each stage, and the Execution Grid routes the case for review because the correction changed the evidence basis. The complete replay is possible because the engine preserved validity, record history, events, and lineage rather than overwriting the current record.
Common mistakes to avoid #
- Using a single updated_at field as a substitute for valid and record time.
- Overwriting corrected facts, which destroys the evidence needed for decision replay.
- Timestamping every attribute without defining what each timestamp means.
- Storing events without linking them to the states and relationships they changed.
- Building historical storage but no tested point-in-time query patterns or production SLOs.
- Treating time zones, inclusive boundaries, and open intervals inconsistently across domains.
How OpenKnowra approaches this #
OpenKnowra implements temporal modeling inside the Context Graph Engine as bitemporal, lineage-complete facts and relationships. Source events and corrections are normalized into explicit valid and record time, while policy versions and state transitions remain first-class objects in the Enterprise Digital Twin. The Context Harness evaluates the policy and permissions applicable to the reconstructed moment, the Decision Layer consumes point-in-time situations, and the Execution Grid records outcomes as new temporal evidence. The design principles remain vendor-neutral: preserve business truth, preserve system knowledge, and make both queryable.