Chapter 11: Decision Traces: Anatomy and LPG Patterns

Summary

Dissects the decision trace — exception logic, historical precedents, approval chains, out-of-band approvals — and shows the complete LPG node schema and edge-type vocabulary for implementing them.

Concepts Covered

This chapter covers the following 26 concepts from the learning graph:

1. Decision Trace Anatomy
2. Exception Logic
3. Historical Precedent
4. Cross-System Synthesis
5. Out-of-Band Approval
6. Approval Chain
7. Decision Justification
8. Decision Actor
9. Decision Timestamp
10. Decision Outcome
11. Linked Precedent
12. Exception Pattern
13. Policy Version Reference
14. Decision Context Capture
15. Real-Time Trace Recording
16. Trace Completeness
17. Trace Replay
18. Trace Indexing
19. Counterfactual Trace
20. Judgment Call
21. Decision Trace Node Schema
22. Decision Trace Edge Types
23. Trace-to-Entity Relationship
24. Actor Node Pattern
25. Policy Version Edge
26. Precedent Chain Pattern

Prerequisites

This chapter builds on concepts from:

• Chapter 9: What a Context Graph Is

---

Every decision, fully documented.

Welcome to Chapter 11! We defined the context graph in Chapter 9. Now we go deep into its most important element: the decision trace. This chapter is the implementation guide — you will leave with a complete LPG schema you can actually deploy. Let's trace the why!

Introduction

The decision trace is where organizational knowledge becomes computational. Everything we have discussed — knowledge graphs, metadata, lineage, provenance, process mining — exists to answer questions. The decision trace records the answers: specific organizational decisions, made by specific actors, at specific times, based on specific context, under specific policies, citing specific precedents. It is the atomic unit of organizational intelligence.

This chapter dissects the decision trace in detail. We examine each layer of content it must capture, the LPG node schema that stores it, the edge types that connect it to the rest of the context graph, and the patterns for building complete, indexable, replayable trace records. By the end, you will have a complete implementation blueprint for decision traces in any enterprise domain.

The Four Layers of a Decision Trace

A decision trace captures four distinct layers of information that together constitute the full organizational context of a decision. These four layers correspond directly to the four missing layers identified in Chapter 8 — each layer is designed to fill one of the gaps that RAG document retrieval cannot bridge.

Layer 1: Exception Logic

Exception logic is the set of rules, thresholds, and judgment calls that govern how the organization handles cases falling outside normal parameters. Most business processes have a "happy path" — the standard flow for standard cases. The happy path is usually documented. The exception paths are usually not.

When an invoice arrives for an amount 40% above the contracted maximum, someone decides what to do. When a customer requests a contract modification outside the standard amendment window, someone decides how to handle it. These decisions are not random — experienced practitioners apply informal rules: "amounts up to 50% above contract maximum are usually approved if the customer is strategic and the explanation is operational," "end-of-quarter exceptions are treated differently than mid-quarter ones." This informal rule set is exception logic.

A decision trace captures exception logic by recording: what the normal rule was (with a policy version reference), why the case was identified as an exception (the triggering condition), what exception-specific reasoning was applied (the justification text), and what the outcome was. Over hundreds of similar exception decisions, the pattern of exception logic becomes visible and queryable — an LLM can retrieve the pattern and apply it consistently rather than requiring a human expert to recall it from memory.

Exception patterns emerge when multiple decision traces share similar triggering conditions and similar outcomes. Detecting exception patterns is a graph analytics operation: cluster decision nodes by their triggering condition properties, and summarize the majority justification and outcome within each cluster. The resulting exception pattern nodes are high-value additions to the context graph — they represent crystallized organizational policy that was never formally documented.

Layer 2: Historical Precedents

Historical precedents are prior decisions that were consulted, cited, or otherwise influential in making the current decision. Precedent reasoning is how experienced practitioners apply consistency: "we handled the same situation last year this way, and it worked out, so let's apply the same reasoning here." Without explicit precedent links in the decision trace, this reasoning chain is invisible.

