Research · Version 2.0

Authorization
Discipline

The missing link in institutional governance
Why institutional decisions must be articulated into approved, versioned, authority-traced inputs before a runtime authorization boundary can govern covered effects.
Edward Meyman · FERZ, Inc. · August 2026

Institutions often possess governing decisions, policies, approvals, and procedural controls without a traceable path from those materials to the verdict on which execution depends.

The relevant question is not whether controls exist between decision and execution. They usually do: planning, budgeting, legal review, procurement, risk assessment, approval, testing, oversight.

The question is whether the governing judgment has been translated into an approved and versioned form whose constraints, authority, evidence requirements, temporal conditions, and failure treatment can be traced into the runtime verdict on which a covered effect depends.

What authorization discipline is

Authorization discipline is the institutional practice of articulating, approving, versioning, maintaining, and authority-tracing the assumptions, evidence requirements, scope, constraints, temporal conditions, and failure treatment that a runtime authorization boundary must materially consume when evaluating covered actions.

It does not itself emit ALLOW, DENY, or ABSTAIN. It creates and governs inputs to the runtime boundary. The authorization artifact is emitted later, by that boundary, for the specific action evaluated.

A program may be procedurally governed while that trace remains incomplete. Documentation may establish who approved an initiative and how the organization administered it. It does not necessarily establish that a specific effect-bearing action was evaluated under the applicable decision state before execution.

Three stages

Scroll horizontally to view the full diagram. The stages are also described in text below.

Three-stage governance model. Stage 1, Governing judgment and authority, establishes institutional direction and emits no action verdict or authorization artifact. Stage 2, Authorization discipline, produces the approved authorizing frame and versioned constraint representation and emits no action verdict or authorization artifact. Codification is a controlled transition between Stage 2 and Stage 3 and is not a separate decision authority. Stage 3, Runtime authorization and controlled release, contains the runtime authorization boundary, the ALLOW, DENY, or ABSTAIN verdict, the authorization artifact and authenticated bound materials, and release-condition validation. Observability operates outside the release dependency.
Figure 1. From governing judgment to runtime authorization. Stage 1 establishes institutional direction and authority. Stage 2 produces the approved, versioned inputs required for action authorization. Stage 3 evaluates a specific covered action and emits the action-bound verdict and authorization artifact on which release depends. No stage substitutes for another, and successful completion of all three does not by itself establish legal compliance or authorization infrastructure beyond the declared topology.
Stage 1
Governing judgment and authority
Competent institutional judgment establishes the objective, authority, initial scope, and material assumptions.
Institutional judgment remains irreducible. Technology may assist but does not displace the competent authority.
Stage 2
Authorization discipline
The governing judgment is converted into an approved authorizing frame and a versioned constraint representation.
Failure if absent: governing inputs remain informal or untraceable.
Transition
Codification
Controlled transition from approved frame to runtime-evaluable constraint representation.
Not a separate decision authority.
Stage 3
Runtime authorization and controlled release
The boundary evaluates the canonical proposed action against the materially used inputs and emits the action-bound verdict.
The authorization artifact is emitted here. Execution depends on the verdict and release-condition validation.

What formalization and runtime authorization cannot establish

Formalization does not make the underlying judgment sound. Runtime authorization does not make the governing policy correct. A well-formed constraint can faithfully enforce a mistaken institutional choice. A reconstructable verdict can show which policy and state produced the result without establishing that the policy was lawful, wise, complete, or normatively justified.

The converse also holds. A runtime boundary cannot establish an authority chain that was never declared, select the legally controlling interpretation on its own, or infer an omitted constraint and represent that inference as approved institutional policy.

Upstream formalization and downstream authorization are separate requirements. Neither substitutes for the other.

Technology may assist research, drafting, comparison, conflict detection, simulation, and constraint extraction. Those capabilities do not displace the competent authority responsible for selecting, approving, and maintaining the applicable interpretation and decision state.

Minimum articulation fields

These five fields are necessary to this model. They do not constitute a universal governance, authorization, or conformance standard.

