Governance

Glossary

This glossary collects the canonical terminology used across the FERZ corpus, doctrine, and architectural comparisons. Each term is defined as it is used in FERZ publications. The glossary is organized in five sections: verdicts and authorization decisions, architectural commitments, frameworks and corpus concepts, determinism pathways, and contrasted categories that share surface features with FERZ but operate in different architectural classes.

Definitions are derived from the FERZ corpus and from the canonical wording locked across the doctrine and comparison pages. Where a term originates in a specific paper, the paper is cited in the entry's see-also line and listed in the references below. The two corpus papers underlying the bulk of the framework are The Authorization Artifact Test (Meyman, 2026; DOI 10.5281/zenodo.20013582) and A Taxonomy of AI Governance Approaches (Meyman, 2026; DOI 10.5281/zenodo.18275969). FERZ itself is a runtime AI-action authorization architecture with built-in action canonicalization, governed state, ABSTAIN-with-override semantics, and a proof-carrying authorization artifact.

Verdicts and authorization decisions

The objects produced by FERZ at the AI action proposal boundary: the canonical three-verdict space, the artifacts in which each verdict is represented, and the explicit override path for fail-closed cases.

ABSTAIN verdictABSTAIN
The third verdict in the FERZ canonical verdict space. ABSTAIN is returned in two cases: the indeterminate case, where the applicable authorization state does not resolve the proposed action to ALLOW or DENY, and the authority-required case, where the governing policy reserves the action or action class for a named human authority. In both, ABSTAIN is fail-closed: execution is blocked pending authorized human override. An authorized resolution supplies authority-bound input to the runtime authorization boundary, which emits the resulting ALLOW or DENY verdict for the held action. Each verdict is represented in an authorization artifact from which it is independently reconstructable.

See alsoAuthorized override · Fail-closed design · Verdict space · FERZ is not Human-in-the-Loop

ALLOW verdictALLOW
The verdict in the FERZ canonical verdict space that permits a proposed action to execute. Issued when encoded policy resolves the action as authorized against the current governed state and policy version. Represented in an authorization artifact from which the verdict is independently reconstructable by third parties.

See alsoAuthorization artifact · Verdict space

Authorization artifact
An authorization artifact is a tamper-evident record that represents a verdict such that the verdict is independently reconstructable from the bound inputs, the policy and version state that applied, the authority chain, and the proposed action, and such that the origin of the inputs on which it rests is established. FERZ represents every verdict in such an artifact. On first reference in formal contexts the full name is "proof-carrying authorization artifact"; subsequent references use the short form.

See alsoProof-Carrying Decisions · Policy version · Canonicalized action specification

Authorized override
An explicit, identified, role-scoped act by a named human authority that supplies authority-bound input to the runtime authorization boundary for an action held at ABSTAIN. The boundary evaluates that input and emits the resulting ALLOW or DENY verdict for the held action; the override does not itself release execution. The resulting verdict is represented in an independently reconstructable authorization artifact that records who supplied the input, on what authority, under which policy version. Any policy amendment is a separate, independently authorized act. Distinguished from review-only human-in-the-loop by the Override Asymmetry.

See alsoABSTAIN verdict · Override Asymmetry · Human-in-the-loop

DENY verdictDENY
The verdict in the FERZ canonical verdict space that blocks a proposed action from executing. Issued when encoded policy resolves the action as not authorized against the current governed state and policy version. Represented in an authorization artifact from which the verdict is independently reconstructable by third parties.

See alsoAuthorization artifact · Verdict space

Proof-Carrying DecisionsPCD
A Proof-Carrying Decision (PCD) is the corresponding vendor-neutral evidence object in 5TS: the record from which a governance verdict is reconstructed under the standard's replay modes. FERZ authorization artifacts correspond to this evidence object. The Authorization Artifact Test requires a pre-execution verdict represented in an independently reconstructable authorization artifact; 5TS expresses that evidence object as a PCD.

See alsoAuthorization artifact · The Authorization Artifact Test · Ex-ante