A linked precedent is a specific prior decision node in the context graph, connected to the current decision by a CITES edge. The precedent link carries properties: how was the precedent found (manual lookup, system recommendation, collegial consultation), how similar was the precedent's context to the current case, and whether the precedent's outcome was favorable (making it a positive precedent) or unfavorable (making it a cautionary one).

Precedent chain patterns emerge when multiple decisions each cite a common ancestor — a small set of foundational decisions that have propagated their reasoning through many subsequent decisions. These high-in-degree precedent nodes represent the most influential organizational rulings. When the policy underlying a foundational precedent changes, the impact propagates through all decisions that cited it — a traversal query can immediately identify all affected decisions.

A counterfactual trace is a special type of trace that records what would have happened if a different decision had been made. Counterfactual traces are generated retrospectively when an exception decision is later reviewed: "if we had applied the standard rule rather than the exception, the outcome would have been X." Counterfactual traces are valuable for training and for evaluating the quality of exception logic — they provide labeled examples of correct and incorrect decision paths.

Layer 3: Cross-System Synthesis

Cross-system synthesis is the combination of information from multiple systems that together provide the full context for a decision. A pricing exception decision draws on: the customer's revenue history (CRM), the current contract terms (contract management system), the account's payment history (billing system), any open escalations (support system), and the current pricing policy (policy document management). No single system has all of this information.

A decision trace records the cross-system synthesis that went into a decision by linking to the source data nodes that were consulted. Each link carries: the system of origin, the data element consulted (linked to the metadata registry), the value at the time of the decision, and the quality score and provenance annotation for that value at that time.

This cross-system synthesis record is what enables the context graph to answer: "when the pricing team made this exception decision, what did they know about the customer's payment history, and was that data current?" It is also what enables the LLM to reproduce the synthesis when a similar decision comes up in the future: retrieve not just the decision outcome but the full cross-system context that led to it.

Layer 4: Out-of-Band Approvals

Out-of-band approvals are authorizations made outside the formal approval workflow systems — via email, phone conversation, Slack message, or in-person discussion. They are extremely common in enterprise decision-making, particularly for high-stakes exceptions where decision-makers want to consult informally before committing to a formal record.

An approval chain is the full sequence of authorizations required for a decision, from the initiating actor through every required approving authority. The chain may be linear (A approves, then B countersigns, then C ratifies) or branching (either A or B may approve, then C ratifies). The approval chain defines not just who authorized the decision but the order in which authorizations were obtained — which matters for audit trails and compliance verification.

Out-of-band approvals become invisible to compliance systems unless they are explicitly captured in the decision trace. A decision trace records out-of-band approvals as approval edge nodes with: the approver's actor ID, the timestamp, the channel (email, verbal, messaging-platform, committee), and a reference to any documentary evidence (a forwarded email, a meeting summary, a recorded call). These records are the difference between "we have no evidence this was approved" and "the approval was obtained verbally by J. Smith from VP Williams on 2025-10-31 at 14:30, referenced in email thread ETH-44821."

The four layers are why context graphs beat document archives.

Here is the synthesis: a document archive captures "what we decided" in the form of output artifacts — the approval letter, the contract amendment, the exception notification. A decision trace captures "why we decided it" in the form of the four layers above: the exception logic applied, the precedents cited, the cross-system data consulted, and the full approval chain including out-of-band authorization. The "what" is useful for record-keeping. The "why" is what enables consistent, grounded AI reasoning over future decisions.

The Complete LPG Node Schema

The decision trace is represented in the LPG model as a cluster of nodes connected by typed edges. The central Decision Trace Node is the core entity; the surrounding nodes represent actors, policies, cited precedents, and source data. Before we examine the schema, here is the complete list of node types in a canonical decision trace:

Decision Trace Node (required): the central node representing the decision itself.

