Deterministic AI Governance: An Executive Guide to Runtime Authorization and Spotting the Fake

Series Introduction to the AI Governance Executive Guide Series from FERZ, Inc.

AI systems in production already produce consequential actions: who is flagged, who is denied, who is escalated, who is restricted. Accountability for those actions attaches at deployment, not when a governance program is stood up. This guide is written for executives and directors who must decide whether an AI system is fit to touch consequential work, and who need a way to test vendor and internal claims without a technical background.

Governance is enforced at the authorization boundary: the point where an output becomes an effect-bearing action, and where evidence, not explanations, must exist.

What this guide provides

• A working definition of runtime authorization and the authorization boundary, including the three-verdict model of ALLOW, DENY, and ABSTAIN.
• Five tests that separate enforced governance from theater, each with the shape of a passing answer and the deflection patterns that indicate an answer is avoiding the question.
• Five recurring moves by which observation is presented as control, including monitoring-as-governance, policy without runtime enforcement, and synthetic authority.
• A minimum bar of five deliverables to require in writing, with named owners, before deployment or purchase.
• A one-page intake script and a glossary of the terms used.

The five tests

• Stop. An authorized human can halt the system before an action produces an effect, through a control enforced at runtime.
• Ownership. Each class of consequential action is assigned to a named accountable role, and that assignment is recorded and enforced.
• Replay. Each verdict can be independently reconstructed from the bound inputs, applicable policy and version state, authority chain, proposed action, and resulting verdict.
• Escalation. When policy cannot resolve an action, the system returns ABSTAIN. Execution remains blocked pending an authorized human override.
• Provenance. The origin of the inputs grounding the verdict is established, and reliance on those inputs was permitted.

A note on Provenance

Provenance is normative in the Five Tests Standard, but mechanical conformance is deferred pending a defined method for binding input origin to the decision. The guide states the practical consequence plainly: a serious supplier should answer the Provenance question substantively, describing sources, retrieval paths, and fail-closed behavior on unapproved inputs, but no claim of mechanically verified 5TS Provenance conformance should be accepted under the current specification.

Scope

This is an introduction, not a procurement standard and not a technical specification. It describes requirements, failure modes, and evaluation methods. It does not describe the capabilities of any named product, and no vendor is identified or assessed. Scenarios are illustrative composites. Readers who need procurement depth should proceed to The Enterprise AI Governance Buyer's Guide; readers who need controls expressed in a sector's native language should proceed to the corresponding volume in this series.

Related publications

• Five Tests Standard (5TS), the published standard defining the five tests and their conformance bundle: 10.5281/zenodo.21040295
• The Enterprise AI Governance Buyer's Guide: 10.5281/zenodo.18002693
• Authorization Boundary Integrity Model: 10.5281/zenodo.20929115

Version

Version 2.0, August 2026. This edition supersedes an earlier 2025 edition of the guide, which was written before the Five Tests Standard was published and is not deposited.

Published by FERZ, Inc. under the Creative Commons Attribution 4.0 International License. The authoritative version is maintained at ferz.ai.