17. Knowledge Graph Layer

17.1 The Living Graph #

The framework’s knowledge graph differs from conventional enterprise knowledge graphs in one decisive respect: its edges are predominantly machine-derived from observed event relationships rather than hand-authored from documented intent.

The distinction is practical. Conventional enterprise knowledge graphs are curated: a modelling team declares entity types, relationship types, and instances, typically sourced from master data systems. This produces a graph that is authoritative about structure and stale about behaviour. It knows that customers place orders; it does not know that this customer’s orders have been correlated with quality complaints for six weeks.

The living graph inverts the ratio. A curated ontology provides the type system and the invariant structural relationships. The Correlation Engine supplies the overwhelming majority of edges — dynamic, scored, expiring assertions about observed relationships.

17.2 Graph Schema #

flowchart LR
    subgraph CORE["Core Entity Types — curated"]
        direction TB
        PARTY(("Party<br/><i>customer, supplier,<br/>employee, counterparty</i>"))
        ASSET(("Asset<br/><i>account, device, vehicle,<br/>facility, product</i>"))
        LOCATION(("Location<br/><i>site, region, jurisdiction</i>"))
        PROCESS(("Process<br/><i>order, claim, case,<br/>shipment, treatment</i>"))
    end

    subgraph EVENT["Event Layer — derived"]
        direction TB
        EV(("Event<br/><i>canonical event<br/>reference</i>"))
        CORR(("Correlation<br/><i>scored relationship</i>"))
        INS(("Insight<br/><i>Insight Object</i>"))
    end

    subgraph SEM["Semantic Layer — curated"]
        direction TB
        CONCEPT(("Concept<br/><i>business term,<br/>metric definition</i>"))
        POLICY(("Policy<br/><i>rule, obligation,<br/>purpose</i>"))
    end

    PARTY -->|"OWNS / CONTROLS"| ASSET
    PARTY -->|"LOCATED_AT"| LOCATION
    PARTY -->|"PARTICIPATES_IN"| PROCESS
    ASSET -->|"DEPLOYED_AT"| LOCATION
    PROCESS -->|"INVOLVES"| ASSET
    PARTY -->|"RELATED_TO<br/><i>group, household,<br/>beneficial owner</i>"| PARTY

    EV -->|"CONCERNS"| PARTY
    EV -->|"CONCERNS"| ASSET
    EV -->|"PART_OF"| PROCESS

    CORR -->|"RELATES<br/><i>confidence, type,<br/>validity</i>"| EV
    CORR -->|"IMPLICATES"| PARTY
    CORR -->|"SUPERSEDES"| CORR

    INS -->|"DERIVED_FROM"| CORR
    INS -->|"ABOUT"| PARTY
    INS -->|"RECOMMENDS"| PROCESS

    CONCEPT -->|"DEFINES"| EV
    POLICY -->|"GOVERNS"| CORR
    POLICY -->|"CONSTRAINS"| INS

    classDef curated fill:#183028,stroke:#4caf7d,stroke-width:2px,color:#e6fff2
    classDef derived fill:#0a5570,stroke:#3fd0f0,stroke-width:2px,color:#ffffff
    classDef sem fill:#3a2540,stroke:#a878c0,stroke-width:1.5px,color:#f6eaff
    class CORE,PARTY,ASSET,LOCATION,PROCESS curated
    class EVENT,EV,CORR,INS derived
    class SEM,CONCEPT,POLICY sem

Figure 25. Enterprise knowledge graph schema fragment. Four curated core entity types provide the structural skeleton. The derived event layer — events, correlations, and insights — supplies the dynamic, high-volume majority of the graph. A curated semantic layer binds business concepts and policies to the derived content, which is what enables policy to govern correlation formation rather than only correlation access.

Note that Correlation is itself a node type, not merely an edge. This is a deliberate modelling decision: a correlation has properties (confidence, modality, evidence set, validity, provenance), participates in relationships (supersedes, is governed by), and has a lifecycle. Representing it as a reified node rather than as an edge property makes these first-class and queryable, at the cost of increased graph size and traversal depth.

17.3 What the Graph Enables #

17.3.1 Multi-Hop Reasoning #

The graph’s principal contribution is efficient traversal to depth. Questions that are expensive or impossible in relational form become natural:

• Which customers are within two hops of any entity subject to a sanctions correlation?
• What is the shortest correlation path between this equipment failure and any supplier change?
• Which entities form a community whose members share device correlations but no declared relationship? — the canonical fraud-ring query.
• Which insights depend, transitively, on a correlation that has just been retracted? — the impact-analysis query, essential for the revision protocol.

The last of these is worth emphasizing. When a correlation is retracted, the framework must notify every consumer whose insight depended on it. Computing that transitive dependency set is a graph traversal. In a relational store it is a recursive join over the lineage tables; in a graph it is a single traversal. This is not a marginal performance difference at depth.

17.3.2 Graph-Native Analytics #

Table 31. Graph-native analytics and their correlation applications. Link prediction is architecturally notable because it runs in the opposite direction to the rest of the system: the graph proposes relationships that the Correlation Engine then attempts to verify against evidence, creating a hypothesis-generation loop.

17.4 Edge Lifecycle and Expiry #

The graph’s most operationally demanding property is that edges expire.

A conventional knowledge graph accumulates edges monotonically. A living graph derived from correlations must not, for two reasons: correlations have temporal validity, and stale edges actively mislead. An edge asserting that two entities are behaviourally correlated, based on evidence from eighteen months ago, is worse than absent — it will be traversed and trusted.

The framework specifies:

Table 32. Edge lifecycle mechanisms. Archival rather than deletion is required for audit: an auditor must be able to reconstruct the graph state at the moment a historical decision was made, which is impossible if expired edges are removed.

17.5 Technology Selection #

Table 33. Graph technology selection considerations. Legend: ✔ strong, ◐ moderate, ✘ weak. No single option dominates, which motivates the hybrid topology below.

17.5.1 Recommended Hybrid Topology #

The framework recommends a two-tier graph:

Hot tier — property graph. Recent, high-confidence, currently-valid edges for entities under active consideration. Sized for sub-second traversal at depth three to four. Typically the trailing 30–90 days plus curated structural edges. This is where interactive queries, insight generation, and real-time decisioning execute.

Cold tier — graph-on-lakehouse. Complete historical edge set, including expired and archived edges, stored in the lakehouse in an adjacency-optimized layout. Serves batch graph analytics (W3), retrospective audit, and re-correlation. Queried with distributed graph processing rather than interactive traversal.

Synchronization. Edges promote to hot on creation and demote on expiry or age. The hot tier is treated as a materialized cache of the cold tier, rebuildable from it — which means hot-tier loss is a recovery inconvenience rather than data loss.

17.6 Relationship to Data Fabric Graphs #

Chapter 6 drew the distinction; it is restated here concretely because the two graphs are frequently conflated.

Table 34. Catalog graph versus living knowledge graph. Both are necessary and they are different systems. The framework retains a catalog graph in the metadata plane (Chapter 18) and a living graph in the intelligence tier. Attempting to serve both from one store degrades both.

Next: 18. Metadata and Data Lineage →