Declared assumptions
The material assumptions on which the governing decision rests. An assumption that is not declared cannot be examined.
Ownership of assumptions
An identified owner responsible for each assumption's validity and for monitoring its continued accuracy.
Evidence requirements
The evidence required for the institutional decision and the applicable conditions governing its use. Input Integrity separately asks whether the materially used evidence satisfied those conditions at decision time.
Constraint boundaries
The limits governing covered actions within declared scope. These do not become runtime controls until represented in approved form and materially consumed by the boundary.
Failure treatment
What follows when a material premise, evidence threshold, authority, or constraint condition is not established. Missing conditions must not produce ALLOW.

The authorizing frame as a structured object

Stating the frame as a structured object makes the traceability relation to runtime authorization easier to reason about and audit. The notation below is an illustrative representation of the paper's articulation model, not a canonical FERZ schema or conformance requirement.

F = (U, O, E, C, T, H, A, R)
U
declared assumptions
O
ownership and accountable roles
E
evidence requirements and applicable conditions governing use
C
constraints and declared scope
T
temporal applicability and validity conditions
H
failure and authorized-resolution treatment, where applicable
A
amendment authority and prospective versioning
R
runtime-consumption requirements

A runtime authorization decision does not consume the authorizing frame abstractly. The boundary evaluates the applicable versioned constraint representation, whose relationship to the approved authorizing frame and approving authority must remain traceable.

What approval binds

Approval that does not attach to specific decision-relevant content leaves the institution free to approve an aspirational statement while implementation supplies the governing detail afterward. That outcome is the condition this model is intended to prevent.

Within the illustrative articulation model used here, the approval record identifies:

  • the declared scope and action vocabulary
  • the authority basis and delegation rules
  • each material constraint and its effective version
  • the evidence requirements and applicable conditions governing use
  • temporal validity and revision rules
  • the failure and authorized-resolution treatment, where applicable
  • the runtime-consumption specification

Where an element is unbound, a downstream claim that the runtime verdict was governed by approved institutional policy is not established for that element.

A federal modernization example

The following is hypothetical. It does not describe an existing agency, procurement, management agenda, appropriations decision, or deployed federal system.

A government-wide modernization directive encourages agencies to use automated classification to reduce document-processing backlogs. An agency approves a pilot, prepares a strategy, conducts acquisition planning, performs security and privacy review, and issues a competitively evaluated procurement. Those steps may be procedurally sound.

The remaining question is whether the governing assumptions and boundaries have been approved in a form that can control downstream actions. If the agency has not declared the target backlog, evidence threshold, acceptable error rate, prohibited record changes, authority for exception handling, review period, and failure treatment, later operators may implement materially different interpretations while each claims alignment with the same directive.

What the approved frame would contain

Purpose
Reduce document-classification time for the declared intake class.
Competent authority
Named role with approval and amendment authority.
Scope
Pilot population, action vocabulary, covered records, excluded actions, declared topology.
Evidence requirements
Representative test set, measurement method, minimum improvement, error bounds, and applicable Input Integrity conditions.
Constraint boundaries
No alteration of adjudicative records. Defined human-review conditions. Security, privacy, replacement, and dependency constraints.
Temporal boundary
Pilot start, evaluation windows, evidence freshness, authority duration, expiration.
Failure treatment
DENY or ABSTAIN at runtime where required inputs are not established. Program hold, remediation, termination, or reauthorization at the institutional level.
Amendment rule
Who may revise the frame, under what evidence, and with what prospective effective date.
Runtime-consumption rule
Which fields and versions the boundary must materially consume.
It can produce a non-authorizing result
Missing required conditions cannot silently produce permission.
It is assessable within declared scope
An evaluator can identify the approved assumptions, authority, constraints, evidence requirements, and versions relied upon.
It assigns ownership and amendment authority
Responsibility for monitoring and changing the frame is declared.

These properties support governability within the declared scope. They do not establish that the assumptions are true, that every applicable legal requirement has been represented, or that the runtime topology is non-bypassable.

Articulation, codification, and approval

