Knowledge Graphs, Geometric Memory and Auditable Decisions

Two kinds of software already sit in every bank, and neither one answers the question a regulator asks. When a committee has to justify a decision, it needs the specific evidence and the reasoning that ties that evidence to the conclusion. The systems in production supply one or the other.

Document search supplies neither well. It splits policies and reports into fragments, turns each fragment into numbers, and returns the fragments that most resemble a query. It can hand back a passage, but it cannot say which cell a figure came from, and it cannot reason across facts. Asked whether an account behaves like a money mule, the best it can do is find paragraphs that mention mules.

The risk scorecard reasons, but out of sight. It takes engineered signals, the count of senders paying into an account, the share of transfers sitting just under a reporting threshold, a destination-risk flag, and combines them with tuned weights into a single number. The number is often accurate. What the scorecard will not tell the analyst is which condition fired, or why this account and not the one beside it.

A newer pattern puts a language model in front of the business and lets it answer in plain language. On its own this is the weakest of the three, because it is ungrounded. A language model will state something false as readily as something true, and its reasoning cannot be traced with any reliability. No bank can hand a lending or an anti-money-laundering decision to a model that behaves this way.

The design below is meant to pass the test the first two fail and to make the third safe to use. It has a few parts: a knowledge graph, a memory that holds the graph geometrically, a way of binding plain-language questions to that memory, provenance that ties every fact to its source and a rule that the model may propose while only the memory may decide.

Think of the knowledge graph as a structured index over the bank’s own data. Rather than storing reports as text to be read again, it stores them as connected facts. Every account, customer, counterparty and vendor is a labeled entity. Every transfer, ownership link or shared device is a labeled, directed connection between two entities. “Account A wired $9,400 to Account B” is one entry; “Person P controls Account B” is another. The stored unit is a plain statement of subject, relation and object, so the ledger becomes a network of who did what to whom instead of a stack of paragraphs.

The structure is what makes patterns visible. Money laundering is a pattern, not a line item. A money mule is a rented bank account, used to collect the proceeds of a scam and pass them out of the banking system, and on its own statement it looks ordinary: money arrives, money leaves. What marks it is the shape of the activity, many small credits from unrelated senders arriving in a burst, swept out to a single cash-out point, with no payroll and no card spending beside them. That shape is visible only when the facts form a network you can trace.

The knowledge graph is what is stored: facts and their sources. The geometric memory store, or GMS, is how they are held, and the how is what raises it above a lookup table. Each entity and each relation is kept as a position and an operation in a geometric space rather than as a plain row. Two things follow, and both matter to the business.

Binding becomes robust. Near-meanings sit near each other in the space, so “cloud segment”, “cloud platform” and “the cloud business” reach the same entity, and a condition written one way by an analyst finds a fact recorded another way in the ledger. A store keyed on exact text answers only questions phrased the way the data was written. The geometric store meets ordinary language.

Relations compose. A funnel runs sender to mule to exit, money in followed by money out, and that two-hop path is never recorded as a single fact. Because a relation is held as an operation, the store can chain the transfer in with the transfer out and check whether the two steps land on the true cash-out account. It recovers the shape of a scheme from the single transfers it was shown, without being told which accounts were mules. Detection patterns are written as a named catalog an analyst can read, and an alert comes back broken into named parts, each with its own contribution, so the reader sees which condition fired and by how much. The store is deterministic: the same query returns the same answer, which is what lets it act as a control rather than a suggestion.

A store of facts does not understand a question by itself. People ask in text; the store is keyed on entities and relations. Binding is the step between them. It turns “does this account look like a funnel?” into a query over the graph: resolve the account to its entity, resolve “funnel” to the pattern of connections that defines it, and evaluate that pattern against the data. The geometric representation is what makes this reliable. For the business the point is plain: the system takes ordinary language and does the translation into a precise query, so the user does not have to know how each fact was stored.

Every fact keeps a link back to where it came from: the file, the line, the character span and the raw text of the source cell, or the specific table cell for structured data. When the system reports a figure, it returns the number, the row it came from and the location of that row. The value it reports and the value in the document are read from the same place, so nothing is retyped from a model’s memory.

Two properties make this worth having. The store checks that a cited source actually supports the fact attached to it, so a citation cannot drift away from what it points to. And a claim that lives only in text, with no cell or row to anchor it, is marked unanchored and reported as such rather than given an invented citation. The blind spots are measured, not hidden.

This is the place for the language model, and the place has a boundary. The division of labor is clean. The model handles language and initiative: it reads the question, proposes an action, drafts the explanation and, when documents come in, proposes candidate facts for the graph. The geometric memory store handles truth and authority: it binds the language to real facts, checks proposed actions and proposed facts against the rules, supplies the provenance and refuses whatever fails to ground.

The working rule is that the model proposes, the store validates, the system executes. The model can explore as widely as it likes, and nothing it proposes takes effect until the store has checked it against the governed graph and attached the evidence. The model never has the last word, and it never supplies the facts from its own memory; it works over a deterministic, governed store.