Verdict space
The FERZ canonical verdict space consists of exactly three verdicts: ALLOW, DENY, and ABSTAIN. There is no separate ESCALATE verdict. ABSTAIN with authorized resolution is the canonical mechanism for actions that policy does not resolve or reserves for a named human authority; the resolution is input to the boundary, and the boundary emits the verdict.

See alsoALLOW verdict · DENY verdict · ABSTAIN verdict

Architectural commitments

The structural properties that define FERZ as an architectural class. These are commitments, not configurations: they cannot be disabled by setting.

Action canonicalization
The transformation of a proposed AI action into a canonical specification that allows policy evaluation to be deterministic and reproducible. Without canonicalization, the same semantic action expressed in different forms could yield different verdicts; canonicalization is a structural requirement of policy-based AI-action authorization and is part of the FERZ authorization-layer vocabulary.

See alsoCanonicalized action specification · Governed state

AI-action authorization
The class of decisions about whether a proposed AI action is permitted by encoded policy, evaluated against canonicalized action specification and governed state, before the action executes. The architectural class that FERZ exemplifies. Distinct from monitoring, observability, identity authorization, attack detection, content filtering, and review-only human-in-the-loop.

See alsoArchitectural class · Three Problems Taxonomy · Architectural Comparisons

Canonicalized action specification
The output of action canonicalization: a stable, structured representation of a proposed AI action that uniquely identifies the operation, its parameters, and its context. Used by FERZ as one of the inputs to policy evaluation and carried as part of the resulting authorization artifact.

See alsoAction canonicalization · Authorization artifact

Ex-ante
Before the fact; before execution. FERZ emits verdicts before execution and represents them in authorization artifacts. Contrasted with post-hoc systems (such as SIEM and AI Observability) that operate after execution. The ex-ante property is what distinguishes authorization-class systems from observation-class systems.

See alsoExecution-time authorization · Impossibility result

Execution-time authorization
The architectural commitment that authorization decisions are evaluated and enforced before the proposed AI action executes, not after. The authorization verdict precedes execution; if the verdict is DENY or ABSTAIN, the action does not execute. The opposite of post-hoc compliance reporting.

See alsoEx-ante · Runtime authorization boundary · Authorization is not monitoring

Fail-closed design
The architectural commitment that, when governance conditions are not met or cannot be resolved, execution is blocked by default. FERZ is fail-closed by architectural design rather than by configuration: there is no opt-in setting for fail-open behavior. Contrasted with monitor-only or alert-only systems where the default response to ambiguity is to allow execution.

See alsoABSTAIN verdict · Authorized override

Governed state
The structured representation of the system state that policy evaluation can reference. FERZ policy evaluation takes the proposed action specification and the governed state as inputs; the governed state determines which conditions apply to the action being evaluated. The state is versioned alongside policy and carried in the authorization artifact.

See alsoPolicy version · Authorization artifact

Policy version
The identifier of the policy snapshot active at the time of authorization. Authorization artifacts carry the policy version as part of their reconstructable evidence; this allows verdicts to be reproduced and audited against the exact policy that was in force, not against later revisions.

See alsoAuthorization artifact · Governed state

Runtime authorization boundary
The architectural surface at which authorization decisions are evaluated and enforced. In FERZ, this surface is the AI action proposal boundary: the point at which a proposed AI action would otherwise cross from intent to execution. The boundary is non-bypassable by architectural commitment.

See alsoExecution-time authorization · Fail-closed design

Frameworks and corpus concepts

The analytical frameworks and formal results developed in the FERZ corpus, used to evaluate architectures and to position the work relative to adjacent categories.

Architectural class
The category of system determined by what kind of decision the system makes, what artifact it produces, and what failure mode it exhibits. Architectural class is determined by function and structural conditions, not by labels or ancillary features. An adjacent system that adds a non-bypassable, fail-closed pre-execution authorization function becomes a composite architecture containing a genuine authorization layer. The architectural-class test, formalized in The Authorization Artifact Test, is the basis for the FERZ comparison set.

See alsoThe Authorization Artifact Test · Architectural Comparisons

