Two customers ask your assistant the identical question — “can you add that fee to my loan?” — and the correct answer is yes for one and illegal for the other. Nothing else differs. One lives in a state where the fee is permitted. The other lives in a state where quoting it is a violation with a licensing consequence.
Your model does not know this. Your model was trained on the internet, where state installment-lending law is, to put it gently, underrepresented. And the deeper problem is that this isn’t one fact the model is missing — it’s a matrix. A multistate consumer lender operates under forty-plus licensing regimes, each with its own rate caps, fee rules, disclosure wording, servicing conduct standards, and mini-FTC act. Add the new generation of state AI statutes — arriving on staggered timelines, amended mid-flight, no two alike — and the compliance surface isn’t a rulebook. It’s a spreadsheet with a time axis.
This series began with the observation that one AI feature at a nonbank lender answers to the CFPB and every state that licenses it. This closing part is about the architectural consequence: jurisdiction is a runtime parameter, and any policy that varies by jurisdiction must live where runtime parameters live — in data the enforcement layer consults, not in prose the model was asked to remember.
The anti-pattern: policy as prompt
Every team meets this problem the same way first: put the rules in the system prompt. “In Iowa, do not discuss fee X. In Oregon, the maximum rate is…” It feels like governance. It is the PDF policy with a lower word count, and it fails in four distinct ways.
It’s probabilistic — instruction-following is a tendency, not a mechanism, and a tendency is not a control; no security or compliance property may depend on the model behaving. It’s untestable in isolation — a rule buried in a wall of prompt text can’t be verified except by sampling the whole system’s behavior, which is exactly the sampling-is-not-enforcement trap. It drifts — prompts get edited for tone and capability by people who don’t know clause fourteen was load-bearing for New Mexico, and no diff review will catch it because the prompt diff looks like wordsmithing. And it doesn’t scale — forty states times a few dozen rules each is thousands of tokens of legal text degrading attention on every single request, taxing every customer to remind the model of rules relevant to none of them.
The prompt is the wrong organ for law. The right organ is the one this series already built.
Policy as data: the rule table
The compliant shape puts every jurisdiction-varying rule into versioned rule tables — structured data, one authoritative source, keyed by jurisdiction: permitted products and fees, rate caps, required disclosure elements, prohibited claims, conduct rules. Not code, and definitely not prose: data, with a schema.
And then the layers this series built consume it. The policy enforcement point resolves the customer’s jurisdiction from the authenticated session — the same session-binding that stops the confused-deputy attack also answers which law applies — and checks every proposed intent against that jurisdiction’s rows. Retrieval filters on it, so the model grounds on the disclosure language for this state instead of choosing among fifty near-duplicates. Deterministic output checks consult it: a generated answer quoting a rate above this state’s cap fails closed, exactly like a hallucinated APR, because that’s what it is. The model, meanwhile, is asked to remember nothing — it operates inside a context that has already been jurisdictionally shaped, and is bounded by checks that don’t care what it remembers.
The division of labor writes itself, and it’s the contract that makes the whole thing maintainable: compliance owns the rows; engineering owns the schema. A regulatory-change memo becomes a data change — reviewed, versioned, diffable, attributable — instead of a prompt edit. When a state amends its statute, the diff shows two rows and a version bump, and the reviewer is a compliance officer reading rows in her own domain, not an engineer squinting at prose. The decision-record discipline applies to the schema; the change log applies to the rows; and for the first time in this series, the lawyers are maintaining a governed artifact in their own hands rather than requesting engineering changes through a queue.
The eval matrix grows an axis
Testing inherits the structure. Part 1’s blocking scenarios were one-dimensional — scenario in, required behavior out. Multistate operation crosses every jurisdiction-sensitive scenario with every jurisdiction: the fee question times fifty, the rate quote times fifty, the hardship script times fifty. That sounds combinatorially grim until you notice the rule table generates the expectations — the same rows the enforcement layer consults at runtime produce the expected outcomes at test time, so scenarios are written once and instantiated per state. One source of truth, enforced live and verified in CI, which means the eval suite is also doing a second job: it’s testing that the table itself is internally coherent, because a row that can’t produce a consistent expected outcome is a row a human needs to look at.
The blocking discipline holds, tiered like everything else: zero-tolerance rows — rate caps, prohibited-fee quotes, covered-borrower protections — block the merge per state; softer rows feed dashboards. And a state examiner, who was always the other audience, gets evidence scoped to their jurisdiction on request: the rows in force, the version history, the eval results for their state’s scenarios, the enforcement log filtered to their residents. Evidence as exhaust, sliced by the examiner’s badge.
The table rots, so watch the table
One failure mode remains, and it’s the quiet one: the world changes and the table doesn’t. A statute is amended, an AI act’s compliance date arrives, a rate cap moves — and your enforcement layer goes on perfectly enforcing last year’s law. Everything looks green. A control nobody tests is a belief, and a rule table nobody freshness-checks is a belief with a version number.
So the last control in this series is a scheduled job in the Part-4 style: every jurisdiction’s rows carry a review-by date and a source citation; a dead-man-checked sweep compares review dates against the calendar and against the regulatory-change feed compliance already subscribes to; and a state whose rows have gone stale past their review date fails loudly — pages a human, marks the jurisdiction, and (for the zero-tolerance categories, by the signed fail-posture decision) degrades that state’s answers to the conservative path until a human re-certifies the rows. Silence is never evidence of freshness. The job that screams is.
Where the series lands
Five articles ago this series opened with an examiner walking into the room. Here’s the whole argument in one paragraph, now that the pieces exist. Regulation, read as an engineer, is a set of requirements with unusually motivated auditors. Every requirement gets bound to a control point that makes it physically true: accuracy to blocking evals, decisions to deterministic cores that can state their reasons, data duties to manifests the build enforces, jurisdiction to rule tables the gateway consults. The model is never asked to be the compliance mechanism — it proposes, it translates, it operates inside shaped context — and no legal property depends on it behaving. And because every control is code, every control emits evidence as exhaust: the binder is a query, the examiner’s packet is a filter, and the system that satisfies the attacker’s auditor and the state’s auditor is the same system, built once.
Governance that bites, in the rooms where it’s also the law.