Deterministic Authorization: Same Label, Different Requirements
What the claim leaves out, and who is expected to supply it.
"Deterministic authorization" does not establish a common level of capability. A control can evaluate a structured proposed action against explicit rules and block execution within a declared workflow. Within that workflow, with a stable action vocabulary, structured inputs, one execution path, and stable state, it delivers pre-execution control. This makes execution conditional on a pre-execution decision. Monitoring after the fact does not supply that control by itself. The question is what that control establishes, and what remains for someone else to supply.
Two systems carrying the same label can differ in what their evaluation represents, in what execution depends on, and in what evidence they leave behind. The label does not establish equivalent capability. The requirements do.
Five questions screen the claim
The executive guide to this series gives a board, a general counsel, or a chief risk officer five questions that need no technical background to ask. They are screening paraphrases of the five tests, not the standard's wording.
- Stop: Can an authorized human halt the system before a governed action produces an effect?
- Ownership: Which named role owns each class of consequential action?
- Replay: Can an independent party reconstruct the authorization verdict for a past action using the required materials?
- Escalation: When evaluation yields indeterminacy or policy requires human authority, does ABSTAIN keep execution blocked pending authorized resolution?
- Provenance: Is the origin of the decision inputs established, and is that origin admitted under the applicable policy?
Each question has the shape of a passing answer and a recognizable set of deflections.
Those questions screen a claim. An unanswered question leaves the corresponding requirement unestablished. They are not a conformance assessment, which is made against the published standard and its conformance materials, and they are not the end of the inquiry.
The question the five tests do not settle
A system can answer all five and still evaluate the wrong thing. Repeatability, ownership, reconstruction, fail-closed ABSTAIN, and established input origin are properties of the boundary and its evidence. None of them says whether the evaluation inside the boundary addressed the conditions on which permission turns.
That is a separate question: did the evaluation address the conditions material to permission, within the declared scope? It is not a sixth test. It is the question that decides whether a verdict, however reliably enforced, was about the right thing. A recipient allowlist checked on every path, with a reconstructable artifact and a named owner, is a sound control. It is not an adequate one if the requirement turns on purpose, classification, delegated authority, and evidence freshness, because the evaluation never represented those conditions.
One release, four cases
An agent proposes to release an extract of a customer dataset to an external recipient. The enterprise's policy permits the release only when the recipient is approved, the purpose is one the recipient may receive data for, the data classification is within the recipient's clearance, a delegated authority covers this recipient, purpose, and classification, and the supporting evidence is current.
A bounded gate checks the recipient against an allowlist. Every ALLOW it returns is deterministic, reproducible, and inadequate to that policy. An evaluation that represents the five conditions returns ALLOW when all hold, with the bound inputs and policy version cited; DENY when the classification exceeds the clearance, with the failing condition and both values cited; and ABSTAIN when the delegation is silent on this purpose and the policy does not say whether silence excludes, with execution blocked pending an authorized human resolution. Nobody has been denied, and nobody has been permitted. If the person who resolves it holds the authority to do so, the resolution is a new authorization event with its own artifact. If the evaluation cannot run at all, no verdict is issued, and execution stays blocked.
The fourth case shows what analysis of the policy adds to evaluation of a request. One rule requires an approved transformation before external release. Another prohibits that transformation for the same data class and purpose. Each rule admits permitted cases on its own. Under conjunctive application, the two rules leave no permitted release for the declared class. Formal analysis can establish that incompatibility before an individual request arrives. Requests in that class receive DENY because permission is conclusively unavailable. Where the policy instead leaves the relationship between conflicting rules unresolved and requires authorized resolution, the verdict is ABSTAIN. The evaluator supplies neither precedence nor authority. Evaluating one request does not by itself establish this class-level result; that requires analysis of the combined policy.
Five substitutions
The following answers are illustrative and attributed to no one. Each sounds complete. Each answer concerns something narrower than the full authorization claim. Even that narrower proposition requires evidence. The discipline is the same in every row: identify what the answer establishes, name what remains unresolved, and make the allocation of responsibility visible. Responsibility carried by the customer is not a defect. Undisclosed responsibility, unsupported assumptions, and evidence that enforcement never consumes are the defects.
| What is presented | What the answer could establish, if substantiated | What remains unresolved | What to ask |
|---|---|---|---|
| "The same inputs always produce the same verdict." | Repeatability under fixed conditions. | Whether the inputs represent every condition material to permission. A repeatable verdict can consistently omit the condition that decides the case. | Which conditions and interactions does the evaluation represent, which are assumptions, and who holds those assumptions? |
| "We check every tool call." | Coverage of the tool-call path. | Whether any other path within scope reaches the governed effect: an API, a scheduled job, an operator, an alternative credential. A successful check on one path establishes nothing about an uncontrolled path to the same effect. | What execution paths are in scope, what evidence shows that none bypasses authorization, and who is responsible for paths the offering does not cover? |
| "Every decision is logged and signed." | The integrity of the signed record, subject to key attribution and custody. | Whether authorization preceded execution, whether an independent party can reconstruct the verdict, and whether the executed action matched the authorized one. A signature, by itself, does not establish any of these broader claims. | What supplies the missing evidence, who is responsible for it, and does execution depend on it? |
| "Uncertain cases go to a human." | Routing to a person. | Whether execution stayed blocked while the person was notified, whether the person holds authority to release it, and whether the resolution is recorded as its own authorization event. | What blocks execution, who may resolve ABSTAIN, and what artifact records the resolution? |
| "Policies come from the customer." | The source of the rules. | Their versioned meaning, the applicable version at decision time, the semantics under which conflicting rules combine, and whether they cover the requirement at all. | What must the customer establish before the rules are used, what does the system validate, and where is that division of responsibility written down? |
If a supplier offers any of these as sufficient evidence of authorization, the claim remains unestablished. That says nothing about what any supplier can or cannot do. It says what the answer, standing alone, has shown, and it asks what will supply the rest.
"Every layer returned PASS" leaves a further question: what establishes that the layers jointly address the same proposed action under compatible assumptions, and that execution depends on their combined result? "The platform is certified" requires the certificate's scope and criteria: what do they establish about authorization of this action in this deployment? Neither answer alone closes those questions.
The organizing question is therefore not whether an offering is real. It is what has been left outside the claim, and who is expected to supply it. Meaning, policy consistency, authority, path coverage, and the materials needed for replay can each be pushed onto the customer while the offering keeps a broad label. Where the customer demonstrably carries that work, the allocation should be stated and priced. Where the allocation is unknown, it should be demanded before deployment, not discovered in discovery.
FERZ's position
The same questions apply to FERZ. FERZ treats authorization as a composed architectural requirement, not a feature. Its target architecture takes versioned meaning, explicit policy conditions, deterministic evaluation, authorization evidence, and execution enforcement as obligations that must compose at the runtime authorization boundary: meaning is stabilized and versioned upstream of enforcement rather than invented at it; the target architecture specifies analysis of the versioned policy's consistency and reachable states, alongside deterministic evaluation of individual requests; evaluation is deterministic over bound inputs and returns ALLOW, DENY, or ABSTAIN with cited grounds; the tamper-evident authorization artifact carries or references what an independent party needs to reconstruct the verdict; and the target architecture is designed to make execution unavailable without a valid, action-bound ALLOW and its required artifact on every path within the declared scope. Those are design commitments. Implemented capability, observed performance, and conformance are separate claims, and FERZ has published the test its own demonstration program must pass before it reports passing it.
Two ways in
Start here: the executive questions. Deterministic AI Governance: An Executive Guide to Runtime Authorization and Spotting the Fake, version 2.1. The five questions, the passing answers, the deflections, and the minimum bar to require in writing. Download from Zenodo (concept record 10.5281/zenodo.21864146).
Go deeper: requirements, evidence, and provider evaluation. What Deterministic Authorization Requires: Runtime Boundaries, Formal Evaluation, and Authorization Evidence, version 1.0. The enforcement obligations that make a gate a boundary, the formal capabilities demanding requirements call for, the evidentiary limits of the artifact, the full release example, and the provider evaluation instrument with its measurement rules. Download from Zenodo (concept record 10.5281/zenodo.22749462).
For conformance, the reference is the Five Tests Standard, specification v1.2.0 with its conformance bundle; Provenance conformance remains deferred in that edition, and no claim of machine-checked Provenance conformance should be accepted against it.
Ask the better question in the next meeting: not "is it deterministic," but "what did it evaluate, what does execution depend on, what evidence establishes each claim, and who supplies what the claim leaves out?"