Admissibility

The class is specific, and it has to be defined before the argument can lean on it: work with bounded inputs, a repeatable institutional standard for what good looks like, an output a competent person can review, and an existing human process against which the model's error rate can be measured. Software engineering agents that commit code to production, operations agents that resolve cases on live files, compliance agents that work alerts to closure - work of that shape. It is not open-ended judgement under novelty; there, capability is still the constraint, and I am not claiming otherwise. The claim is also not that every stalled deployment is a governance problem - plenty stall on latency, integration, data access, or cost. It is narrower and more exact: in enough bounded delegated tasks to matter, the institution accepts the model's output as good enough, and then cannot let the system act on it - because it cannot make that output something it is allowed to rely on.

It stalls at the point where the output stops being a draft for a person to check and starts being something the institution acts on. Four questions sit at that point, and capability does not settle them. Can we prove what the system decided, and on what basis? Can we say what it is allowed to act on, and on whose authority? Can we show a supervisor the context the decision was made in? Can we produce the evidence the act is supposed to leave behind?

Those are admissibility questions. I mean admissibility not in the courtroom sense but an operational one: whether, before the act, an institution can treat the model's output as a permissible basis for action - and stand behind that choice afterwards. Capability decides whether the answer is good. Admissibility decides whether the institution may rely on it. They are different axes, and they are sequenced - in logic, not in project order: even after the institution judges the output good enough for the task, a separate question remains, whether it may act on it. For regulated deployment, the second question is the one that binds.

Those four questions are not four separate problems. Put to a supervisor, an auditor, or a court after something has gone wrong, they collapse into one: at the moment the system acted, did the institution have a defensible basis for the act, and could it have known if it did not. That is the operational invariant admissibility comes down to. No consequential action commits unless the claims it depends on still hold - well-sourced, current, and uncontradicted enough for what the act will do - the authority to rely on them is in place, and the act records the context it relied on and the evidence it produced.

Two things about this invariant are load-bearing and need stating directly. First, the four conditions are not a checklist - they have to hold together at the moment of commit. Any one failing makes the act unbasable in retrospect, which is why supervisors, auditors, and courts collapse them into one: from the outside, after a failure, no party distinguishes a stale basis from an unclear authority from an unrecorded context. Any of them is enough to make the act unbasable. Second, the check has to fire before commit, not after. There is no remediation path that returns a committed delegated act to its pre-commit state - the notice has issued, the payment has cleared, the alert has closed. A check that fires afterwards is a finding, not a control. The invariant names a preventive control on delegated action, and that is the shape the rest of the piece is about.

It is not a new principle. It is the old principle of not acting without a basis, made to hold at machine speed, with no person in the path to hold it.

I write this from the delivery side of regulated transformation, not from a lab - and I am building in this space. The stake is specific: I have a commercial interest in the claim that admissibility is a real and distinct requirement. Read this as a bet from someone with that interest, not a neutral survey - and note that the architectural claim and the venture claim can come apart. If existing platforms absorb this invariant as ordinary plumbing, the architecture was right and there is no separate company to build; I think that is a live possibility. The bet rests on a pattern, and I should be plain about its status: this is not survey evidence, it is a delivery-side observation, consistent enough across different regulated settings to design for. The pattern runs like this. The model passes its evaluation. The business owner wants to proceed. Legal asks which policy interpretation the model relied on. Risk asks who owns that interpretation. Audit asks whether the decision context can be reconstructed a year later. The answers turn out to be scattered across policy documents, committee minutes, ticket threads, data permissions, and somebody's memory. The institution may have a basis for action somewhere. It does not have one the system can use before the act.

The constraint past capability

The claim has to be precise, because the loose version is wrong. Capability is still a constraint - a model that hallucinates, reasons badly, or breaks on the edge cases produces output an institution cannot defend. The argument is about what binds after the model is good enough, so the threshold has to be defined without leaning on admissibility to define it.

