Runtime Admissibility

Runtime admissibility is the property that a proposed action is currently permitted — given the present state of conditions, authority, evidence, and risk — re-evaluated at the moment of execution rather than the moment of decision. It is the architectural primitive that distinguishes governed execution from automated execution: a system that approves but does not re-evaluate at the commit cannot guarantee the outcome was permitted when it occurred; one that re-evaluates can.

Because state changes between approval and execution. Documents expire, sanctions lists update, authority lapses, conditions fail, exposure shifts, and fraud signals emerge. A decision approved earlier may no longer be permitted when the action attempts to commit. Design-time policy checks cannot see runtime state — only an evaluation at the moment of action can determine whether the action is still admissible against current reality.

Four dimensions are checked against the policy that authorized the decision: current state (has reality changed since approval), policy (do the rules still permit it), authority (does the actor still hold the right to act), and context (have risk signals, timing windows, or dependencies changed). Supporting evidence — documents, signals, conditions — is checked for whether it is still intact at the moment of action.

Admissibility fails when any dimension has changed in a way that invalidates the original authorization: an expired or missing document, a policy or sanctions update, lapsed or reduced authority, a failed condition, a crossed exposure threshold, or a new fraud signal. The decision was correct under the state known at approval; it is inadmissible because the state it would now act upon is different.

Yes — that is the entire point. Approval captures admissibility at a moment in the past; runtime admissibility tracks whether it still holds now. An action admissible at 9 AM can become inadmissible by 2 PM. For actions that stay in flight, admissibility is evaluated continuously, so a change at any point before the act invalidates it before it can commit on stale assumptions.

At minimum at the commit boundary, before the action binds. For actions that remain in flight over time — held positions, open commits, long-running disbursements — admissibility is re-evaluated continuously for the duration of the obligation, so any state change between evaluations invalidates the action. Continuous evaluation is what makes Decision Infrastructure a runtime layer rather than a one-time checkpoint.

Yes. Every admissibility outcome — ALLOW, HOLD, DENY, ESCALATE — is produced deterministically and recorded with the state, conditions, authority, and policy that produced it. Because the evaluation is captured in-line, you can see exactly why an action was permitted, paused, blocked, or escalated. Admissibility is not a model's opinion; it is a deterministic, explainable verdict against current reality.

Yes. Each admissibility evaluation produces evidence at the moment it occurs — the inputs, the checks, the policy version, the authority, the timing, and the verdict — as an immutable, reconstructable record. Because outcomes are deterministically replayable, the same inputs reproduce the same result, so auditors and regulators can review not just that an action happened but whether it was permitted when it happened.

Policy enforcement checks whether a decision was made under acceptable rules — a design-time check. Runtime admissibility checks whether that decision is still permitted right now, against the live state of the systems it will act upon — an execution-time check. Policy is necessary but not sufficient: a decision can satisfy policy at approval and still be inadmissible at execution because reality has moved.

It eliminates the failure mode where approved actions execute against state that has drifted — the stale approval, the post-authorization sanctions hit, the expired condition, the lapsed authority. By holding, denying, or escalating no-longer-admissible actions before they bind, and evidencing each outcome, it converts silent, accumulating risk into governed, explainable events — and prevents the auditable failures that survive every after-the-fact control.

Every commit attempt produces one of four outcomes: ALLOW (the action proceeds and evidence is captured at binding), HOLD (revalidation is required before binding — the action is paused, not failed), DENY (the action is blocked, with reason and current state recorded), or ESCALATE (higher-authority review is required). The semantics are deliberately narrow: admissibility is a binary property with structured exceptions.

The commit boundary is the architectural location where intent becomes consequence; runtime admissibility is the evaluation performed at that location — the check that determines whether the action is permitted to bind. The boundary names the place, admissibility names the property, and binding names the act. Distinguishing the three is what keeps execution governance architecturally coherent.