Required properties: - trace_id: globally unique identifier (UUID or domain-specific format) - decision_type: category label — one of: pricing_exception, approval, escalation, configuration, exception_override, policy_application, judgment_call - timestamp_created: ISO 8601 timestamp of when the trace was recorded - timestamp_decision: ISO 8601 timestamp of when the actual decision was made (may differ from recording time) - status: lifecycle state — one of: active, superseded, under_review, overturned - context_summary: natural-language description (50–200 words) written for LLM retrieval - decision_outcome: the actual outcome of the decision, recorded retrospectively when available - confidence_level: self-assessed confidence of the decision actor (high / medium / low), useful for future retrieval ranking

Optional properties: - exception_flag: boolean — was this decision an exception to the normal rule? - urgency: boolean — was this decision made under time pressure? - judgment_call_flag: boolean — was this a case where reasonable people might disagree?

Actor Node: represents a person or system that participated in the decision.

A decision actor can be: the initiating analyst who proposed the exception, the approving manager, a countersigning authority, or an automated system that triggered the decision workflow. Actor nodes are shared across all decision traces involving the same person or system — there is one actor node per person in the enterprise, not one per decision.

Actor node properties: actor_id (canonical ID from HR or service registry), actor_type (human / automated-system / committee), name, role_at_time (the actor's role when the decision was made — important because roles change over time).

Policy Version Node: represents the specific version of a governing policy that was in effect at decision time.

Policy version node properties: policy_id, version_string, effective_from, effective_to, document_reference (link to the policy document in the content management system).

Source Data Node: represents a specific piece of data consulted during the decision.

Source data node properties: data_element_id (link to the metadata registry), system_of_origin, value_at_decision_time, freshness_at_decision_time, quality_score_at_decision_time.

The Complete LPG Edge Type Vocabulary

The nodes in a decision trace are connected by a specific vocabulary of typed edges. Each edge type encodes a specific semantic relationship. Here is the complete canonical edge type vocabulary:

Edge Type	From	To	Meaning
DECIDED_BY	Decision Trace	Actor Node	This actor made or initiated the decision
APPROVED_BY	Decision Trace	Actor Node	This actor formally authorized the decision
COUNTERSIGNED_BY	Decision Trace	Actor Node	This actor provided secondary authorization
GOVERNED_BY	Decision Trace	Policy Version Node	This policy version governed the decision
APPLIES_TO	Decision Trace	Entity Node (KG)	This decision applies to this business entity
CONSULTED	Decision Trace	Source Data Node	This data was consulted in making the decision
CITES	Decision Trace	Prior Decision Trace	This prior decision was cited as a precedent
SUPERSEDED_BY	Decision Trace	Later Decision Trace	This decision has been replaced by a later one
OVERTURNED_BY	Decision Trace	Later Decision Trace	This decision was found incorrect and reversed
TRIGGERED_BY	Decision Trace	Event Node	This external event triggered the decision process
RESULTED_IN	Decision Trace	Outcome Node	This decision produced this documented outcome

The CITES edge is the most analytically valuable: it is the edge that builds the precedent citation network. The GOVERNS_BY edge with specific policy version nodes is what enables temporally correct policy interpretation. The APPLIES_TO edge is what makes decision traces traversable from entity nodes in the enterprise knowledge graph.

Diagram: Complete Decision Trace LPG Schema

Interactive vis-network diagram showing all node types and edge types in a fully populated decision trace, with a concrete pricing exception example

Type: graph-model sim-id: decision-trace-full-schema Library: vis-network Status: Specified

Bloom Level: Apply (L3) Bloom Verb: implement Learning Objective: Learners can implement a complete decision trace schema by identifying the required node types, property lists, and edge types for a given enterprise decision scenario.

Instructional Rationale: A fully-populated clickable schema diagram is appropriate for the Apply objective — learners see all schema elements instantiated with concrete example values, then can click each element to read the property list they would need to populate for their own implementation.

Canvas: responsive width, 600px height. White background with soft grid.

Nodes and positions: Central: "Decision: Pricing Exception DT-4482" (indigo, large ellipse, center) Left: "Initiator: J. Smith (Account Mgr)" (gold, circle) Left-upper: "Approver: M. Williams (VP Sales)" (gold, circle, slightly above J. Smith) Right: "Customer: Acme Corp" (teal, ellipse) — entity node from KG Lower-left: "Policy: Pricing Policy v3.2" (steel blue, box) Lower-right: "Precedent: DT-3891 (Q2-2024 exception)" (indigo, smaller ellipse) Lower-far-right: "Precedent: DT-2204 (Q4-2023 exception)" (indigo, smallest ellipse) Upper-right: "Source: CRM Revenue Data" (orange, diamond) — source data node Upper-far-right: "Source: Billing Payment History" (orange, diamond)

Edges (with labels and colors matching the edge type vocabulary table): - Decision ← J. Smith: label "DECIDED_BY", gray - Decision ← M. Williams: label "APPROVED_BY", gold - Decision → Customer: Acme Corp: label "APPLIES_TO", teal - Decision → Policy v3.2: label "GOVERNED_BY", steel blue - Decision → DT-3891: label "CITES", orange dashed - Decision → DT-2204: label "CITES", orange dashed - Decision → CRM Revenue Data: label "CONSULTED", orange - Decision → Billing Payment History: label "CONSULTED", orange

Click on Decision node: shows full property list with example values for all required and optional properties. Click on each Actor node: shows actor properties and the DECIDED_BY vs. APPROVED_BY distinction. Click on Policy Version node: shows policy version properties and why the specific version (not the current version) is stored. Click on each Precedent node: shows CITES edge properties (similarity score, finding method, favorability). Click on each Source Data node: shows source data properties including value_at_decision_time and quality_score_at_decision_time. Click on Customer entity node: "This node lives in the enterprise knowledge graph. The APPLIES_TO edge makes this decision discoverable from the customer entity without duplicating customer data in the decision trace."

Hover over edges: shows edge type name and a one-sentence description.

Trace Completeness, Indexing, and Replay

A decision trace that is missing required fields is not just incomplete — it is potentially misleading. An LLM retrieving a trace with a missing governed_by edge will not know which policy was in effect, and may incorrectly apply the current policy to a historical decision context. A trace with a missing approved_by edge is an unverifiable claim.

Trace completeness is a measurable property: for a given decision type, a completeness schema defines which nodes and edges are required and which are optional. The context graph write API validates new traces against the completeness schema before accepting them, returning errors that list the missing required fields. Validation at write time is far less costly than detecting incomplete traces during retrieval.

For a pricing exception decision, a minimal complete trace requires: Decision Node (with all required properties), at least one DECIDED_BY edge, at least one APPROVED_BY edge (for approved decisions), one GOVERNED_BY edge to a specific policy version, one APPLIES_TO edge to the relevant entity, and at least one CITES edge if any precedents were consulted. Decision traces that fail completeness validation are quarantined in a review queue for steward remediation before entering the live context graph.

Trace indexing is the practice of creating queryable indexes on the most frequently accessed decision trace properties. For the read path performance targets typical in enterprise AI (< 200ms context retrieval latency), the following indexes are standard: index on decision_type (for type-filtered queries), index on timestamp_decision (for recency-ranked queries), index on the APPLIES_TO entity node ID (for entity-specific decision history queries), and a full-text index on context_summary (for semantic keyword searches over decision descriptions).

For high-volume context graphs (millions of decision traces), a vector embedding of the context_summary text enables approximate nearest-neighbor search over the semantic space of decisions — finding precedents that are semantically similar to the current case without requiring exact keyword matches. This embedding-augmented retrieval is the bridge between graph traversal and semantic search, combining the precision of graph structure with the flexibility of embedding similarity.

Trace replay is the ability to reconstruct the organizational context that existed at any past point in time by replaying the sequence of decision trace events up to that point. Trace replay enables historical audit queries ("what did the decision-making system know and decide on January 15th?") and counterfactual analysis ("if the policy had been different on that date, what decisions would have been made differently?"). Replay requires that the context graph stores event-ordered, immutable decision traces — a property ensured by the append-only write path described in Chapter 7.

Real-Time Trace Recording

One of the most common implementation failures in decision trace systems is the delay between when a decision is made and when the trace is recorded. A trace recorded three days after the decision is missing the real-time context: the specific data values consulted at decision time, the urgency signals that may have influenced the judgment, the out-of-band conversations that informed the approval chain. Real-time trace recording — capturing the trace at the moment of decision — is the only reliable way to ensure completeness.

Decision context capture is the technical mechanism for real-time recording. In automated systems (AI agents, workflow automation platforms), the agent's decision state — including all context retrieved, all reasoning steps taken, and all outputs produced — is serialized and written to the context graph as a decision trace node as the final step of the action execution. No separate recording step is required because the system captures the state it is already computing.

For human-in-the-loop decisions, real-time capture requires a user interface integrated into the decision workflow. Rather than requiring humans to fill in a separate trace form after the decision, the trace is assembled from the system context (who is logged in, what entity they are reviewing, which policy version is current, which precedents the system surfaced) and the human provides only the incremental information: the decision outcome, the free-text justification, and acknowledgment of any out-of-band approvals. This design minimizes the additional burden on the decision-maker while maximizing trace completeness.

Judgment calls are decisions where reasonable practitioners might disagree — where the right answer depends on contextual factors that are difficult to fully articulate. Judgment call decision traces are particularly important to capture because they represent the tacit expertise that the organization most needs to preserve. They should be flagged with the judgment_call_flag property and given higher weight in precedent retrieval — a subsequent LLM agent or human reviewer who is facing a similarly ambiguous case should see these traces prominently.

Capture the judgment call while the context is hot.

Judgment call decision traces are most valuable when captured immediately — while the decision-maker can articulate the non-obvious factors that influenced their reasoning. Even a brief free-text note in the context_summary field ("approved despite the payment delinquency because the customer's CTO personally confirmed a restructuring is underway") is far more useful than a perfectly structured trace recorded two weeks later from an incomplete memory.

Implementing Decision Traces for a Domain

To make these patterns concrete, let's walk through the implementation of decision traces for a specific enterprise domain: invoice exception handling. An invoice exception occurs when an invoice is received for an amount, date, or supplier that differs from the purchase order terms.

The decision trace for an invoice exception has the following implementation:

Decision Type: invoice_exception

Required nodes: - Decision Trace Node with: trace_id, decision_type = invoice_exception, timestamp_decision, status, exception_flag = true, context_summary - Actor nodes: the AP specialist (initiator), the AP manager or controller (approver) - Policy Version Node: link to Accounts Payable Policy, section "Invoice Variance Tolerance," version in effect at decision time - Entity nodes: the supplier entity (from procurement graph), the purchase order entity (from ERP)

Required edges: - DECIDED_BY → AP Specialist - APPROVED_BY → Controller - APPLIES_TO → Supplier Entity - APPLIES_TO → Purchase Order Entity - GOVERNED_BY → AP Policy version - CONSULTED → Source Data Node (invoice amount, PO amount, variance percentage) - CITES → prior invoice exceptions for the same supplier (if any)

Context summary template: "Invoice INV-{id} from Supplier {name} received for ${amount}, exceeding PO-{id} by ${variance} ({pct}%). Exception approved by {controller} based on {justification_type}. Precedents cited: {list}. Outcome: payment authorized within {days} days of approval."

With this template populated from system data, the context summary is an LLM-ready narrative that an agent can use directly for reasoning about future similar exceptions.

Diagram: Precedent Chain Pattern

Interactive vis-network graph showing a precedent citation chain for invoice exceptions, with in-degree centrality visible on precedent nodes

Type: graph-model sim-id: precedent-chain-pattern Library: vis-network Status: Specified

Bloom Level: Analyze (L4) Bloom Verb: organize Learning Objective: Learners can organize a set of decision trace nodes into a precedent citation chain, identify the most influential foundational precedents by in-degree, and explain why high-in-degree nodes should be retrieved first for LLM context.

Instructional Rationale: A vis-network graph where node size reflects citation count (in-degree) is appropriate for the Analyze objective — learners must examine the citation structure to identify influential precedents, which is the same analytical task an LLM retrieval system performs.

Canvas: responsive width, 520px height. White background.

Nodes (7 decision traces, representing a chain of invoice exceptions over 18 months): - "DT-1001 Q1-2024" (small, gray, ellipse) — oldest, foundational - "DT-1580 Q2-2024" (medium, indigo) — cites DT-1001 - "DT-2204 Q4-2024" (large, indigo) — cites DT-1001, DT-1580 — high in-degree - "DT-2891 Q1-2025" (medium, indigo) — cites DT-2204 - "DT-3105 Q2-2025" (small, indigo) — cites DT-2204 - "DT-3891 Q3-2025" (medium, indigo) — cites DT-2204, DT-2891 - "DT-4482 Q4-2025" (small, indigo, latest) — cites DT-2204, DT-3891

Node sizes scale with in-degree: DT-2204 is largest (cited by 4 others), DT-1001 is next (cited by 2 others).

CITES edges (orange, dashed): drawn as directed arrows from citing to cited node.

Toggle button "Show In-Degree Labels": displays in-degree count above each node (DT-2204: in-degree 4, DT-1001: in-degree 2, others: in-degree 0 or 1).

Toggle button "Highlight Top Precedents": colors nodes with in-degree ≥ 2 in bright indigo with a gold outline — the "should retrieve first" set.

Click any node: shows infobox with decision type, date, brief context summary, and "cited-by" count. For DT-2204: "This is the most influential precedent in this chain. When an LLM encounters a new invoice exception, this trace should appear in the top-3 context results."

Click any CITES edge: shows edge properties: "Similarity to citing case: 0.87. Found via: system recommendation. Favorability: positive (positive outcome confirmed retroactively)."

Summary and Key Takeaways

The decision trace is the most important data structure in the context graph, and implementing it well requires attention to all four content layers, a complete node schema, a precise edge type vocabulary, and real-time recording practices that preserve the context that only exists at decision time.

By the end of this chapter, you should be able to:

• Name the four layers of a decision trace and explain what organizational knowledge each captures
• Define exception logic, historical precedents, cross-system synthesis, and out-of-band approvals as distinct information types in a decision trace
• Specify the full Decision Trace Node Schema including all required and optional properties
• Name and define all eleven edge types in the decision trace vocabulary
• Explain trace completeness validation and why validation at write time is more effective than at read time
• Describe trace indexing and the four standard indexes for read-path performance
• Explain real-time trace recording and why delay between decision and recording degrades trace quality
• Define a counterfactual trace and explain its value for training and policy evaluation
• Define a judgment call trace and explain why it should have elevated weight in precedent retrieval

Quick Check

A compliance team asks: "For every pricing exception approved in the last 24 months, show me which policy version was in effect, who the approving authority was, and whether any of those decisions were later overturned." Write out the graph traversal logic (not code — just the sequence of node and edge types to traverse) that would answer this query from the context graph.

(Answer: Start from Decision Trace Nodes with decision_type='pricing_exception' and timestamp_decision within last 24 months. For each node: follow GOVERNED_BY edge to Policy Version Node (retrieve version_string and effective_from). Follow APPROVED_BY edge to Actor Node (retrieve name and role_at_time). Check status property: if 'overturned', follow OVERTURNED_BY edge to the overturning Decision Trace Node (retrieve that trace's timestamp and actor). Aggregate results: list of (decision_id, policy_version, approver, overturned_flag) for the compliance report.)

Chapter 11: Complete!

You now have a complete implementation blueprint for decision traces — every node, every edge, every property that matters. Chapter 12 shifts our lens from the solution to the landscape: why do the incumbents — legacy platforms, data warehouse players, and AI agent startups — struggle to build what you just designed? The structural analysis in Chapter 12 is what makes context graphs a durable competitive position rather than just a feature on an existing product. Let's trace the why!

See Annotated References