Here is the clean version, and it has two parts the loose version runs together. The first is capability proper: the model's raw task performance, its residual error profile before any institutional check, measured against the existing human process. That is a property of the model on the task. The second is absorption: whether the institution can catch or tolerate the errors that remain, within the operating process it already runs. That is a property of the operating model, not the model. It is a question of operational tolerance - whether the residual mistakes are manageable. Whether the institution may then rely on the output is a different question, and the one this piece is about. A task is ready for a rung when capability and absorption both hold. What readiness does not settle is whether the institution may then let the system act. Past the point where it clears, a better model still helps - cleaner output, fewer errors to govern - but it is no longer what decides the deployment date.

That threshold is not the same at every rung, because there is a ladder, and each rung has to clear on its own terms - nothing about clearing one rung implies the next. The advisory assistant drafts for a human who checks everything: the bar is the cost of that review, and for many standard drafting and summarisation tasks it cleared some time ago. The workflow participant routes and triages inside a controlled process: the bar is higher, because the catch is now process controls and institutional rules the output has to conform to, not a person reading every line, and it has cleared for some tasks and not others. The delegated operator acts: the bar is highest, because ordinary review is the thing being removed. Admissibility is what stops the operator - and increasingly the workflow participant - from moving. A more capable model lowers the burden the invariant imposes. It cannot remove it, because it cannot decide whether the institution may act on what it produced.

The loudest critic is still inside the frame

The strongest version of the case that the field has it wrong is architectural. The argument runs that today's models are the problem - that better grounding, planning, and world models will produce systems whose reasoning is inherently more traceable and predictable. Grant the strong form of it. A better-grounded model would automate much of the epistemic work: finding the policy, tracking which version is current, citing its sources, exposing its own uncertainty, proposing the record an act should leave behind. That helps, and it is real.

But it would not finish the job, and the reason is not a limit of the machine. When a bank acts, a named part of the institution is answerable for that act - to a supervisor, a court, a customer. That answerability has never moved to the tool, and nobody serious argues it should: the rules engine does not own the lending policy, the trading system does not own the mandate. So the accountability point on its own does not force anything; institutions have always carried it. What forces the architecture is what changes when the human leaves the path. While a person was there, the institution could carry its accountability the way it always had - reconcile the basis for the act through that person, through approvals, through review after the fact. Remove the person, and the institution still has to be able to show, before the act, that what the system relied on met its own conditions for relying. A perfectly grounded model can tell the bank what the policy appears to say. It cannot be the thing that owned that reading when the regulator asks who decided. The capability critique, in every version, is answering how to make the machine better. Admissibility is answering whether the institution can show it was answerable - and a better machine helps with the preparation but does not settle that.

What admissibility requires, and what a claim is

Admissibility does not need a new philosophy. The invariant names four things, and they have to be present, checkable, and binding at the moment an AI system acts - they are the four the opening questions were already pointing at. A basis: the claims the action rests on. An authority: who, or what, may rely on those claims, for this act, under what conditions. A context: the bounded record of what informed the decision, captured before the act rather than reconstructed after the failure. And evidence: the record the act itself produces, in a form the institution is prepared to defend.

Together they describe one event - the reliance event - not the anatomy of a single object. The basis is something the system holds; the authority is a rule it is checked against; the context and the evidence are records, one captured going in and one written coming out. None of this is new as a control idea - every consequential institutional decision has always needed all four. What is new is the demand that they be machine-operable, in the path of the action, before it commits. They are not a taxonomy of everything AI governance has to do; fairness, privacy, resilience, and human oversight do not reduce to them, and an act can be inadmissible for reasons that have nothing to do with the basis. They are the minimum the gate cannot defer.

Of the four, the basis is the one most often missing in the form delegated AI needs. Authority rules, context capture, and evidence records are familiar institutional machinery; institutions also govern plenty of basis-like things already - case facts, rule predicates, eligibility determinations, reason codes, master data. What is rarely present is the basis as a maintained, assertion-level object: an assertion whose standing can change on its own, independently of the workflow that first used it, and whose change can stop a later act before it commits. That object is the claim. A model's output - fluent, structured, possibly correct - is not yet one. It becomes a claim when it can answer four questions the gate cannot defer.

