FERZ is not Guardrails

A guardrail may be deterministic or probabilistic, and it may inspect content, structured outputs, tool calls, or proposed actions. None of that classifies it. What classifies a control is what its result means and how release is conditioned on it. A guardrail's result is an observation about a declared condition: this input matches a pattern, this output fails a schema, this tool call is not on the allowlist, this behavior scores as anomalous. Its positive form is the absence of an objection. A PASS, a validation success, or silence from a check that did not apply does not become an action-bound ALLOW merely because the underlying check is deterministic.

The release condition follows from the result semantics. A supervisory stack standing alone releases an action when no layer objects, or, in the stricter variant, when every declared layer returns PASS. Unanimous PASS establishes that every declared objection check returned a result; it does not establish that policy was evaluated over the action. A runtime authorization boundary releases only if a policy-grounded, action-bound verdict of ALLOW exists before execution, evaluated over the canonical action, the applicable policy and version state, the governed state, and the authority chain. The release condition, not the accuracy of any check and not its determinism, decides the class.

Coverage is a property of the release topology, not of the layer count. The transitions that matter are the ones a demonstration rarely shows: timeouts, unavailable services, fallbacks, retries, resolution paths, alternate tools, and direct execution paths. A boundary is fail-closed only across a declared execution-path scope in which every in-scope release transition depends on ALLOW. Multiple enforced veto points reduce the likelihood that a detected condition reaches execution; they do not establish complete mediation of every transition. A stack with five vetoes and one ungated retry is not fail-closed.

Governed state is what a per-action check cannot see. Cumulative limits, pending authorizations, prior consumption, and current authority are terms of the policy, not properties of the isolated action. A layer that evaluates each proposal on its own can pass five transfers that together exceed a daily limit while every check performs correctly, as the concurrency example below shows. An authorization boundary binds governed state, including pending authorizations, into the determination.

The evidence artifacts answer different questions. Layer outputs record what the controls observed: a trigger, a score, a validation result, a PASS. An authorization artifact records why this specific action received this verdict under the bound policy, governed state, inputs, and authority, and is sufficient for an independent party to reconstruct the verdict without access to the governed system. Halt records and authorization verdicts are not points on a spectrum, as the doctrine establishes: a halt is not a verdict. A more accurate check remains a check, and a deterministic check remains a check. What changes the class is a release condition that depends on an action-bound ALLOW.

The structural claim follows. Supervisory layers and a runtime authorization boundary compose in a complete AI safety stack: the layers evaluate the conditions they are configured for, and a boundary may consume their validated outputs as verdict-determinative inputs, with release depending on its ALLOW. Composed that way, the layers are supporting controls within an authorization architecture. Aggregated on their own, they release on non-objection, and calling that aggregation AI governance in the authorization sense is a category error the doctrine has already addressed at the level of foundational distinctions.

The strongest defense of guardrails is not that any one filter is the authorization control. It is that authorization emerges from the stack as a whole: content filters, schema validators, allowlists, anomaly detectors, and review queues, each catching what the others miss, together constitute the permission to act. That is a composition claim, and Layering Is Not Authorization (Meyman, 2026) answers it at its own level, by release semantics rather than by product label. A system is within the target class when action release is conditioned on aggregated non-objection, whatever its components or outputs are called.

The two release conditions are not equivalent. A layered stack releases an action when no layer objects:

A stricter stack requires every declared layer to return PASS, which establishes that every declared objection check returned a result, and nothing more:

An authorization boundary releases only if a policy-grounded, action-bound verdict of ALLOW exists before execution:

where P is the applicable policy and version state, C(a) is the canonicalized action, S is the governed state, and H is the authority chain. PASS means that no participating layer detected a reason to object. ALLOW means that the governing authority affirmatively permitted the proposed action under the bound conditions. Increasing the number of PASS signals does not change PASS into ALLOW.

The note concedes everything layering accomplishes and tests six arguments that it is sufficient: coverage accumulation, defense-in-depth reliability, residual-risk sufficiency, heterogeneous controls, fail-safe accumulation, and evidence accumulation. Each is granted its strongest form. A larger detection set does not establish that every released action was permitted. Lower failure rates are empirical evidence of reliability, not analytical proof of authorization. Heterogeneous outputs do not compose into one policy-grounded verdict, by inventory or by aggregation. Five vetoes and one ungated retry are not fail-closed. Aggregated logs show what the layers observed, not why a specific action received a specific verdict. Only the reliability and residual-risk arguments depend on probability; the other four hold against a stack of perfectly deterministic validators.

The residual-risk argument deserves its own answer, because it accepts the classification and disputes its consequence: if a dense stack makes harmful release unlikely enough, and the remainder is insured, why add an authorization boundary? An institution may decide that a runtime authorization boundary is unnecessary for a declared low-consequence scope in which the governing authority requires no action-specific permission. That is a scope and risk-acceptance decision. It does not make the stack an authorization boundary. Risk acceptance asks whether the expected harm across a class of operations is tolerable; authorization asks whether this proposed action is permitted under the applicable policy, governed state, and authority. Insurance is a risk-transfer response: it reallocates financial consequences after a covered loss and cannot establish that the underlying action was authorized. Scheduled air-carrier operations under 14 C.F.R. Part 121 illustrate the distinction: extensive safety controls do not displace the operation-specific, jointly signed dispatch release.

One failure can be shown exactly. A policy permits transfers totaling no more than $10,000 per day. Five $3,000 transfers are evaluated concurrently, and each passes every content, schema, anomaly, and destination check. If prior consumption and pending authorizations are outside the release determination, all five may release: $15,000 against a $10,000 limit. Nothing malfunctioned. A release condition that examines each action in isolation cannot enforce a rule whose terms are cumulative, however many layers examine the isolated action.

Layering and authorization are not mutually exclusive. When a boundary materially consumes the validated outputs of the layers, every release path depends on its action-bound ALLOW, governed state is bound into the determination, unresolved permission becomes a blocking verdict, and the verdict can be independently reconstructed, the layers function as inputs within an authorization architecture. Their stacking is not what established authorization. The full argument, with its five-question diagnostic and failure witnesses, is in the technical note (DOI 10.5281/zenodo.22267761) and summarized in Layering Is Not Authorization.

Each question has a failure witness. Within a declared scope: an in-scope effect executed without a matching action-bound ALLOW; a release path on which an in-scope effect executes around the boundary; a cumulative determination that does not account for pending authorizations on which policy depends; unresolved permission that proceeds without a separate resulting verdict; or a reconstruction under the declared replay mode that does not reproduce the verdict. Each defeats the corresponding claim.