Governance Doctrine
The Concepts section defines the vocabulary FERZ uses for runtime authorization. This section asserts the architectural positions FERZ takes about that vocabulary. Concepts answer "what is this?" Doctrine answers "what follows from how this is built?"
Governance is the market category; authorization is the enforcement mechanism. This is not an observability framework, an identity and access management overlay, or a policy engine, and none of those categories alone establishes the full authorization architecture. It is a category of its own: runtime authorization architecture for AI actions, producing pre-execution verdicts represented in authorization artifacts sufficient for independent reconstruction. The doctrine pages exist to distinguish that category from adjacent ones without forcing readers to reconstruct the argument each time.
The doctrine is established across the FERZ corpus, with foundational arguments in On the Impossibility of Observability-Based Authorization, The Authorization Boundary, and The Authorization Non-Substitution Principle (Meyman, 2026) and supporting analyses in the papers cited in References below. Each doctrine page distinguishes its approved canonical statement from the explanation surrounding it. Canonical statements are reproduced verbatim across FERZ publications and should be quoted exactly when presented as canonical wording. The surrounding analysis may be summarized, attributed, or excerpted without being represented as an additional locked formulation.
The organizing statement
The positions are organized by that statement. The first group states what is not authorization: mechanisms whose characteristic outputs, taken alone, do not establish that a specific proposed action received the required pre-execution determination. The second group states what is not a runtime authorization boundary: controls that evaluate, mediate, bound, or stack without, by themselves, making release depend on an action-bound verdict beyond the governed system's reach.
What is not authorization
Observation, interruption, and standing authority can support runtime authorization. Their characteristic outputs, taken alone, do not establish that a particular proposed action received the required pre-execution authorization determination.
Visibility into AI behavior is necessary for oversight but does not constitute permission to act. A system that logs everything and authorizes nothing has not performed authorization.
Read the doctrine →Monitoring describes actions after they occur. Authorization decides whether they occur at all. Treating the two as interchangeable collapses the distinction between observation and control.
Read the doctrine →Stopping execution is an event. A verdict is a decision with reproducible logic, bounded scope, and a verifiable authorization artifact. Systems that halt without producing a verdict cannot be audited, replayed, or appealed.
Read the doctrine →Authority belongs to actors; action-level authorization belongs to proposed actions. An agent operating under the broadest delegation has not, by that fact, had any specific action authorized.
Read the doctrine →What is not a boundary
Each of these may be a component of a runtime authorization boundary. None is one by itself: a boundary exists only where covered execution depends on its action-bound verdict and the governed system cannot bypass it or control what it relies on.
A control the governed system can route around, suspend, or reconfigure does not govern execution. Non-bypassability is not a feature of a governance architecture. It is the condition under which the architecture is governance at all.
Read the doctrine →A runtime authorization boundary can be in every execution path and still be controllable by the system it governs. Being in every path is not the same as being beyond reach.
Read the doctrine →A pre-execution callback may be a genuine enforcement component. It is not, by virtue of its position in time, an authorization boundary.
Read the doctrine →Containment bounds where a system can reach. Authorization decides whether an action is released. Even an action that stays inside its sandbox can exceed the authority delegated to the agent.
Read the doctrine →A layered stack releases on non-objection; an authorization boundary releases only on an action-bound ALLOW. No count of layers converts one into the other.
Read the doctrine →The combined canonical form
This is the FERZ Governance Doctrine in its compressed form. It appears verbatim in the corpus and in FERZ external materials. The doctrine pages above expand these clauses, the definitional position on authority, and the positions on what a boundary requires into their full arguments, counter-positions, and architectural implications.
Why these positions matter
The AI governance market currently uses one word for several categorically different things. "Governance" is attached to content filtering, logging, human review queues, model fine-tuning, and policy documentation, among other practices. Each of these practices has a legitimate role. None establishes runtime authorization merely by being present, and combining them does not automatically supply what is missing. The combined arrangement must be evaluated against the authorization requirements: an action-specific pre-execution verdict, a non-bypassable, fail-closed boundary governing release, and an authorization artifact sufficient for independent reconstruction.
The doctrine pages exist so that buyers, regulators, and engineers can distinguish authorization architecture from adjacent categories without having to reconstruct the argument each time. They are written for citation. The canonical wording is fixed; the surrounding argument can be excerpted; the structural claim can be quoted verbatim in regulatory submissions, academic work, and procurement documentation.
Frequently asked questions
Concepts define the vocabulary used in runtime authorization architecture, such as execution-time authorization, the authorization artifact, and ABSTAIN. Doctrine asserts the structural positions FERZ takes about that vocabulary, such as observability is not authorization. Concepts answer "what is this?"; doctrine answers "what follows from how this is built?"
Structural claims. The positions on what is not authorization rest on the corpus's information-sufficiency result: observation can inform a verdict but cannot supply governing information it does not contain, and neither evaluation before execution nor reconstructability alone establishes authorization. The positions on what is not a boundary rest on the boundary-completeness and enforcement-independence conditions stated in The Authorization Boundary, The Hook Is Not the Boundary, and Enforcement Integrity in Pre-Execution Authorization. The definitional position rests on Authority versus Authorization: A Definitional Framework for AI Governance, which distinguishes authority, delegation, policy, authorization, and enforcement as separate architectural concepts.
Audit logs record what happened. An authorization artifact represents a verdict rendered before the action occurred and supports its independent reconstruction. A log may preserve such an artifact; a log that records only what occurred, however complete, does not establish that any action was authorized before it ran. The distinction is developed in the FERZ Governance Taxonomy.
Yes. The doctrine is published in canonical form precisely so that buyers, regulators, and engineers can cite it without paraphrase. The compressed three-clause form, the organizing statement, the canonical block on each doctrine page, and the underlying corpus papers are all designed for direct citation.
References
FERZ, Inc. (2026). Governance Doctrine. https://ferz.ai/governance/doctrine
BibTeX
@misc{ferz2026doctrine,
author = {{FERZ, Inc.}},
title = {Governance Doctrine},
year = {2026},
url = {https://ferz.ai/governance/doctrine},
note = {FERZ Knowledge Base}
}