Build a Knowledge Layer: Ground Decisions in Precedent

In this series

1. Give Your AI Agents the Shared Context to Succeed

2. Map Your Data with an Ontology

3. Turn Your Existing Data into Context

4. Connect Your Data Sources with a Composite Database

5. Ground Decisions in Precedent

Code: knowledge-layer-demo on GitHub

Why does an AI agent need a context graph? 

Context graphs make decisions more fair, more traceable, and more defensible. When an AI agent approves one applicant and declines another who failed the same lending rule, the bank faces a question it cannot answer, because the agent has no earlier case to point to when someone asks why. A context graph gives the agent that missing memory by storing every decision alongside the rules behind it, so similar cases receive similar outcomes and each outcome cites the earlier case that supports it, which gives the agent the same consistent, traceable, and defensible judgment that a human underwriter brings to every case.

This post shows where a context graph fits in a knowledge layer and how you can build one for a loan-decision agent, picking up from the earlier posts in this series that covered a Virtual Graph, a document graph, and a composite database that joins them.

Those graphs hold facts that exist independently of any agent, such as a customer’s credit score, a lending policy, a business plan, which means none of them remembers what an agent decided. A context graph fills that gap by supplying the memory component of the knowledge layer, holding what the agent decided and why, so before it makes a new recommendation, it can check whether this situation has happened before and what was decided.

See the below demo for how a context graph informed a loan decision:

What makes a good schema for a context graph?

A context graph is persistent memory for an AI agent, so a good schema would capture each decision, what went into that decision, which rules it applied, and how it relates to earlier decisions. 

To record loan decisions for Nordtell Bank, each recommendation is stored as a Decision node. It points to a Customer node, to a PolicyRule node for each rule the agent applied, and to an Escalation node if the decision triggered one.

Take a look at the schema below:

The context graph sits in its own slot in the composite database, and it keeps itself small on purpose. Composite databases don’t allow relationships between constituents, so it holds stripped-down copies of customers, rules, and escalations, and leaves the full records in their respective graphs. A shared ruleId is the one thread back to the lending policy, and since every decision that cites a rule points to the same node, “who failed this rule?” becomes a single hop.

How does a context graph find precedent for a decision?

You can let the model read the whole context graph and judge which cases are comparable, which gets slower and less predictable as the decision history grows, or you can compare embeddings or graph similarity scores to surface similar cases, which makes the results depend on how similarity is scored. You can also define precedent in the graph itself, which gives the agent a fixed rule for what counts as comparable.

We took that third approach because it makes precedent deterministic, since two decisions are comparable when they fail the same policy rule.

That makes finding precedents easy because each decision is already connected to the policy rules it was checked against. To retrieve it, the agent runs one query with the rule ids the applicant failed

USE meridianComposite.context

MATCH (rule:PolicyRule)

WHERE rule.ruleId IN $failedRuleIds

MATCH (rule)<-[:APPLIED_POLICY {failed: true}]-(priorDecision:Decision)

RETURN DISTINCT priorDecision.decisionId AS decisionId,

       priorDecision.customerName AS customerName,

       priorDecision.recommendation AS recommendation,

       priorDecision.reasoning AS reasoning,

       priorDecision.escalationRole AS escalationRole,

       rule.ruleId AS ruleIdCode language: JavaScript (javascript)

The query returns every earlier decision that failed any of the rules in $failedRuleIds, along with what was decided and why. If the applicant fails no rules, there is nothing to look up, so the agent skips the query.

When does an AI agent call the context graph?

Two tools touch the context graph. get_decision_history finds precedents, and record_decision writes the finished decision. The agent looks up precedent once it knows which lending policy rules failed (if any) before it reaches a recommendation. It then records the decision just before it writes its answer. Looking up precedent first lets earlier cases shape the recommendation, and recording the decision afterward saves it to the graph so it can serve as precedent the next time a similar case comes in.

How do different layers work together on one loan?

Rosa’s Bakery applies for a term loan, and the agent pulls her transactions, credit score, and KYC status from the Virtual Graph, her business plan from the document graph, and the term-loan rules from the lending policy. She fails two of those rules because the requested amount is too large for her cash flow (POL-003), and an affiliate under common ownership is delinquent on an existing facility (POL-005). Only then does the agent query the context graph, passing those two rule ids to get_decision_history.

The lookup returns two cases, in which Cannon, Anderson and Alvarez were declined for failing POL-003, at roughly 4.1x cash flow against the 3.5x cap. Snyder, Campos and Callahan was escalated to the Credit Risk Committee for POL-005, because a sibling company under common ownership was delinquent. The agent weighs both as evidence, reaches its recommendation, and records it. 

In the run we captured, it recommends Decline.

The Virtual Graph and the document graph supplied the facts, the lending policy supplied the rules, and the context graph supplied the earlier cases, and all three meet at one point, the failed policy rule. 

Next steps

• The previous post, Connect Your Data Sources with a Composite Database, covers the composite database this context graph sits in. 
• Read Hands-On with Context Graphs and Neo4j.