Overview

Artificial intelligence systems have crossed from advisory to operational capability. They now commit transactions, modify infrastructure, and make decisions at a scale and velocity that exceeds human review. This shift introduces a structural accountability gap: the absence of a formal standard for what it means to authorize an AI-initiated action and prove that authorization occurred.

CAES addresses this gap. It does not prescribe implementation architecture. It defines the normative properties that any conformant system must provide — regardless of the underlying technology, deployment model, or AI provider.

Scope

This specification applies to any AI system — agent, model, or automated pipeline — that:

(a) Produces effects beyond the boundary of its own process state;
(b) Operates in an environment subject to regulatory, legal, or financial accountability;
(c) Executes actions that a human or policy authority must be able to verify after the fact.

CAES does not apply to purely advisory systems — those whose output requires explicit human mediation before real-world effect occurs. The boundary is the execution gate: if the AI can cause effects without a human completing a separate action, CAES scope applies.

Definitions

Normative Requirements

The following requirements are normative. A system claiming CAES conformance must satisfy all requirements at the applicable compliance level.

4.1 — Authorization Requirements

4.2 — Evidence Requirements

4.3 — Failure Requirements

Core Primitives

CAES defines three structural primitives. These are the minimum objects a conformant system must be able to produce, persist, and present to an auditor.

Primitive 1 — The Decision Receipt

The Decision Receipt is the atomic unit of governed authorization. It is produced at evaluation time — not after execution — and binds the following: the identity of the requesting actor, the canonical policy state (via PolicyHash), the disposition (Approve / Deny / RequiresHuman), the timestamp of evaluation, and a cryptographic signature.

Primitive 2 — The PolicyHash

The PolicyHash is a deterministic, reproducible hash of the canonical policy state active at the moment of evaluation. Any party with access to the policy definition can independently recompute the hash. A PolicyHash mismatch is proof of policy drift or manipulation.

Primitive 3 — The Governed Spine

The Governed Spine is the append-only, causally ordered record of all governed events. It is not a log. It is the forensic source of truth. Every event in the spine carries: a unique immutable identifier, a causal parent reference, a tenant scope, a hash commitment over the payload, and a timestamp assigned at ingestion.

Causal Chain

Every governed operation produces a spine — a causally ordered sequence of governed events. The spine is the complete forensic record of a single operational run.

The canonical CAES causal chain is:

Trigger → Intent → Justification → Decision → Action → Outcome

Authority Model

CAES does not prescribe how policy is authored. It defines how authority is exercised and proven.

When high-stakes actions require human review, a CAES-conformant system must not merely pause and resume. It must produce a cryptographic signing request. The human operator must produce a signed delegation — narrow in scope, bound to the specific action, and recorded in the governed spine.

Human authority in a CAES system is:

Scoped — authorization applies to a specific action, not a class of actions. Temporal — the delegation has explicit validity bounds. Non-repudiable — the operator's identity is cryptographically bound. Recorded — the delegation is a spine event, not an out-of-band approval.

Compliance Criteria

CAES conformance is defined in three levels. Higher levels are supersets of lower levels.

Reference Implementation

The CAES Working Group designates a single reference implementation per specification version. The reference implementation demonstrates normative conformance and serves as the baseline for interpretive questions about specification intent.

Designation as the reference implementation does not imply commercial endorsement by the CAES Working Group. Other implementations claiming CAES conformance must independently satisfy the requirements defined in this specification.

Version History

Working Group Charter

Membership

Process

Specification amendments are proposed via documented change requests. Each change request must identify: the normative requirement affected, the rationale for change, and backward compatibility implications. Changes are published with the next versioned release. There are no informal amendments.

Amendment Process

CAES does not change silently. Every normative change is versioned. Every version is publicly documented with a summary of what changed and why. The amendment process exists to make the specification more correct — not more comprehensive. Scope creep is not an amendment.

To propose an amendment: document the requirement, the problem it solves, and the conformance implications. Submit to the Working Group. Amendment proposals are acknowledged, considered, and either incorporated into the next versioned draft or formally declined with rationale.