Where did it come from: a claim carries its provenance, a traceable chain from source through extraction method to an accountable validation point - a role, a rule, an approved process - never an anonymous assertion. How much weight it currently carries: a claim carries a standing, derived under rules the institution owns and can audit, not a confidence number the model reports about itself and not a label a reviewer attached by hand. Those rules are not exotic; they are the institution's own heuristics made executable - a claim from a filed regulatory document starts higher than one from an internal memo, corroboration from an independent source raises it, age lowers it. Standing is what source, validation, corroboration, and freshness add up to. What the claim does not carry is the authority to use it: that is a separate rule the gate applies, because the same well-sourced claim can be strong enough to draft on and not strong enough to act on. Whether it is still current: a claim carries a validity window, monitored, because knowledge goes stale at different rates, and an institution that treats the stale as current acts on something that has quietly stopped being true. And whether anything live contradicts it: a claim carries its contradiction status - what it conflicts with, within a source universe the institution has committed to watch, held open as typed information the gate can act on rather than silently resolved into one tidy field. Held open is not unresolved forever - it means the conflict stays visible, and is resolved, tolerated, or escalated under a rule fit to the consequence, instead of disappearing before anyone decided it should.

None of these four is an invention. Provenance is the territory of data lineage; a derived standing is what data-quality scoring does; a validity window is a familiar idea; holding contradictions open is what truth-maintenance systems have always done. Regulated institutions have also automated consequential decisions for decades - credit scoring, fraud declines, sanctions screening - where the facts and the rules were already formalised into a decision engine. None of that is the gap.

The gap appears where a delegated system relies on assertions that were never formalised that way: a policy interpretation, a document's meaning, a fact extracted from unstructured material, a reading of how a rule applies to this case. For that kind of basis, the institution's reconciliation - is this current, is it authorised, does anything contradict it - did not sit in a system. It often sat in the human reviewer, who supplied the join between the output and the institution's live knowledge that no formal control represented. Remove that reviewer, and the join does not vanish; it becomes unowned. So three things have to happen, in order. The reconciliation has to become explicit, rather than implicit in someone's judgement. It has to become machine-operable. And where the basis can go stale or be contradicted between the moment it is approved and the moment it is used - which is exactly the case for policy readings and extracted facts - it has to be checked against current state in the path of the act, because there is no longer a person between approval and action to notice. That last step is the one that forces the architecture, and only for that class of basis. The discipline it asks for is old - do not act without a basis. What is new is having to keep it without the person who used to.

This does not launder the model's uncertainty. The assertion a model extracts is still probabilistic, and admissibility cannot make it true. What it does is make the uncertainty inspectable and stoppable. A claim's standing is derived from its evidence under rules the institution owns, versions, and can challenge - not taken from the model's self-reported confidence. A fluent answer with a high confidence score is not an admissible basis; an assertion whose source, corroboration, and currency have been scored against governed rules is. The institution still carries the risk. The difference is that it can now see it, weigh it against the consequence, and decline.

So what does enforcing the invariant require, concretely? Two functions, and the order matters - functions, not products. The first is somewhere claims are kept and maintained: not a new enterprise knowledge base, and not a system of record for everything the institution knows, but maintained state for the claims a given set of AI-mediated actions is permitted to rely on, and their current standing. It is specialised because it has a job an ordinary data store does not - it recomputes a claim's standing when corroborating or contradicting evidence arrives, watches validity windows, and keeps contradiction live rather than letting it settle. A claim is not a record written once and read later; it is a thing whose standing can change between Monday and Tuesday without anyone touching it. The second function is a gate: the point where a proposed action is checked against the claims it depends on, before it commits, against their standing as it is at that moment. The gate is the visible move; the maintained state is what makes the gate mean anything - a gate with nothing live behind it is a rule firing on whatever it was handed.