Articulation requires accountable institutional judgment. Domain experts and competent authorities determine the applicable purpose, interpretation, scope, assumptions, evidence requirements, and constraints. Tools may assist drafting, extraction, normalization, comparison, simulation, and conflict detection. The institutional authority remains responsible for approving the representation used by the runtime boundary.

Codification is the controlled transition between articulation and runtime evaluation. It is not a fourth decision authority and must not be treated as an autonomous source of policy meaning.

Executability does not establish fidelity. The organization must maintain evidence supporting the claim that the represented constraints correspond to the approved frame within the declared scope.

Policy representation fidelity concerns whether the constraint representation accurately implements the approved authorizing frame. Input Integrity concerns whether the boundary used admissible evidence and evaluated applicable conditions at decision time. These are distinct questions with distinct evidence. Representation fidelity is an upstream assurance obligation, not a fourth boundary integrity property, and it does not extend the Authorization Boundary Integrity Model.

The authorizing frame participates in composed authorization only where its approved, versioned constraint representation is materially consumed by the runtime boundary, and the action-bound verdict and validated release conditions depend on that representation.

The runtime architectural role

FERZ's published runtime architecture does not
  • improve governing judgment or validate premises
  • independently determine the controlling policy interpretation
  • perform articulation or decide what constraints should govern
  • establish legal compliance
FERZ's published runtime architecture
  • receives the canonical proposed action, applicable policy and version state, authority chain, governance-relevant state, materially used evidence, evaluator and dependency state, and any authority-bound resolution input required by the declared profile
  • emits the action-bound verdict at the runtime authorization boundary
  • represents that verdict in an authorization artifact with authenticated bound materials
  • makes release dependent on the boundary's application of the declared authorization state
ALLOWDENYABSTAIN

ALLOW means the action is permitted under the evaluated authorization state, but execution may proceed only if the applicable release conditions validate. DENY blocks the covered effect. Unresolved ABSTAIN remains ABSTAIN and blocks execution unless and until authorized resolution causes the boundary to emit a separate resulting action-bound verdict. The original ABSTAIN does not convert.

Independent reconstruction may require the authorization artifact, authenticated bound materials, interpreter, dependencies, verifier materials, and preserved state required by the declared replay mode. Artifact existence alone does not establish Output Integrity, Input Integrity, Replay Integrity, 5TS conformance, or legal compliance.

Observability may operate before, during, or after execution. It remains outside authorization unless the runtime boundary materially consumes its output, the covered effect remains held, and execution depends on the resulting verdict.

Three distinct functions

Governing judgment determines the institution's direction and authority. Authorization discipline converts that judgment into an approved, versioned, authority-traced frame and constraint representation. The runtime authorization boundary evaluates a specific proposed action and emits the verdict on which release depends.

No stage substitutes for another. A runtime boundary cannot invent omitted authority, policy, or evidence requirements. A formalized frame cannot prevent a covered effect unless the applicable representation is materially consumed by a non-bypassable boundary. A reconstructable verdict does not make the governing judgment correct or prove legal compliance.

Observability can document what occurred. Authorization discipline can establish what the institution approved as the governing frame. The runtime authorization boundary determines whether the specific covered action is permitted before the effect occurs. Keeping these functions separate is what allows them to compose without overstating what any one function establishes.

Without governing authority, there is no approved basis.

Without authorization discipline, there is no traceable constraint state.

Without runtime authorization, there is no action-bound verdict on which execution depends.

This paper does not assert that a law, regulation, procurement rule, or institutional framework requires the FERZ authorization architecture. The institutional examples illustrate an internal control model. They do not determine legal authority, appropriations validity, procurement compliance, regulatory satisfaction, or evidentiary admissibility in a particular proceeding. Organizations should obtain qualified legal and domain-specific advice.

Edward Meyman is Founder and CEO of FERZ, Inc., which develops deterministic authorization infrastructure for AI systems operating in regulated environments. Published research is available at ferz.ai and through the FERZ Zenodo community. Version 2.0 supersedes Version 1.1.0.