The most useful sentence I have ever heard from a finance lead was: “We have a system of record for what happened. We do not have one for why.”
Her team could tell me, with high confidence, the discounts that had been applied to every renewal in the last three years. They could not tell me, with any confidence, why a specific 20% discount on an enterprise account in Q1 had been considered acceptable. The CRM had the discount. Slack had a thread that probably referenced it. A VP’s email approved something, but it was not clear it was the same thing. The reasoning had happened across people and systems; the artifact stored only the outcome.
This is the gap that a context graph fills. Not better dashboards on the system of record for what. A separate, structured, queryable system of record for why.
2026 update: the graph is a projection, not the source
Treat the Decision Record as the source artifact for decision lineage and the context graph as its query projection. Graph edges can be re-indexed while retaining provenance. A record does not replace protected atomic run/operation/approval/budget stores or prove external provider state. Signatures and hash-chained storage are provenance/storage profiles, not mandatory fields or self-authentication in the base record.
In practice, that means every graph edge should point back to the record, tool transcript, policy decision, approval event, or evidence snapshot that created it. If a node cannot answer “which trace_id wrote me?”, it is analysis data, not decision lineage.
Rules are not the problem
Most enterprises codify rules — “discounts above 10% require finance approval.” The real business runs on how rules were applied in specific cases: “we used policy v3.2, granted a service-impact exception, based on a precedent set last quarter for a similar account.” The rules describe a space; the decisions describe what actually happened in that space.
What agent systems need access to is the second one. Prior exceptions and their justifications. Who approved what, under which policy version. The cross-system evidence that made an exception reasonable. Precedents that explain earlier decisions, alongside the current written policy. An old exception is evidence for review, not a new grant or permission to bypass current approval, authority, independent prohibitions or escalation. None of that lives in the system of record. Most of it does not live in any system at all.
The reason I think this is now solvable is that agent systems sit in the execution path. Unlike a warehouse, which sees an after-the-fact ETL of state, an agent runtime sees the full context at commit time: the inputs, the policy evaluation, the exceptions invoked, the approvals collected, the writes performed. Capture what the runtime actually observed, including partial and unknown effects; do not infer provider commitment from a locally persisted decision. The narrative examples and timing/percentage figures below are anecdotes, not independently verified ContextOS deployment benchmarks.
The Decision Record as a contract
ContextOS treats every consequential action as a structured decision event, recorded to a typed DecisionRecord. The record carries the inputs (evidence references), the policy bundles and rules evaluated, any conflicts and how they resolved, approvals (human or automated), the actions and their side effects, write-commit metadata, and outcome hooks for later feedback.
A condensed local graph projection for a renewal-discount decision follows. It omits required fields from the full canonical DecisionRecord and uses an abbreviated illustrative digest; it is not a schema-valid complete record or a stored approval binding. Resolve the complete record and current independently verified action/approval facts before use:
{
"record_id": "dr_2026_04_18_a17",
"decision_key": "revops.renewal.execute",
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
"subject_ids": ["account:acme-co", "renewal:acme-2026q1"],
"evidence_refs": [
"kg:incident:sev1#snapshot_kg_2026_04_17",
"tool:itsm.lookup:tc_201",
"tool:crm.lookup:tc_203"
],
"policy_decisions": [
{ "policy_decision_id": "pol_5510", "rule_ids": ["R_RENEWAL_DISCOUNT_CAP"] },
{ "policy_decision_id": "pol_5511", "rule_ids": ["R_SERVICE_IMPACT_EXCEPTION"] }
],
"approvals": [
{
"gate_id": "GATE_FINANCE_APPROVAL",
"approver": "user_finance_lead_44",
"approval_mode_effective": "destructive",
"evidence_snapshot_hash": "sha256:b2a1...",
"decided_at": "2026-04-18T12:03:10Z"
}
],
"outputs": { "discount": 0.20, "currency": "USD" },
"lineage": { "pack_version": "ctxpack.revops@4.1.0", "snapshot_version": "kg_2026_04_17" }
}Structured evidence, policy and approval references make the projection inspectable. The canonical record can also carry an optional rationale; prose and structured fields both need provenance rather than being treated as inherently factual. A hash binds bytes, not the accuracy of a statement or current authority to reuse it.
A selected tamper-evident storage profile can chain entries and verify them against independently trusted checkpoints/keys. A chain alone cannot detect an attacker rewriting the whole unanchored history. Declare storage verification and typed failure behavior; this article does not claim the typed reference deploys that service or exports a universal tamper_detected result. (The replay machinery itself is its own topic — see Replay Is the Real Audit Log.)
From records to a queryable graph
The records are the ground truth. The graph is the query surface — a projection that joins records by their entities, evidence, policies, approvals, and outcomes.
Typical nodes are the things you’d expect: Account, Renewal, Ticket, Incident, PolicyVersion, Approval, AgentRun, EvidenceArtifact, Exception, Commit. Edges carry the kind of relationship — USED_EVIDENCE, APPLIED_POLICY, INVOKED_EXCEPTION, APPROVED_BY, BASED_ON_PRECEDENT, WROTE_STATE_TO, RESULTED_IN — and the metadata you need to reason across time: event time, valid time, provenance, policy version references, redaction labels, access constraints.
Time is the load-bearing column. Most existing systems store current state and lose the picture of what the world looked like when a decision was made. A precedent without a snapshot of the world it lived in is not a precedent; it is an anecdote. The graph carries the snapshot reference on every edge so that a query like “show me decisions made under POLICY_RETURNS_V4 in February, with evidence drawn from the KG snapshot before the March migration” is a real query, not a research project.
Capture lineage before it is lost
An ETL pipeline cannot reconstruct evidence, effective policy, approval scope or provider outcomes that its producers never captured. A warehouse can preserve and query those artifacts when the producing systems emit them with adequate provenance. The requirement concerns the captured information and trust boundary, not the database category.
Capture proposed intent durably before dispatch, then record owned attempts, observed effects and later reconciliation facts. Preserve actual event/valid time and immutable source pins. Unknown acknowledgements remain unknown; neither a graph edge nor an audit event makes the provider transaction atomic with local persistence.
Four APIs that earn their keep
These are logical application operations to design, not claims of exported ContextOS functions or deployed services. Bind their current authorization, actual data recipients and retention before implementation.
EmitDecisionRecord persists lineage from the canonical loop. Durable intent must precede dispatch; actual completion requires provider evidence and protected state updates. If a provider commits while record persistence fails, preserve/recover the operation as uncertain rather than claiming nothing happened or issuing a fresh effect. Audit storage and provider transactions are not automatically atomic.
QueryPrecedent is what makes the graph valuable to agents themselves. Given a candidate decision and constraints, the API returns similar prior cases scoped by tenant and intent — including the approval patterns, the evidence types relied on, and the eventual outcomes. Agents may use eligible history as data. Recheck current owner/tenant/audience/ancestor scope, purpose, subject access and actual model/reviewer processors; an old approval cannot authorize a changed action. Require current exact stored approval with entitled quorum when mandated, and keep all independent controls conjunctive.
ReplayDecision lets a trace_id be reconstructed from pinned inputs: the evidence pack as-of decision time, the policy versions in effect, the approvals and exception path, the exact write set committed. Audit replay uses recorded transcripts without reissuing side effects. Deterministic compiler/policy artifacts can match exactly; model-dependent stages use declared property, scorecard or tolerance checks. A pinned packet is not current dispatch authority. Current owned fenced resume rechecks authority/approval, active boundary/data controls, external preconditions and original shared capacity.
AuditDecisionLineage answers the questions the compliance org actually has. Who approved deviations from policy X last quarter? Which exceptions correlate with negative outcomes downstream? Which workflows are exception-heavy and probably need policy refactor? These are projections against the record store; they used to be multi-week investigations.
Where this lands first
The highest-leverage entry points are workflows that are exception-heavy (“it depends” is a real answer), headcount-heavy (many humans reconciling context manually), or cross-system glue (RevOps, DevOps, SecOps, Finance Ops). These exist precisely because no single system of record owns the full workflow. ContextOS can automate the role and persist the decisions that role exists to produce — turning exception handling into searchable precedent rather than tribal memory.
The finance lead I quoted at the top eventually moved her team’s renewal-discount workflow onto this pattern. The first quarter, the audit pack for a regulator request took fifteen minutes instead of four days. The second quarter, the team noticed that 40% of their service-impact exceptions clustered around two specific tickets-per-account thresholds — a finding that turned into a policy refactor and reduced exception volume by a third. The win was not the time saved on the audit. The win was that the data needed to refactor the policy had finally been written down.
Production requirements worth naming
A few things that have to be true for this to hold up.
Pinned policy bundle versions go on every record. Evidence provenance — source, adapter, hashes — has to be there too. Redaction labels and tenant-scoping live on traces, nodes, and edges. Tamper-evidence depends on the selected storage/provenance profile and independent trusted anchors. Human approvals reference protected exact stored bindings rather than status flags; their redemption needs atomic state. Graph queries, reviewers, retries and children consume original shared spent/reserved capacity. Stable provider effects need reconciliation before eligible retry; cancellation and release rollback cannot prove stop or reversal.
Collection and projection already need eligible purpose/readers/actual processors, classification and retention. Inventory source records, graph indexes, summaries, caches, memory, exports and delegated copies. Bound correction/deletion receipts to actual copies; pending, failed or externally unknown propagation remains incomplete. Append-only integrity does not justify indefinite raw personal-data retention.
For quality, I’d watch a small number of metrics. Trace integrity: record emission success rate, “no commit without record” enforcement rate, missing-evidence rate. Precedent utility: precedent hit rate, agent acceptance rate, policy-deviation explainability rate (every deviation should link to an exception and an approval). Context health: the rate at which conflicting evidence or policies stay unresolved. Runtime cost: record overhead p95, replay determinism rate.
If the dashboard does not have these on it, you do not have a context graph. You have a logging pipeline.
Graph readiness checklist
| Requirement | What to verify |
|---|---|
| Source of truth | Decision Records are append-only and graph projections can be rebuilt from them. |
| Provenance | Every node and edge links to trace_id, evidence ref, policy decision, approval, or tool transcript. |
| Time model | Event time, valid time, and snapshot version are queryable. |
| Access control | Tenant scope, redaction labels, and subject-level permissions apply to graph queries. |
| Replay | A graph answer can be traced back to a replayable run, not only a warehouse row. |
| Outcome loop | Outcomes, corrections, and later StrategyRules connect back to the decisions they changed. |
A closing thought
Agents will not become reliable through governance alone. Reliability comes from turning organizational memory — exceptions, approvals, and precedents — into durable, queryable artifacts. The executing system is well placed to capture its actual decisions and observations, while external providers remain authoritative for their own effects. Exact profiles and conformance evidence bind useful/denied fault cases and current independently verified controls to the actual workflow, release and environment; source/reference checks alone cannot establish a deployed service.
The context graph is what you get when you commit to that. It is the system of record for why we did that — and over time, the asset that lets the next decision be better than the last.