I have been calling the two together a layer, and the word needs disciplining. A layer here is a logical responsibility, not a product you buy or a system you stand up beside the others. It can live inside a workflow engine, a decision platform, a knowledge graph, or be assembled across systems an institution already owns. And it does not need to start at enterprise scale: the unit of adoption is one delegated use case - one action path, the claims that path is allowed to rely on, the owners of those claims. What has to be true is the function. The packaging is open.

The check at the gate is not pass-or-fail. It is graduated: an action can proceed, proceed with the uncertainty logged, proceed in part, pause for a specific missing claim, escalate to a named human authority, or be refused outright. The consequence class of the action sets how high the claims' standing has to be before any of that is allowed - a low-consequence action can run on a thinly-supported claim, a critical one cannot. And the gate rarely tests one claim. A real institutional action rests on a bundle - a covenant breach notice depends on the borrower's filed accounts, the covenant definition, the calculation period, any waiver, and the authority to issue - and for the claims that are material and not substitutable, the act can be no stronger than the weakest of them.

Take the case that shows why the state has to be live, and take the hard form first - the interpretive one, which is where the architectural gap actually bites. A bank operates a delegated AML investigation agent that closes alerts under a current internal interpretation of sanctions guidance: a particular ownership structure does not amount to beneficial-ownership control. Six weeks later, a regulator-issued advisory refines the interpretation - structures of that shape do constitute control. Nobody re-opens the closed alerts; there is no reviewer between the agent's next decision and the act. But the interpretation the prior closures relied on has had its standing changed - by a named authority inside the institution, under a rule the institution has set for how external guidance updates internal interpretations - and the gate holds the next alert that depends on that interpretation, instead of letting the agent close it. The architecture does not adjudicate; it does not decide that the advisory supersedes the prior reading. It makes sure that once the institution's own authority has, the dependent act stops.

The simpler factual version is the same mechanism on easier ground. A lender runs a system that prepares covenant breach notices. It relies on the claim that a borrower's filed accounts are current and validated. A later filing supersedes those accounts. Nobody re-opens the case; there is no reviewer between approval and the next notice. The claim's standing has changed - the accounts it points to are no longer current - and the gate holds the next notice on that basis instead of issuing it. The change is not magic: a person or a feed has to enter the new filing into the system. What the layer does is make the consequence automatic once it is entered - it does not go and find the new filing in the world; it makes sure that once the world has changed, the act that depended on the old state does not quietly proceed. The shape is the same as the interpretive case. The difference is that for the factual version, existing master-data and reference-data controls already do part of the work; for the interpretive version, no existing control sits in the path.

The acting system cannot lift its own gate. It can request escalation; it cannot grant itself the authority to proceed. Override is a separately owned, separately logged path - otherwise the gate is theatre. And every pass through the gate writes its own record: what was relied on, what was excluded and why, what the gate decided, what the system then did. That record is the evidence, produced as part of the act rather than reconstructed after it.

A record reconstructed after the act is not this. A model registry, a policy library, a control dashboard can support admissibility, but they are not it unless they can test the standing of the relied-on claims and stop the act for that reason before it commits. For advisory and low-consequence work, after-the-fact records may be enough; the hard claim is narrower. Where a delegated system commits a material act without ordinary human approval in the path, if nothing in that path could have stopped the act on the standing of the claims it relied on, the institution has documentation, not admissibility.

Why it is not already enforced

If the invariant is this concrete, why is it not already enforced?

Not for lack of work, and the honest answer starts there. AI governance standards - ISO 42001, the EU AI Act, the NIST framework - define the obligations: risk management, transparency, traceability, human oversight. Agent frameworks provide the execution: memory, state, observability, policy controls, kill switches. Inside institutions, model risk management, GRC platforms, data lineage, policy-as-code engines, and entitlement systems are real and serious, and some already sit in the operating path - a rules engine refuses a transaction, an entitlement check blocks an action, a workflow gate holds an approval.