Audit-stable meaning
The property that every governed decision remains evaluable, for as long as it must be retained, under the exact semantics that governed it at the moment it was made. Established in Versioned Meaning: How to Make Ontologies Audit-Stable (Meyman, 2026; DOI 10.5281/zenodo.18328587). It holds only when four invariants are satisfied: decision-bound semantics, non-retroactivity, reproducibility, and drift visibility. By binding each decision to an immutable semantic snapshot, it prevents a later change to a definition from silently restating a decision already made, the failure mode known as definition laundering. Audit-stable meaning is the semantic substrate beneath authorization, not the enforcement layer itself.

See alsoAudit-Stable Meaning (article) · The Authorization Artifact Test · Runtime authorization boundary

The Authorization Artifact TestAAT
A two-prong, regime-neutral test for ex-ante AI-action authorization, derived from the impossibility result (Meyman, 2026; DOI 10.5281/zenodo.20013582). Prong One (Pre-Execution Verdict): does the runtime authorization boundary emit a verdict before the proposed action executes? Prong Two (Independent Reconstruction): can an independent third party reconstruct that verdict without access to the governed system? The authorization artifact represents the verdict and carries the bound material necessary for reconstruction: the bound inputs, the policy and version state that applied, the authority chain, and the proposed action, with the origin of the inputs established. An architecture is an ex-ante authorization architecture only if both prongs are satisfied.

See alsoImpossibility result · Architectural class

Five Tests Standard5TS
A vendor-neutral published standard defining five necessary conditions for governed AI: Stop (halt before side effects), Ownership (named accountable authority), Replay (deterministic reconstruction), Escalation (transfer of control at policy boundaries), and Provenance (established input origin). Repository release v1.2.2; specification v1.2.0; conformance bundle v1.0.2. In specification v1.2.0, Provenance is normative, while Provenance conformance and full five-test conformance are not yet assertable. The v1.0.2 conformance bundle verifies Stop, Ownership, Replay, and Escalation. Current status is maintained in the repository at github.com/edmeyman/4ts-standard. The specification is licensed under CC BY-NC-ND 4.0, and the conformance bundle is licensed under MIT.

See alsoThe Authorization Artifact Test · Fail-closed design

Implicit authorization
The condition in which an AI pipeline makes release decisions, deciding what evidence is sufficient, what to surface, and what to withhold, without an explicit authorization boundary that owns those decisions. Because the decisions are made through retrieval heuristics, validators, and confidence thresholds, they are observation-class and bypassable: the system is default-release with retrospective checks. Implicit authorization has the surface of a release boundary without its architectural commitments; it is authorization in form, not in substance.

See alsoRuntime authorization boundary · Impossibility result · Ex-ante · The Authorization Trap

Impossibility result
The formal result, established in On the Impossibility of Observability-Based Authorization (Meyman, 2026; DOI 10.5281/zenodo.19647542), that authorization cannot be derived from observability alone. Observation-class systems cannot produce authorization-class artifacts; the architectural-class boundary is not crossed by adding observability features.

See alsoThe Authorization Artifact Test · Observability is not authorization

Override Asymmetry
The structural difference between ABSTAIN with authorized resolution and guardrails with review-only human-in-the-loop, established in The Override Asymmetry: Why ABSTAIN with Authorized Resolution Is Not Guardrails with Review-Only Human-in-the-Loop, v2.0 (Meyman, 2026; DOI 10.5281/zenodo.19772248). In the first, the runtime authorization boundary consumes the human's authority-bound input to emit the verdict on which execution depends, represented in an independently reconstructable authorization artifact. In the second, a human determination is consumed by the surrounding workflow and recorded; no boundary verdict is produced. The asymmetry is the architectural-class boundary between the two.

See alsoAuthorized override · Human-in-the-loop · FERZ is not Human-in-the-Loop

Provenance
The requirement that the inputs grounding a verdict have an established origin. Provenance is origin, not truth: it does not establish that input content is true, complete, current, or substantively sufficient under a domain policy. In 5TS v1.2.0, Provenance is normative, but mechanical conformance is deferred until input-origin binding and validation vectors are defined.

