A great deal of attention goes to the rule. It is the part that encodes the regulation, produces the verdict, carries the citation. It is what people mean when they talk about a compliance engine. But a rule is helpless on its own, because a rule operates on structured facts, and structured facts are not what the world hands you. The world hands you a scanned document, a name spelled three ways, a brand instead of an ingredient, a ticker instead of an instrument, a paragraph instead of a typed clause. Something has to stand between the mess and the rule and turn one into the other. That something is normalization, and it is the part nobody demos and everybody underestimates.
This paper is about that step. What it is, why it is the job a language model is actually built for, why the real accumulated value of a system tends to hide inside it, and why a normalization error is the most dangerous error in the whole system, because it is invisible to every rule downstream.
The step nobody demos
Watch a demo of a compliance system and you will see the rule fire. A document goes in, a verdict comes out, the verdict is correct, the citation is attached. What you will not see, because it does not demo well, is the work that happened before the rule ran: the resolving of a messy input into the clean fields the rule needed. It happened, or the rule could not have fired, but it happened in the background, and so it gets treated as plumbing.
It is not plumbing. It is half the system, and it is the half that determines whether the other half is operating on truth or on garbage. A rule that checks whether a holding crossed five percent is exact and trustworthy, and it is exactly as trustworthy as the number it was given. If the step that read "6.2%" out of the filing read it wrong, the rule will correctly apply the threshold to the wrong number and produce a confident, traceable, completely incorrect verdict. The rule did its job. The system still failed, upstream, in the part nobody was watching.
The reason this matters so much in regulated work is that the inputs are uniquely hostile. A consumer application can often assume clean, structured input from its own forms. A compliance system has to ingest the world: documents written by other parties, in other formats, in other languages, with the inconsistencies and the occasional deliberate obfuscation that come with real commerce. The gap between that and a clean field is enormous, and normalization is the entire job of closing it.
What normalization actually does
Strip away the domain and normalization is always the same move: take the messy real-world reference to a thing, and resolve it to the canonical identity of that thing, the one the rules are written against.
A party on a payment is a string, "ACME Trading FZE," maybe transliterated, maybe abbreviated. Normalization resolves it to an entity, the actual organization, against which screening can run. A medication on a prescription is a brand, "Napa." Normalization resolves it to its generic ingredient, paracetamol, and from there to its drug class, against which interaction rules can run. A security is a ticker or a local name. Normalization resolves it to an instrument with an international identifier and an issuer. A clause in a contract is a paragraph of prose. Normalization resolves it to a typed clause, a limitation of liability, against which the playbook can be checked. A counterparty's address is a line of text. Normalization resolves it to a jurisdiction, against which the cross-border rules can run.
The subjects could not be more different. A party, a drug, a security, a clause, a place. The move is identical every time: messy reference in, canonical identity out. And it has to happen first, before any rule runs, because every rule is written against the canonical identity and knows nothing about the messy reference. The rule does not know "Napa." It knows paracetamol. The bridge between them is the whole job.
The job the model was built for
Here is where the language model earns its place in the architecture, and it earns it decisively. Resolving messy references to canonical identities is a reading task, and reading is what a model is genuinely, transformatively good at. Recognizing that "Napa" is a brand of paracetamol despite never being told so explicitly. Understanding that a dense paragraph is functionally an indemnity clause. Pulling a date out of a sentence that buries it in narrative. Matching a transliterated name to its standard form. These are not arithmetic, and they are not lookups you can fully enumerate in advance. They are acts of interpretation over language, and a model does them at a level no rule-based parser ever reached.
This is the answer to the question of where AI belongs in a system built on deterministic rules. It belongs here, at the front, doing the reading. The model turns the world into fields. Then it steps back, and the rules, deterministic and traceable, operate on those fields. The model is not kept out of the system. It is given the job it is best at, and it is the job that was historically the bottleneck, because before the model, turning messy documents into clean fields took rooms full of people. The model is the thing that finally made the inputs cheap. That is not a small contribution. It is most of the practical reason any of this is now economic.
Where the value hides
There is a strategic observation buried in the normalization step, and it is worth stating plainly because it inverts where people expect the value to be. The rules, in most domains, are public. The regulation is published. Anyone can read GDPR Article 33 or the UCP 600 or the EU AI Act. The encoding of them is real work, but it is work over public material. The normalization layer is different. The maps that resolve messy references to canonical identities, a comprehensive entity graph, a brand-to-generic mapping for a local market, an instrument master, are maintained reference data, and the good ones are hard-won and not lying around for free.
So the durable edge of a regulated system often sits not in the rules, which are encodings of public law, but in the quality and coverage of its normalization, which is accumulated, maintained, and specific. The rule that says "screen the party against the sanctions list" is the same for everyone. The ability to resolve a badly transliterated name to the right entity is not. The unglamorous front half of the system is, frequently, where the durable advantage actually sits.
Garbage in, but worse
Everyone knows the principle that bad input produces bad output. In regulated work the principle has a sharper edge, because the bad output does not look bad. It looks exactly like good output.
When normalization fails quietly, resolving a name to the wrong entity, a brand to the wrong generic, a clause to the wrong type, the rule that runs next does not know anything went wrong. It receives a clean, well-formed field and applies itself correctly to it, and produces a verdict that is confident, traceable, and wrong, with a citation attached and an audit trail intact. Every part of the system downstream of the error behaves perfectly. The error is sealed inside a correct-looking decision, and there is no flag on it, because nothing downstream had any way to know the input was a misreading.
This is why a normalization mistake is the most dangerous kind. A rule error can often be caught by review of the rule. A normalization error is invisible precisely because the rules worked. It is the one failure that hides behind the system's own correctness. Which means the discipline that governs the rest of the engine has to govern normalization first and hardest.
Normalization must fail closed
The discipline is the same one that runs through the whole architecture, and it is non-negotiable at the front: when normalization cannot confidently resolve a reference, it must not guess, and it must not pass the case along as if it had succeeded. An unresolved party is not a clean party. An unidentifiable drug is not a safe drug. A name that matched nothing above threshold is not a name that cleared.
So the resolution step is tiered and honest about its own confidence. An exact match is taken. A normalized match, after standardizing the messy reference, is taken. A close fuzzy match above a high threshold may be taken, with a note that it was fuzzy. And below that, where the system cannot identify the thing with enough confidence to stake a decision on it, it does not invent an identity. It marks the reference unresolved and routes the case to a person. The system would rather say "I could not identify this party" than quietly resolve it to a plausible wrong entity and let a rule clear it. Guessing an identity is the one thing normalization is never allowed to do, because a wrong identity confidently asserted is the seed of every invisible error described above.
The point
The rule gets the attention because the rule produces the verdict. But the verdict is only as good as the facts it ran on, and the facts come from normalization, the step that turns the messy world into the clean canonical input the rule requires. It is the job the model is best at, it is often where the real maintained value of a system lives, and it is the place where an error becomes invisible by hiding behind the system's own correctness. Get it right, with the model reading and the resolution failing closed when it is unsure, and the rules above it operate on truth. Get it wrong, and every rule above it operates, perfectly and traceably, on a lie. Before any rule can run, something has to turn the world into fields. How well that is done is, quietly, most of whether the system can be trusted at all.