These are not unserious, and they are not wrong. They are necessary. They are also organised around other objects. The standards say what to do. The agent frameworks say how to run. The control systems govern the model, the data, the user, and the workflow state. The pieces of claim governance exist too: a lineage tool tracks a source, a data-quality system scores it, a policy engine tests a predicate. What is uncommon is not any one of those pieces. It is the discipline of treating the relied-on assertion as something the action path has to test - maintained as live state, checked against the consequence before the act commits. That obligation has an architectural shape: a control that can be satisfied by periodic review stays governance; a control that has to hold in the path of the act becomes part of the architecture. For delegated AI of the kind this argument is about, this one crosses that line.

This is not a claim that incumbents cannot build it. They can, and some will - into a workflow engine, a decision platform, a model gateway, or assembled by an institution's own architects. The question is not who builds it; it is what counts as having built it. And the test is about what the system must be able to do, not how it is wired. Four failures tell you it has not. If it cannot stop an action when the basis that action depends on has changed since it was approved. If a claim's authorisation to be acted on cannot be withdrawn by new information without someone manually intervening. If the actor can proceed without the gate, or grant itself the authority to. If the only record that the basis was sound is one assembled after the act. A platform that avoids all four has built the layer, whatever it calls it - and the deeper test is whether the claim and its standing are first-class in that platform, as native as a user or a transaction, or bolted on as fields the workflow happens to carry. The first is the layer. The second is a description of it.

That also settles the obvious comparison. An operational ontology - a knowledge graph, a master-data hub, the kind of substrate a platform like Palantir provides - can carry every field a claim needs: provenance, timestamps, confidence, conflict markers. The question was never whether the data model can hold those fields. It is whether the system enforces the invariant - whether claim standing is a live precondition of action, or descriptive metadata attached to objects the workflow already means to use. An operational ontology that enforces the invariant before commit has become the substrate for this layer. One that does not has a richer data model and the same gap. The substrate is welcome. What it has to enforce is the invariant.

There is one field this is most easily confused with, and it deserves its own paragraph: AI safety. Safety and the AI control agenda - alignment, evaluations, interpretability, monitoring, runtime limits - increasingly reach into the deployment setup, not only the model. The mechanisms overlap with what the invariant needs: gates, monitors, escalation. So does the ground - control work plainly governs actions, not only behaviour. A control architecture that tests a claim's standing before an action commits is, on that move, enforcing the invariant, and that is the point rather than a problem: admissibility is not a rival discipline or a separate stack, and if a control architecture absorbs it, the thesis is confirmed, not refuted.

What does not collapse is the question each one answers, and the regime that judges the answer. Safety asks whether the system can be kept inside an acceptable behavioural envelope, under error and adversarial pressure - and its failures are judged as the system behaving badly. Admissibility asks whether, for this act, the institution had a defensible basis to rely on what the system produced - and its failures are judged as the institution acting without one. A model can be perfectly safe and the institution still act on a policy reading that was superseded yesterday: nothing about the model misbehaved, and the institution still had no warrant. Safety is judged against the system. Admissibility is judged against the institution. Alignment does not confer the institution's warrant; the institution does. The invariant is the runtime test that the warrant was in place.

Why regulated industries, and why now

The invariant has to be enforced where it is a hard constraint, and that is regulated industries - not because the problem is unique to them, but because there the requirement is external, tested, and non-negotiable. A supervisor, an auditor, a court, or an affected party can ask - and in the hard cases will - what the institution relied on and why that reliance was permitted. A version that survives there has met the hard form of the problem.

And the timing has converged. Agentic systems are being pushed from advisory roles toward delegated ones, so the gap and the demand arrive together. DORA is in force; the EU AI Act's high-risk obligations are moving into application; supervisory expectations on model risk are being rewritten for AI. The names differ by jurisdiction - model risk guidance, clinical safety regimes, public-sector accountability rules - but none of these instruments mandates a claim store or a gate. What they do is raise the cost of being unable to show, after a delegated act, what it relied on and why that reliance was permitted - and that cost is what makes the question unavoidable. The argument does not stand on any single deadline. If a timeline slips or enforcement starts soft, the demand still arrives - through board accountability, through audit, through the plain fact that no executive wants an autonomous system acting on stale or unauthorised reasoning. Regulation makes the gap visible first and hardest. It is the forcing function, not the foundation.

