5TS adds Provenance as a fifth necessary test: the input-origin requirement the four-test version left implicit. Four tests—Stop, Ownership, Replay, and Escalation—remain mechanically verifiable today through the v1.0.2 conformance bundle. Provenance is normative in v1.2.0, and its mechanical conformance is deferred until input-origin binding is defined.
The Five Tests Standard (5TS) establishes five necessary conditions that any consequential AI system must satisfy to claim governance in practice rather than performance: Stop (halt before side effects), Ownership (named accountable authority), Replay (deterministic reconstruction), Escalation (transfer of control at policy boundaries), and Provenance (established input origin).
Unlike frameworks that rely on organizational self-assessment, 5TS enables independent verification through deterministic acceptance criteria and a public conformance testing bundle.
From Governance Theater to Verifiable Control
Governance theater
Dashboards without constraint. Organizations invest in dashboards, committees, and documentation that satisfy regulatory requirements while providing no actual constraint on AI system behavior.
Post-hoc narratives. When disputes arise, organizations discover their governance cannot reproduce decisions, halt actions, or prove compliance under adversarial inspection.
Interpretive ambiguity. Terms like human oversight and explainable decisions admit multiple interpretations, making compliance assessment subjective and dispute-prone.
Mechanically verifiable
Objective tests. Five conditions that resist interpretation. Four are verified independently today through deterministic acceptance criteria; the fifth, Provenance, is normative now.
Evidence-based. Proof-Carrying Decision (PCD) objects encode sufficient evidence to verify governance claims at decision boundaries.
Vendor neutral. Works across LLMs, MLOps, RAG, and BPMN or ETL. Any system that emits PCD evidence passing the v1.0.2 bundle can claim bundle conformance for the four testable tests, regardless of implementation approach.
The Five Tests
Every consequential AI decision must satisfy these five conditions to claim enforceable governance. Four carry mechanical verification today; Provenance states the input-origin requirement.
Stop Test
The system must be haltable by authorized humans before side-effects occur. Effect-tokens gate external actions, ensuring fail-closed operation.
Attempt an unapproved action, observe zero external effects, inspect the denial PCD with cited policy and no effect-token.
Ownership Test
Each class of consequential decision must map to a named accountable authority. Policy and runtime attestations must preserve role accountability and key separation.
Check attestations: policy_signed precedes exec_start precedes exec_end, with distinct key IDs for policy and runtime emissions.
Replay Test
Decisions must be reproducible from recorded state, yielding identical outcomes. Supports both state-replay and protocol-replay modes.
Freeze decision state, re-execute with fenced IO and time, compare outcome and canonical hash for equality.
Escalation Test
The system must provide escalation routes to authorized human control at defined policy boundaries, with execution blocked until the authorized approval or denial is recorded.
Trigger a defined boundary condition and verify that execution is held, the responsible human authority is identified, and the approval or denial is recorded before any external effect occurs.
Provenance Test
Normative · conformance deferredThe inputs a decision rests on must have an established origin. A control must establish the provenance of the inputs grounding a verdict, and must not ground a verdict on inputs whose origin cannot be established.
Normative in v1.2.0. The proof object binds input bytes through custody hashes but does not yet bind input origin, so Provenance is not yet mechanically tested. Its verification is defined once input-origin binding ships. Provenance governs whether a control may rely on an input; it does not, by itself, establish that the input is true or sufficient.
What Makes 5TS Different
Cryptographically signed
Every PCD includes canonical hashes and signatures that support authenticity checks and make tampering detectable.
Implementation agnostic
Works with any AI system architecture: LLMs, MLOps, RAG, BPMN or ETL. Standards-based, not product-bound.
Decision boundaries
Precisely defined accountability points: deploy, policy, and inference decisions with clear lineage.
Provenance requirement
A verdict may not rest on inputs whose origin cannot be established. Normative in v1.2.0; conformance deferred.
Public testing bundle
Downloadable bundle with schemas, vectors, and validator. Three positive cases must pass, five negative cases must fail.
Deterministic replay
State-replay for byte-identical reproduction, or protocol-replay with policy gates for stochastic processes.
Full five-test conformance is not yet assertable. An implementation claims conformance to the v1.0.2 bundle, and must not claim Provenance conformance.
Get the Standard
The specification, conformance bundle, validator, and archival records are public. Everything lives in the canonical sources below—no on-site downloads to drift out of date.
Repository
- 5TS v1.2.0 specification
- Conformance bundle v1.0.2
- Reference validator and schemas
- Eight test vectors
DOI-pinned release
- Concept DOI (latest): 10.5281/zenodo.21040295
- This version, v1.2.0: 10.5281/zenodo.21040296
- Citable, version-pinned record
Foundational paper
- Formal specification and proofs
- Threat model and conformance framework
- Peer-oriented academic record
97d67d345873fdd0832617d31c037481cf9a029daf225c28045c4dd7008f0836
The bundle and its published hash live in the repository. Three positive vectors must pass, five negative vectors must fail.
Conformance Claims Template
Implementations claiming conformance to the v1.0.2 bundle publish this standardized claim line with verification logs. The bundle covers Stop, Ownership, Replay, and Escalation. Provenance is normative and is not part of the claim until its conformance is defined.
Standard: 5TS · Bundle: v1.0.2 · Tool: <name@version>
PCD major: 1.x · Vectors: 8/8 correct
Hash(zip)=97d67d345873fdd0832617d31c037481cf9a029daf225c28045c4dd7008f0836
Logs: <link>
Implementation Quickstart
Five steps from proof-of-concept to conformance with the v1.0.2 bundle, with Provenance preparation for 5TS v1.2.0.
Freeze custody first
Hash and URI-pin decision-relevant inputs (data, model, policy, prompt, config). Emit canonical PCDs for every consequential decision. Recording input origin here is the groundwork for Provenance.
Choose replay mode
Default to state-replay for byte-stable artifacts. Use protocol-replay with policy gates when re-execution is required for stochastic processes.
Install the acceptance surface
Enforce fail-closed architecture with pre-execution policy checks and effect-token gating for all external side-effects.
Type your lineage
Add schemas and units for step inputs and outputs, and cite policy references that govern authority and threshold changes.
Run the conformance suite
Test with positive vectors (pass) and negative controls (fail with explicit codes). Publish the claim line and verification logs.
Implementation by Role
For Engineers
- Run the quickstart validator against your PCD emissions.
- Implement the PCD schema: decision, artifacts, lineage, controls, attestations.
- Choose a replay strategy: state-replay for deterministic systems, protocol-replay with gates for stochastic ones.
- Add effect-token gating so denial paths block side-effects.
- Record input origin alongside custody to prepare for Provenance.
For Procurement
- Require conformance claims to the v1.0.2 conformance bundle, with published logs and vector results.
- Ask for PCD evidence demonstrating Stop, Ownership, Replay, and Escalation for your use cases, and ask separately how the vendor establishes input origin.
- Verify claims by running vendor PCDs through the public validator.
- Demand deterministic acceptance criteria, not subjective ethics assessments.
For Auditors
- Use the v1.0.2 conformance vectors as standardized audit procedures for Stop, Ownership, Replay, and Escalation.
- Verify replay determinism by re-executing decision boundaries and comparing outcomes.
- Check custody integrity through hash verification, canonicalization checks, and signature validation.
- Validate policy signatures with proper timing and key separation.
- Test fail-closed operation by attempting unapproved actions.
Frequently Asked Questions
What is the Five Tests Standard (5TS)?
5TS is a vendor-neutral open standard that defines five necessary conditions a consequential AI system must satisfy to claim governance in practice rather than performance: Stop, Ownership, Replay, Escalation, and Provenance.
Why five tests and not four?
5TS adds Provenance, the input-origin requirement the four-test version left implicit. A system can be stoppable, owned, replayable, and escalatable while authorizing on inputs whose origin was never established. Provenance names that requirement, and 5TS v1.2.0 makes it explicit and normative.
Is Provenance mechanically testable today?
No. Provenance is normative in v1.2.0, but its mechanical conformance is deferred until input-origin binding is defined in the proof object. The current v1.0.2 conformance bundle tests the other four tests.
How does an implementation claim conformance?
By passing the v1.0.2 conformance bundle, which covers Stop, Ownership, Replay, and Escalation across eight vectors. Provenance conformance and full five-test conformance are not yet assertable.
Is 5TS vendor-neutral?
Yes. 5TS is implementation-agnostic and works across LLM tools, MLOps, RAG, and BPMN or ETL. Any system that emits Proof-Carrying Decision evidence passing the current v1.0.2 conformance bundle can claim bundle conformance for Stop, Ownership, Replay, and Escalation. Provenance is normative in 5TS v1.2.0, but Provenance conformance and full five-test conformance are not yet assertable.
References
- FERZ, Inc. (2026). Five Tests Standard (5TS) v1.2.0. Zenodo. 10.5281/zenodo.21040295 (concept), 10.5281/zenodo.21040296 (v1.2.0).
- Meyman, E. (2026). On the Impossibility of Observability-Based Authorization. Zenodo. 10.5281/zenodo.19647542.
- Meyman, E. Verifiable AI Governance: The Five Tests Standard (5TS) and Proof-Carrying Decisions. SSRN. Author page.
BibTeX
@misc{ferz2026fivetests,
author = {{FERZ, Inc.}},
title = {Five Tests Standard (5TS)},
year = {2026},
url = {https://ferz.ai/governance/five-tests-standard}
}The Five Tests Standard (5TS) is vendor-neutral and open for implementation. Specification licensed under CC BY-NC-ND 4.0. Conformance bundle licensed under MIT.