See alsoFive Tests Standard · Authorization artifact

Three Problems Taxonomy
The framework distinguishing the three categorically distinct AI governance problems: Visibility (what the AI did), Alignment (what the AI should do), and Authorization (whether a proposed action is permitted). Established in A Taxonomy of AI Governance Approaches, v1.7.1 (Meyman, 2026; DOI 10.5281/zenodo.18275969). FERZ addresses Authorization; adjacent categories typically address Visibility or Alignment.

See alsoAI-action authorization · Architectural class

Determinism pathways

The five architectural mechanisms through which FERZ engines formally assure determinism. Each pathway names a distinct assurance mechanism and is implemented by one engine in the FERZ stack. The five pathways together constitute the architectural-class taxonomy that distinguishes FERZ from observability and from probabilistic governance.

Semantic Determinism
The assurance mechanism by which LASO(f) formally assures determinism: meaning and coherence. The architecture specifies that semantic interpretation is constrained through a multi-tier coherence framework with bidirectional propagation, so that for the same input under the same codified rules, the same governance decision is produced. A governance decision in one dimension cannot quietly contradict a decision in another.

See alsoLASO(f) · Architectural class · Constraint Determinism

Constraint Determinism
The assurance mechanism by which DELIA formally assures determinism: bounded executable constraints. The architecture specifies a flat constraint set with no hierarchical propagation between rules and priority-based deterministic resolution where constraints overlap, so that every governed output is evaluated against the active constraint set before it leaves the system.

See alsoDELIA · Architectural class · Semantic Determinism

Adaptive Determinism
The assurance mechanism by which the FERZ Behavioral Engine formally assures determinism: deterministic bounded adaptation. The architecture specifies that behavioral adaptation responds to operational context within mathematically bounded constraints, so that adaptation remains inside the codified governance envelope rather than drifting outside it.

See alsoArchitectural class · Causal Determinism

Causal Determinism
The assurance mechanism by which CausaCore formally assures determinism: deterministic causal modeling across complex multi-tier and cross-domain systems. The architecture specifies that under the same input data, the same engine selection, and the same parameters, the same causal structure is produced, and every causal claim is traceable to the evidence and reasoning that produced it.

See alsoCausaCore · Architectural class · Constraint Determinism

Consensus Determinism
The assurance mechanism by which Constitutional Blockchain formally assures determinism: distributed deterministic authority. The architecture specifies that deterministic oversight is achieved across distributed authorities through cryptographic consensus and constitutionally bounded intervention protocols, so that no single authority can override the governance constraint and every consensus decision is independently reconstructable.

See alsoArchitectural class · Causal Determinism

Contrasted categories

Adjacent categories that share surface features with FERZ but operate in different architectural classes. Each has its own canonical comparison page; the entries here define the category on its own terms, with cross-links to the corresponding comparison.

Agent framework
An orchestration library that wires up AI agents: loads tools, manages prompts, executes tool calls, and coordinates multi-agent workflows. Common implementations include LangChain, AutoGen, and CrewAI. Agent frameworks compose with FERZ rather than substitute for it; the framework provides composition while FERZ provides authorization.

See alsoFERZ is not an Agent Framework

AI Observability
The descriptive instrumentation layer for AI systems: dashboards, traces, metrics, and alerts describing what AI systems did. Produces records of behavior after the fact. AI Observability is observation-class; FERZ is authorization-class. The architectural-class boundary cannot be crossed by adding observability features (impossibility result).

See alsoFERZ is not AI Observability · Impossibility result

Guardrails
A class of supervisory mechanisms that intercept AI inputs or outputs to filter unsafe content, using pattern matching, classifiers, or content-evaluation models. Representative systems include Guardrails AI, NeMo Guardrails, and Llama Guard. Guardrails address content; FERZ addresses action.

See alsoFERZ is not Guardrails