This is falsifiable, and it should be. By delegated action I mean a system that commits an externally meaningful act - approving a payment, issuing a notice, changing a limit, closing an alert - without ordinary human approval in the path. The thesis is wrong if regulated institutions can run delegated AI of that kind at scale, accepted by their supervisors, on the controls they already have - model governance, workflow approvals, entitlement checks, policy-as-code, audit logs - with no mechanism that does what I have described: an individually addressable assertion, used as a basis for action, whose standing can change after approval and stop the act before commit. To be a real test it has to be observable, so the non-examples matter. A generic audit log does not count - it is written at decision time and cannot stop anything. A data-quality flag refreshed overnight does not count - its standing cannot move between approval and act. A workflow approval does not count - it gates the case, not the assertion. If institutions reach scale on those alone and supervisors accept it, I am wrong. A nearer-term version of the same test: watch whether the institutions now moving delegated use cases through audit add a pre-commit check on the standing of the specific assertions relied on, or whether they pass on documentation alone. I do not think they pass on documentation alone - because the reviewer who used to hold the basis is exactly what delegation removes - but that is the test, and it does not turn on anyone using the word claim.

Two questions

Step back, and the field is working on two questions at once, and mostly treating them as one. The first is what the machine can do. It has the funding, the names, and the attention. The second is what the institution may rely on. The two are not independent - a better-calibrated model lowers the burden the invariant imposes, and the invariant shapes what capability is worth building - but they are different questions, and for institutions deploying under supervision, the second decides the outcome. A more capable model an institution cannot rely on is a more capable model it cannot use. Most are funding the first hard and assuming the second will be there when they reach for it. It will not be, unless it is built deliberately, into the path the action travels.

Admissibility has no finish line

One thing is left open. Capability is narrated as a race toward a destination - human-level performance, whatever the end state is called. Admissibility has no destination. There is no point at which an institution is finished proving what it may rely on; the work moves with the regulation, the institution, and the agents operating through it.

That can sound like a weakness - an open commitment with no terminal state. It is the opposite. A destination is something an institution can fall behind on. Admissibility is something it gets better at: the validated claims, the tested authority rules, the evidence patterns a supervisor has already accepted compound into an institution that can move faster precisely because it can defend what it does. The cost is real and front-loaded, and it is not mainly technology. It is the work of naming who owns each material claim, turning the institution's reliance rules into something executable, putting the gate in the action path, and running the exception queue when claims decay or conflict. Set against it is a cost institutions are already paying: the AI that cleared its evaluation two years ago and still has not left pilot. And individual use cases do reach a stable state - a use case is admissible when its claim set, authority rules, context capture, and evidence record are executable and tested. What has no finish line is the portfolio, not the implementation.

The test of where an institution stands is simple, and it is organisational before it is technical. Take one use case it wants to move up the ladder. For the decision that use case would make, ask: what claims does the act rest on, and who owns them; what authority does the act require; what context would have to be recorded before it; what evidence would it produce. The failure that matters is not an imperfect answer - it is no named owner for the answer at all. But answering the questions on paper is only the start. The harder test is whether those answers can be made executable in the path of the action - whether the system can test the claims it depends on and stop itself when they cannot bear the consequence. If they cannot, the institution is not blocked by model intelligence. It is blocked by admissibility, and a better model alone will not move it.

The first concrete move is small. For one delegated use case, inventory the claims the act depends on, name an owner for each material one, set the consequence threshold, and run the gate in shadow - recording what it would have stopped - before it is allowed to block anything in production. That is enough to find out whether the institution has the start of admissibility or only the documentation of it.

The advantage - and at first it will simply be the ability to move at all - will go to the institution whose AI can act under supervision, produce its evidence as it acts, and keep moving without losing track of what it is allowed to rely on. That is admissibility.