This is what makes an agentic system safe to run. An agent is a language model that plans and acts across many steps instead of answering once. Autonomy of that kind is acceptable only if it is bounded, and the store is the bound. Each step the agent takes is grounded in the store’s facts and checked against the store’s rules before it has any effect. The model brings initiative and language; the store brings the ground truth and the limits.

Everything so far concerns one graph, the data. The move that turns a search tool into a governance tool is to treat the rules as knowledge too, and store them the same way.

A bank keeps two kinds of document that rarely meet. On one side are the policies, procedures and typology definitions, the text that says what a rule is, what conditions define a pattern and what limits apply. On the other side are the records, the transactions and accounts and their performance. Today the first is a document a committee reads and the second is a warehouse analysts query, and the link between them lives in people’s heads and in spreadsheets.

Hold each in the store as a graph. The rulebook becomes a graph of definitional facts, each traced to the clause it came from. The records become a graph of observed facts, each traced to a row or a cell. A question can be put to either. The step that matters is that the rulebook graph can generate queries against the data graph: a rule’s conditions compile into checks that run over the records. The detector is no longer code that reimplements the policy. The policy, held as data, is the detector, and when a language model proposes an action, the rulebook graph is what validates it.

The design is easiest to see where the rulebook and the data are plainly different documents owned by different teams. A credit card business has both. One is a credit strategy document, which sets risk appetite, exposure limits, loss and capital budgets, together with the conditions under which a segment may be grown or must be held back. The other is account-level performance: millions of accounts with their balances, losses, vintages and stress outcomes, rolled up into portfolio segments.

The strategy graph holds the rulebook as typed facts. Each clause becomes a triple of subject, relation, value and a label for how binding it is.

(portfolio, loss_budget_ceiling, 0.50, HARD)       — stressed loss must stay within budget
(portfolio, concentration_limit, 0.25, SOFT)       — no segment above 25% of portfolio value
(near-prime S5, max_exposure, 0.60, HARD)          — exposure capped
(near-prime S5, max_delta_per_cycle, 0.10, HARD)   — move at most 10 points per cycle
(near-prime S5, requires, stress_pass, PREREQ)     — may grow only if it passed the stress test
(subprime  S7, uncertainty_ceiling, 0.30, HARD)    — no action where estimate error exceeds 0.30

Every triple carries provenance back to the section of the strategy document it was read from. The performance graph holds the records as typed facts, each segment carrying its computed value, its stressed loss, its capital cost, its estimate uncertainty and its stress-test result, each traced to the account rows underneath.

A decision arrives: raise near-prime exposure from its current level to 0.80. It comes from a language-model advisor asked to lift portfolio value. Under the working rule the model proposes and the store validates before anything runs.

Validation is the two-graph query at work. The proposal binds to the strategy graph, which returns the clauses that govern that segment. Each clause compiles into a check against the performance graph. The exposure cap tests the proposed 0.80 against 0.60 and fails. The per-cycle limit tests the size of the move against 0.10 and fails. The prerequisite looks up the segment’s stress result and finds it did not pass. The uncertainty ceiling reads the segment’s estimate error and passes. The portfolio loss ceiling recomputes total stressed loss with the change applied and tests it against budget.

The rulebook was not reimplemented inside the validator. Its triples are the checks. When the committee revises the strategy, moving a cap or tightening a prerequisite, the strategy graph changes and the checks change with it, with no code release.

The proposal is rejected, and the rejection is a full record. On the authority side each failed check names the clause that governs it, traced to the strategy document. On the evidence side each check names the data it read, traced to the account rows. The advisor’s fluent case for the change never reaches the portfolio, because the store did not admit it. Every refusal points to the rule that refused and the number that triggered it.

The anti-money-laundering case is this design with the roles filled differently. The rulebook graph is the typology catalog, the definitions of pass-through layering, circular flow and the mule pattern, each condition traced to the procedure that defines it. The data graph is the transaction ledger. A language model may phrase the analyst’s question and draft the narrative, while the typology’s conditions compile into a query over the ledger inside the store, the alert fires when the records satisfy them, and the alert cites both the clause that defined the pattern and the transactions that matched it. Detection and governance run on one mechanism: a rulebook graph, a data graph, a store that binds one to the other and a language model kept to language.

The result changes what a decision is. In place of a number no one can open, or a fluent answer no one can check, a committee receives a record it can act on and defend: the records involved with their identifiers and values, the rule or pattern they were tested against, the condition that fired, a source pointer behind every figure that has been checked to support its claim and the clause that made it a rule. The reasoning and the evidence arrive together, and both trace to documents a person can read.

The language model supplies the fluency and the initiative that make the system usable and, in an agent, autonomous. The geometric memory store supplies the ground truth, the rules and the provenance that make it accountable. Because the rules are data rather than code, they change when the committee changes them, and the audit trail changes with them.

Read more here: https://leanpub.com/beyondpromptandpray