Review-only human-in-the-loopHITL
Review-only human-in-the-loop is a category of workflows in which a human determination is consumed by the surrounding workflow and recorded, but is not materially consumed as authority-bound input at a runtime authorization boundary; execution does not depend on a resulting boundary verdict; and no independently reconstructable authorization artifact represents such a verdict. Human participation belongs to the authorization architecture only when the authority-bound input is materially consumed at the boundary, execution depends on the resulting verdict, and that verdict is represented in an independently reconstructable authorization artifact. Distinguished from ABSTAIN with authorized resolution by the Override Asymmetry.

See alsoFERZ is not Human-in-the-Loop · Override Asymmetry

Identity and Access ManagementIAM
The architectural category that authorizes identity-to-resource access: it answers whether a principal may access a resource. The decision basis is identity attributes, role and group membership, and access control rules. IAM gates who can interact with the AI system; FERZ gates what the AI may do.

See alsoFERZ is not IAM

Policy engine
A general-purpose policy decision point that evaluates caller-provided queries against caller-provided rules. Typical examples include OPA, Cedar, Drools, and IBM ODM. A policy engine can be a useful component within an AI-action governance architecture but does not by itself constitute one; the properties that distinguish AI-action authorization are architectural commitments, not policies that can be added.

See alsoFERZ is not a Policy Engine

Runtime Application SecurityRASP-class
A class of security tools that detects and blocks attacks at runtime by inspecting requests, function calls, and data flows against attack signatures or behavioral baselines. RASP asks whether an action is an attack; FERZ asks whether an action is authorized by policy. The architectural class remains security and attack-detection regardless of what is being protected.

See alsoFERZ is not Runtime Application Security

Security Information and Event ManagementSIEM
A class of platforms that aggregate security events from enterprise systems, apply correlation rules, and generate alerts for human investigators. Common platforms include Splunk, Microsoft Sentinel, and IBM QRadar. SIEM is post-hoc; FERZ is ex-ante. The architectural class remains post-hoc event aggregation regardless of which events are being ingested.

See alsoFERZ is not SIEM · Ex-ante

References

Meyman, E. (2026). The Authorization Artifact Test: Applying the Impossibility Result to Ex-Ante Regulatory Regimes, v1.1. Zenodo. Concept DOI https://doi.org/10.5281/zenodo.20013582; v1.1 DOI https://doi.org/10.5281/zenodo.21326750

Meyman, E. (2026). A Taxonomy of AI Governance Approaches: Distinguishing Visibility, Alignment, and Authorization, v1.7.1. Zenodo. https://doi.org/10.5281/zenodo.18275969

Meyman, E. (2026). On the Impossibility of Observability-Based Authorization: A Formal Impossibility Result for Ex-Ante AI Governance. Zenodo. https://doi.org/10.5281/zenodo.19647542

Meyman, E. (2026). Observability Is Not Enforcement: A Doctrinal Framework for Distinguishing Compliance Instrumentation from Runtime Authorization in AI Governance Architectures. Zenodo. https://doi.org/10.5281/zenodo.18663864

Meyman, E. (2026). From Monitoring to Authorization: The Structural Shift in Agentic AI Governance. Zenodo. https://doi.org/10.5281/zenodo.18743974

Meyman, E. (2026). The Override Asymmetry: Why ABSTAIN with Authorized Resolution Is Not Guardrails with Review-Only Human-in-the-Loop, v2.0. Zenodo. https://doi.org/10.5281/zenodo.19772248

Meyman, E. (2026). Versioned Meaning: How to Make Ontologies Audit-Stable. Zenodo. https://doi.org/10.5281/zenodo.18328587

Meyman, E. (2026). Type-Theoretic Formal Methods for AI Governance. Zenodo. https://doi.org/10.5281/zenodo.18371224

Related doctrine and pages

Cite this page

FERZ, Inc. (2026). Glossary of FERZ Governance Terms. https://ferz.ai/governance/glossary

BibTeX
@misc{ferz2026glossary,
  author = {{FERZ, Inc.}},
  title  = {Glossary of FERZ Governance Terms},
  year   = {2026},
  url    = {https://ferz.ai/governance/glossary},
  note   = {FERZ Canonical Reference}
}