Knowledge Graph
Evidence-bound retrieval substrate for grounded reasoning.
Evidence-bound retrieval substrate with snapshot pinning, provenance on every edge, and conflict-aware traversal.
- Ontology and identity-layer references
- Source documents, databases, APIs, and event streams
- Retrieval parameters from the Context Pack
- Run Context (tenant, role, budgets)
- Evidence bundles with source IDs, hashes, traversal paths
- Snapshot + ontology version pin
- Typed conflict markers with affected requirements and resolution state
- Aggregate confidence
- IntelligenceRefs
- EvidenceBundle
- EvidenceHop
- EvidenceConflictMarker
- RetrievedEvidence
The Knowledge Graph is the Intelligence-plane profile for turning connected enterprise data into evidence the Decision plane can cite. Graph-derived evidence must trace through each retrieval hop to typed sources. Direct tool, database, or document evidence can also satisfy a Decision Spec when it carries equivalent provenance, freshness, integrity, and replay references.
Definition
A typed labeled-property graph (LPG) of canonical entities and relationships, where every edge carries an evidence_ref to the source it was derived from. Reads are policy-scoped; writes require evidence; replay is deterministic via snapshot pinning.
This describes a deployment retrieval profile. The repository’s reference compiler consumes supplied evidence/conflict candidates; it does not operate a graph database or enforce storage isolation. The Execution Contract binds current authority, data/processor routes, active boundaries and budgets independently of retrieval relevance. A source hash or high match confidence cannot authenticate its issuer or grant access.
Why it exists
Naive RAG injects unstructured passages into the prompt and lets the model decide what to trust. That is unauditable and contradicts the Decision Catalog requirement that every decision cite typed evidence. For multi-hop and relationship-heavy work, the graph profile returns evidence bundles with traversal paths, source IDs, freshness signals, and conflict markers rather than opaque chunks. The source system remains authoritative; the graph is a versioned evidence projection.
How it works
- Ingest: sources (databases, documents, APIs, events) are normalized against the Ontology.
- Resolve: entities are linked via the Identity Layer; ambiguous matches follow a configured evidence/review threshold (for example
≥ 0.92in a declared profile). A match score is not actor authentication or permission. - Index: vectors, BM25, and graph indices are kept in sync against a single snapshot version.
- Retrieve: GraphRAG expands from a seed set along permitted relationships under a hop budget, returning a typed evidence bundle.
- Replay: every retrieval is reproducible by pinning the snapshot version and the query parameters.
Graph data model
| Element | Carries |
|---|---|
| Node | entity_type, ceid, attributes, provenance, as_of |
| Edge | relationship_type, evidence_ref, confidence, direction, valid_from, valid_to |
| Snapshot | monotonic snapshot_version, ontology_version, content hash |
Invariants enforced at write time
- No edge created without
evidence_ref. - Entity merges require explicit evidence and an audit record.
- Relationship types must exist in the active ontology version.
GraphRAG retrieval
Retrieval is parameterized in the Context Pack and bound by the Run Context’s budgets:
{
"retrieval": {
"mode": "graphrag",
"seed_strategy": "intent+entity_extraction",
"max_hops": 2,
"top_k": 8,
"freshness_window": "30d",
"evidence_required": true
}
}The retrieval adapter enforces hop/query/resource limits before returning evidence; the reference compiler bounds admission into token buckets rather than traversing the graph itself. Each returned hop carries its own evidence ref, so the Critic can score each individually and the Decision Record can list them by source.
Access control model
- Reads are scoped by
tenant_id,data_classification, and the agent’s role from the Run Context. - Cross-tenant traversal is denied at the storage layer, not just the API.
- Sensitive attributes are redacted before they enter the compiled context (see Memory for write-side redaction).
Apply data.flow_policy@1 where required by Control Profiles, including collection, inference, telemetry, caches, exports and delegated reads. Bind actual destination tenant/domain, processor/residency, purpose and verified source labels. A declassification/redaction release needs its exact source/result and approved transformation evidence; relevance, semantic similarity and copied labels cannot lower classification. Govern derived indexes/caches and deletion propagation when the graph consumes corrected or deleted memory.
Conflict detection
When two edges assert contradictory facts on the same (subject, predicate), the retrieval bundle returns both plus an EvidenceConflictMarker. The marker names the conflicting evidence refs, the decision requirements they affect, and whether the conflict is unresolved or resolved.
An unresolved conflict is never silently ranked away. The Context Pack Compiler carries it into the relevant EvidenceGate, marks the compiled view insufficient, and keeps commit_allowed: false. A resolved conflict must name a resolution_ref and the selected evidence refs so replay can reconstruct both the discarded branch and the rule or accountable review that selected the winner.
{
"conflict_id": "conflict:order:ord_881:identity",
"evidence_refs": [
"kg:orders/881#snapshot_41",
"crm:orders/881#snapshot_19"
],
"requirements": ["order_lookup"],
"status": "unresolved",
"subject": "order:ord_881",
"predicate": "canonical_order_id",
"values": ["ord_881", "ord_992"]
}The graph detects and describes the disagreement; it does not grant the model authority to resolve it. Resolution belongs to a deterministic source-priority rule, a fresh authoritative read, or an accountable reviewer whose decision is itself recorded as evidence.
Deterministic replay
Every retrieval response embeds snapshot_version and ontology_version. Deterministic replay also pins query parameters, index/ranker/embedding configuration and applicable recorded observations. Model-assisted or unpinnable retrieval stages need transcript substitution or declared property comparisons rather than an invented byte-equality guarantee. New edges after the snapshot cannot silently leak into historical replay; live dispatch separately rechecks current authority and external facts.
Interfaces
Inputs
- Ontology and identity-layer references
- Source documents, databases, APIs, and event streams
- Retrieval parameters from the Context Pack
- Run Context (
tenant_id, role, budgets)
Outputs
- Evidence bundles with source IDs, hashes, traversal paths
- Snapshot + ontology version pin
- Typed conflict markers with evidence refs, affected requirements, and resolution state
- Aggregate confidence
Failure modes
- Edges written without evidence (caught at write time; rejected).
- Retrieval expansion exceeds hop budget — bundle silently truncated, hiding relevant evidence. Mitigation: emit a
truncated: trueflag the planner must handle. - Stale snapshot used in production reads after writes have advanced — mitigated by snapshot version reconciliation on every read.
- Entity-resolution false positives merge two real-world entities and corrupt downstream traversals.
- Cross-tenant leakage through a shared relationship type — mitigated by tenant-scoped traversal at the storage layer.
Operational concerns
- Snapshot pinning per environment; promotion is a deliberate step.
- Re-index cost when the ontology version advances.
- Vector index drift vs. structured edges — alerting on disagreement.
- Backfill jobs must replay against ontology versions, not against
now. - Eviction of edges past
valid_torequires audit trail.
Evaluation metrics
- Evidence coverage (fraction of decisions whose
evidence_refsresolve to live edges). - Retrieval precision/recall on golden sets per intent.
- Conflict rate, closure rate, and resolution latency by
(entity_type, relationship_type). - Unauthorized cross-tenant retrieval success rate (target zero), with denied attempts and coverage of negative tests reported separately.
- Replay determinism (identical bundle for identical inputs across snapshot pin).
Example
GraphRAG path returned for a refund-eligibility query, condensed:
{
"snapshot_version": "kg_2026_05_03_T0930",
"ontology_version": "ont.support@4.2.0",
"seed": { "ceid": "order:ord_881", "entity_type": "Order" },
"hops": [
{
"hop": 1,
"edge": "order_belongs_to_customer",
"evidence_ref": "oms:db:orders/881#row_v3",
"to": { "ceid": "customer:cus_77", "entity_type": "Customer" },
"confidence": 0.99
},
{
"hop": 2,
"edge": "customer_has_segment",
"evidence_ref": "crm:exports/segments_2026_05_01.parquet#offset_4112",
"to": { "value": "vip" },
"confidence": 0.96,
"as_of": "2026-05-01"
}
],
"conflicts": [],
"truncated": false
}Common misconceptions
- It is not the embedding store or the source of truth. Vectors are an index strategy; the graph is a versioned projection whose claims still resolve to source evidence.
- It is not a universal evidence gateway. A high-risk decision may use direct typed evidence without graph traversal, but it may not waive provenance, freshness, conflict, access, or replay controls.
- Memory has its own lifecycle. Memory is another Intelligence-plane primitive; graph projections do not replace its ownership, promotion, retention or copy-propagation controls.