There is a ceiling that every ambitious compliance system runs into, and it is not a technical one. It is a liability ceiling. A wrong rule in regulated work is not a bug you patch in the next release. It is a wrong decision made about someone's money, license, or freedom, with consequences that attach to whoever deployed it. So the rate at which a system can responsibly add rules is capped by the rate at which someone qualified can confirm those rules are correct. You cannot ship a Basel rule, or an FDA-pathway rule, faster than an expert can validate it, because an unvalidated rule that makes a real decision is a liability waiting to be triggered.
This ceiling is real, and it appears to put a hard limit on coverage. The pipeline can produce candidate rules quickly. The validation cannot keep up. So either you slow the pipeline to the speed of validation, and accept thin coverage, or you ship unvalidated rules and accept the liability. That looks like the whole choice.
Rules can be authored quickly. Validation cannot keep up. So the apparent choice is to slow authoring to the speed of validation and accept thin coverage, or to ship unvalidated rules and accept the liability.
It is not the whole choice, and this paper is about the field that dissolves it: separating whether a rule exists from whether it can be trusted.
The conflation that creates the ceiling
The ceiling exists because of a hidden conflation. In most systems, a rule that exists is a rule that runs. To add a rule to the corpus is to put it into the decision path. Existence and authority are the same act. And because they are the same act, the liability of authority attaches the moment a rule exists, which is why every rule has to be validated before it can be added, which is what caps the rate of addition at the rate of validation.
Pull those two apart and the cap disappears. Let a rule exist without yet having authority. Let it be in the corpus, searchable, visible, even demonstrable, while being explicitly gated out of any real decision until a qualified person has signed off on it. Now adding a rule is cheap and safe, because adding it does not put it into the decision path. Only validating it does that. Authoring can run as fast as it likes, producing candidates, and none of them carries liability, because none of them decides anything until trust is granted separately.
Trust as a field
The mechanism is to make trust an explicit property of every rule, a field that records how far the rule can be relied on. A rule is not simply present or absent. It has a status, and the status governs what the rule is allowed to do.
A candidate is a rule that exists but has not been validated. It can be searched, inspected, shown in a preview, used to demonstrate coverage. It cannot make a binding decision. An expert-reviewed rule has been confirmed by a qualified person to faithfully encode the regulation it claims to, and it is allowed into the decision path. A customer-validated rule has been confirmed in use by the institution relying on it, the strongest tier, because the party who bears the consequence has affirmed it. The status is not a comment or a wiki note. It is a field the engine reads, and it gates behavior: a candidate rule that matches a case produces a preview marked as such, never a verdict, while a reviewed or validated rule produces a real decision.
This single field is what decouples coverage from trust. Coverage is how many rules exist. Trust is how many have been validated. With the status field, those two numbers are allowed to be different, and the gap between them is not a problem to hide. It is a managed, visible state: this many rules cover the domain, this many of them are trusted enough to decide, and here is exactly which is which.
Coverage ahead of validation
Consider what this makes possible. Suppose authoring runs well ahead of validation, and a domain accumulates a large body of candidate rules. In a system that conflates existence with authority, this is a catastrophe in waiting: a mass of unvalidated rules sitting in the decision path. In a system with the trust field, it is a mass of candidates, every one of them gated to preview, carrying exactly zero liability, because not one of them can make a binding decision until a person upgrades its status.
The experts then work through them at the speed experts actually work, upgrading candidates to reviewed as they confirm each one, and the coverage that is trusted grows steadily while the coverage that exists was there from the start. Authoring never had to wait for validation, and validation never had to rush. The two run at their own speeds, joined only by the status field that keeps the unvalidated work safely out of the decisions that matter. The ceiling that seemed to cap the whole system was an artifact of conflating two things, and separating them lifts it entirely.
Who grants trust
A field is only as meaningful as the act that changes it, so the question of who validates is not a detail. A domain does not enter serious use without a named source of validation, because trust granted by no one is not trust.
There are a few shapes this takes. The strongest is the customer as validator: in a domain where the buyers are themselves the experts, a bank's compliance team, a hospital's clinicians, the people who bear the consequence of a rule are the people who confirm it, and their confirmation is the highest tier of trust because it is backed by their own accountability. Where the builder has the expertise in-house, in-house review grants the first tier. Where a domain is being explored before commitment, a fractional or advisory expert can validate, enough to ship candidates as reviewed previews. And a partner who is a domain incumbent can validate as a channel. What is not acceptable is a rule that decides on no one's authority. Every rule that reaches the decision path traces to a person who put their name on it.
The honesty of a trust field
There is a deeper virtue here than scaling, and it is honesty. A system with a trust field cannot pretend a rule is more reliable than it is, because the reliability is written down, on the rule, in a field the consumer can read. A candidate is badged as a preview. A reviewed rule is presented as trusted. The consumer of a decision sees not just the verdict but how much to lean on it, and that is a more honest thing to hand someone than a uniform confidence that hides the difference between a rule an expert signed last week and a rule a pipeline produced an hour ago.
This is the same instinct that runs through the rest of the architecture. The system that fails closed says "I could not check" rather than guessing. The system with a trust field says "this rule has not been validated; treat it as a preview" rather than presenting it as settled. In both cases the system is refusing to let an absence, of verification, of validation, pass for a presence. Trust is not a vibe the system projects. It is a state it tracks, per rule, and tells you.
The point
The apparent ceiling on a regulated rule corpus, that you cannot add rules faster than you can validate them, comes entirely from treating existence and trust as the same thing. Separate them with a status field that gates what each rule may do, and the ceiling lifts: coverage can grow at the speed of generation while trust grows at the speed of expert judgment, and the gap between them is a managed, honest, visible state rather than a hidden liability. A rule that exists is not yet a rule you trust, and saying so plainly, on every rule, is what lets a system be both comprehensive and safe at once. Coverage is not trust, and the systems that survive in regulated work are the ones built to know the difference.