CAES v0.2.0

Two documents, one constitution

CAES defines how decisions must be enforced. CPP defines how decisions must be determined.

Capitalized keywords follow RFC 2119 and RFC 8174. MUST and MUST NOT are requirements. SHOULD is a recommendation. MAY is an option. This HTML edition adds navigation and tables. Short labels in the margin are reading aids. The sentences are the requirements.

Overview

This repository contains the normative specification, version history, and working group materials for CAES.

Why CAES exists

AI systems have moved beyond advisory roles. They now:

• Commit transactions
• Modify infrastructure
• Trigger automated workflows
• Interact with physical systems
• Influence consequential human decisions

There is no widely adopted standard defining what it means to authorize an AI action and prove that authorization occurred. CAES addresses this structural accountability gap.

Scope

CAES applies to any AI system that crosses an Effect Boundary, including:

• Digital state mutation
• External system invocation
• Communication with consequential impact
• Behavioral influence in regulated contexts
• Physical actuation (robots, vehicles, automation)
• Cross-boundary access to regulated data
• Behavioral output that influences a decision with material consequence
• Recording, observation, or retention of personal or sensitive data

If an AI system can produce consequential effects without independent human mediation, CAES scope applies.

Purely advisory systems are out of scope.

Core principles

A conformant CAES implementation MUST provide:

• Deterministic policy evaluation
• Pre-execution authorization receipts
• Cryptographically verifiable evidence
• Append-only causal event recording
• Fail-closed enforcement
• Offline-verifiable artifacts
• Explicit authority delegation for high-stakes actions

Which of these are required at each level is the applicability matrix. Cryptographic evidence, the Governed Spine, and offline artifacts are Level 2 and Level 3 requirements. Level 1 requires a pre-effect Decision Record and fail-closed enforcement.

Governance applies to any output capable of producing consequential effect, including behavioral outputs.

CAES defines structural requirements. It does not prescribe implementation architecture.

Effect Boundary definition

An Effect Boundary is crossed whenever an AI system produces an output that can cause a consequential change in state outside the system itself.

Effect Boundaries MUST be treated as governed action triggers. The following categories are normatively recognized:

Fail-closed semantics

Fail-closed is the mandatory default behavior under uncertainty, failure, or missing information. It is not configurable.

A system is fail-closed if and only if all of the following hold:

A fail-closed event MUST:

• produce a denial record with the persistence requirements of that level
• at Level 2 and Level 3, append that record to the Governed Spine
• surface a structured error indicator to the caller

Uncertainty is denial. Silence is non-compliant.

Authorization-execution separation

CAES requires strict temporal separation between the authorization decision and the execution of the governed action.

Non-compliant patterns

• Recording a receipt at execution time rather than before execution
• Using a previously issued receipt to authorize a new action
• Treating a storage acknowledgment as equivalent to verified persistence
• Allowing execution to proceed when receipt verification is unavailable

Decision dispositions

Every governance evaluation MUST yield exactly one of the following dispositions. Dispositions MUST be explicitly named. Implicit or inferred dispositions are non-compliant.

Core primitives

CAES formalizes three foundational objects. All three MUST be present for Level 2 conformance. Level 1 requires a Decision Record. A Level 2 Decision Receipt is a signed Decision Record and satisfies the Level 1 record requirements.

1. Decision Record and Decision Receipt

A Decision Record is the pre-effect governance artifact. A Decision Receipt is a Decision Record with the Level 2 signature and PolicyHash profile. At Level 1, "unverifiable" means a missing required field or a failed readback. It does not mean signature verification.

Denial records. A Denied disposition uses the same persistence rules as an approval at that level. At Level 2 the denial is signed. A denial is evidence that the constraint functioned. It is not an error.

2. PolicyHash

A PolicyHash is the SHA-256 fingerprint of the effective policy bundle. It is required at Level 2 and Level 3. It is not a Level 1 blocker. The hashed bytes are the UTF-8 RFC 8785 (JCS) encoding of the bundle after imports are resolved and defaults are expanded. Runtime context is not part of the bundle.

PolicyHash = lowercase-hex(SHA-256(JCS(effective_policy_bundle)))

The PolicyHash is the proof that a specific policy version governed the decision. It MUST NOT be a pointer, a label, or a version string alone.

3. Governed Spine

The Governed Spine is an append-only, causally ordered, tenant-scoped record of governed events. Spine requirements apply at Level 2 and Level 3. Level 1 does not require a spine append (CAES-SPN-01).

Compliance levels

CAES defines three conformance tiers. Each tier is a strict superset of the previous.

Conformance claims MUST specify the CAES version, the claimed level, and a complete Conformance Statement. Partial conformance claims are non-compliant.

CPP v1.0 states that CPP is optional at Level 1 and required at Level 2 and Level 3.

Not required at Level 1: PolicyHash, RFC 8785 canonicalization, JWS signature, spine ordering, and offline Evidence Pack verification. Implementations SHOULD include them. Their absence is not a Level 1 failure. The applicability matrix controls.

Level 3 chaos modes

Each mode is tested independently. The pass condition is the one named for that mode. Denial is not assumed. A legitimate key-rotation overlap MAY succeed. An interrupted pack export MUST NOT look sealed.

1. DB write failure
2. Key rotation conflict
3. Clock skew
4. Network partition during pack export
5. Disk full during pack write
6. Duplicate receipt injection
7. PolicyHash mismatch
8. Delegation chain expiry

Implementations MUST define a typed error code namespace. Every failure mode reachable from the public surface MUST map to a named code in that namespace. Raw exceptions or untyped error strings surfacing to callers are non-compliant.

Non-compliant patterns

CAES prohibits the following patterns. An implementation exhibiting any of these patterns MUST NOT claim CAES conformance at any level.

Authorization failures

• Prompt-only "policy" enforcement without deterministic evaluation
• Post-hoc logging presented as authorization proof
• Non-deterministic model-only policy evaluation without a deterministic verification layer
• Receipts produced after execution rather than before
• Reuse of a prior receipt to authorize a new action
• Treating storage acknowledgment as equivalent to verified persistence

Evidence integrity failures

• Mutable logs masquerading as evidence ledgers
• PolicyHash implemented as a version label, pointer, or name rather than a cryptographic hash of canonical policy inputs
• PolicyHash recomputed at execution time rather than bound at evaluation time
• Evidence artifacts that require live system access for verification

Enforcement failures

• Silent degradation under failure conditions
• Fallback to permissive execution when receipt verification is unavailable
• Implicit authorization paths not gated by receipt verification
• Invocation-layer governance bypass, where governance applies only to some invocation surfaces
• Governance that applies only when explicitly enabled

Behavioral and output failures

• Post-hoc content filtering presented as governance of behavioral outputs
• Prompt-only behavioral constraints without deterministic evaluation
• Silent modification of outputs without an audit trace
• Emission of behavior when policy evaluation fails or is unavailable

Recording and privacy failures

• Recording without verifiable authorization
• Passive or continuous recording without policy evaluation
• Use of recorded data outside the authorized purpose
• Silent collection of personal or sensitive data
• Deletion without an audit trace or verification

Behavioral governance

CAES applies to traditional execution actions and to effect-bearing behaviors produced by AI systems.

An AI system may produce consequential outcomes through language (responses, instructions, recommendations), interaction (user guidance, persuasion, escalation), physical actuation (robotics, embodied systems), and social or psychological influence. These outputs may cross an Effect Boundary even when no explicit system mutation occurs.

CAES therefore requires governance of behavioral outputs, not only execution calls. CPP requirements for those outputs are in CPP §13.

Behavioral Effect Boundary

A Behavioral Effect Boundary exists when an AI-generated output can:

• influence a user decision with material consequence
• produce legal, financial, regulatory, or safety impact
• trigger downstream actions by humans or systems
• create risk through communication, instruction, or interaction

Systems MUST treat such outputs as effect-bound.

Policy requirements

Policies MUST define constraints on:

• Allowed content. What the system may say or communicate.
• Disallowed content. Prohibited instructions, claims, or statements.
• Interaction boundaries. Escalation requirements, refusal conditions, and handoff to human authority.
• Domain-specific restrictions. Regulated domains (legal, medical, financial) and sensitive interactions (minors, vulnerable populations).
• Physical interaction constraints, where applicable. Permitted contact or actuation, safety envelopes, and exclusion zones.

Policies MAY include contextual or conditional rules, but MUST remain deterministically evaluable at the point of decision.

Behavioral decision requirement

For any behavior crossing a Behavioral Effect Boundary, a Decision Record, or a Decision Receipt at Level 2, MUST exist before emission as defined in Streaming and emission. A completion record after the stream ends is outcome evidence, not prior authorization. The record MUST:

• at Level 2 and Level 3, bind the behavior to the governing policy state (PolicyHash)
• capture the evaluated decision disposition
• include sufficient context to support audit and reconstruction

Behavioral enforcement

Systems MUST enforce behavioral policies before output is delivered, without relying on post-hoc filtering alone. Post-generation filtering MAY be used as a secondary control, but MUST NOT replace pre-decision authorization.

If policy evaluation fails or cannot be completed, the system MUST fail closed and the behavior MUST NOT be emitted.

Behavioral dispositions

• Approved. Output may be emitted as generated.
• Modified. Output must be transformed to comply with policy before emission.
• Denied. Output must not be emitted.
• RequiresHumanAuthorization. Escalation is required before emission.

All dispositions MUST be recorded and auditable.

Causal recording

At Level 2 and Level 3, behavioral decisions MUST be recorded in the Governed Spine, including the evaluated behavior or output reference, the Decision Record reference, the resulting disposition, and any transformation or escalation applied. Behavioral events are first-class governed events.

Privacy, recording, and data stewardship

AI systems may record audio, video, or environmental data, capture user-generated content, and observe or infer personal or sensitive information. These capabilities introduce legal, privacy, and ownership obligations equivalent to or exceeding those applied to human actors. CAES requires that such capabilities be governed as effect-bearing operations. CPP lifecycle rules are in CPP §14.

Sensory Effect Boundary

A Sensory Effect Boundary exists when an AI system can record audio, video, or other environmental signals; capture or store user content; or observe or infer personally identifiable or sensitive information. Crossing this boundary MUST be treated as a governed action. The record, signature, PolicyHash, and spine duties are those of the claimed level.

Consent and authorization

AI systems MUST NOT:

• record audio, video, or environmental data without appropriate authorization
• capture or store personal content without a permitted legal basis
• operate recording capabilities in restricted or prohibited contexts

Authorization MAY be derived from explicit user consent, contractual agreement, or legal or regulatory allowance. The system MUST be able to determine whether recording is permitted in context, and to deny or disable recording if authorization cannot be verified. Failure to verify authorization MUST result in fail-closed behavior.

Use and purpose limitation

Captured data MUST be used only for the purposes for which authorization was granted. It MUST NOT be repurposed without reauthorization, and MUST NOT be accessed outside defined policy scope. Policies MUST define allowed use cases, prohibited use cases, and domain-specific restrictions.

Retention and storage

AI systems MUST enforce defined retention policies for all captured data, automatic expiration or deletion based on policy rules, and restrictions on duplication, transfer, or export. Retention policies MUST be explicitly defined, deterministically enforceable, and auditable.

Deletion and proof of deletion

Data deletion MUST be treated as a governed action. When data is deleted:

• the deletion MUST be executed through the governed execution pathway
• the deletion MUST produce a Decision Record representing the action
• at Level 2 and Level 3, that record MUST be a signed receipt appended to the Governed Spine
• the record MUST be retained even after the data itself is deleted

The deletion record is permanent. The data is not.

Recording dispositions

• Approved. Recording or usage is permitted.
• Denied. Recording or usage is prohibited.
• Modified. Restricted or redacted capture is authorized.
• RequiresHumanAuthorization. Escalation is required before capture or use.

All decisions MUST be auditable and traceable.

Enforcement timing

Privacy and recording policies MUST be enforced prior to data capture, prior to data usage, and prior to data retention or transfer. Post-hoc enforcement alone is non-compliant.

Capabilities that observe, record, or retain data carry the same governance obligations as actions that execute. (CAES-PRV-01)

Conformance is judged on observable behavior: an attributable decision, an identified responsible operator, the privacy controls in this section, authorization before capture or use, and an auditable effect. (CAES-PRV-02)

Rationale, not a conformance requirement. The Working Group's aspiration is that these controls make an AI system accountable in the same practical sense as a human operator who records or retains data. That sentence does not confer legal status, and a conformance claim MUST NOT rest on it.

Interoperability contracts

These contracts complete the v0.2.0 public draft. Requirement IDs are stable. Editorial rearrangement MUST NOT recycle an ID for a different obligation. Where this section conflicts with an earlier paragraph on this page, this section controls. The Markdown source remains canonical. Fixtures are in CAES_v0.2.0_FIXTURES.md.

Three states are distinct and MUST NOT be collapsed into one field:

An Approved disposition does not by itself grant execution authority. Outcome evidence does not rewrite the disposition.

Applicability matrix

Signing and verification profile

Level 2 and Level 3 receipts MUST use flattened JWS JSON (RFC 7515) with one signature. (CAES-SIG-02)

The protected header MUST contain alg, kid, and typ with value caes-receipt+jws. The payload is the JCS encoding of the receipt JSON. The JWS signing input is BASE64URL(protected) || '.' || BASE64URL(JCS(payload)).

Interchange algorithms are EdDSA (Ed25519) and ES256 only. none and shared-secret algorithms are non-compliant. (CAES-SIG-03)

kid MUST resolve through the Evidence Pack trust bundle or the trust anchors named in the Conformance Statement. An unknown or revoked kid MUST NOT grant execution authority. During a published rotation overlap, a signature under either key that is inside that window MAY be accepted. Overlap alone is not a reason to deny. (CAES-SIG-04)

Receipt claims MUST include caes_version, receipt_id, tenant_id, issuer, audience, action_id, action_descriptor, payload_hash, disposition, enforcement_outcome, iat, and exp. Level 2 claims also include policy_id, policy_version, policy_hash, and matched_rules. payload_hash is lowercase-hex SHA-256 of the canonical action payload that would be effected. (CAES-SIG-05)

iat and exp MUST be RFC 3339 timestamps with a Z or numeric offset. They are signer-asserted. A signature does not prove that the clock was accurate. For an interchange claim, exp - iat MUST be at most 15 minutes, and declared clock skew MUST be at most 120 seconds. If clock accuracy is unknown, execution authority MUST NOT be granted. Archival verification MAY still report that the signature matches, and it MUST label the time as untrusted. An RFC 3161 time-stamp token is optional additional evidence. It does not replace iat, and it is required only when the Conformance Statement claims trusted-time assurance. (CAES-SIG-06)

exp bounds execution authority. It does not erase an archived receipt. Later verification asks whether the signature and claims were valid when recorded. It does not ask whether the authority is still unused. (CAES-SIG-07)

Effect composition

CPP effect_type values and these categories are not a one-to-one map. A policy names one effect_type. A concrete action lists every CAES category it crosses. Evaluation MUST select every installed policy whose effect_type applies to any listed category, then apply CPP conflict resolution to the combined matches. A category with no applicable policy is Denied. An effect_type outside the CPP set fails closed. (CAES-EFF-02, CPP-EFF-01)

SafetyCriticalActuation has no CPP effect_type in this version. An action that lists it therefore has no applicable policy for that category and is Denied.

ExternalInvocation is the worked case: one call can be an external side effect, a governance-state change, and a workflow transition together. All three controls apply. Dropping one because the policy named only one type is non-compliant.

Tenant selectors and dispositions

Tenant comparison is a Unicode code-point match with no case folding and no normalization. The only wildcard is the exact string *. Every other value is literal. Tenant identifiers MUST NOT be *. A policy with tenant_id * MUST NOT be installed unless the installing authority presents a delegation whose scope is cross_tenant_policy. Otherwise that policy is ineligible. (CPP-TEN-01)

Obligations

An obligation MUST declare phase: pre_effect, continuous, or post_effect. Obligations remain auditable and deterministic. They MUST NOT change the policy disposition. (CAES-OBL-01)

• A failed pre-effect obligation MUST NOT grant execution authority. Outcome evidence records the block. The disposition stays what the policy decided, including Approved.
• A failed continuous obligation MUST stop further covered effects. Bytes already released stay in the outcome evidence.
• A failed post-effect obligation MUST be recorded with a remediation duty. It MUST NOT be described as if the completed effect did not occur.

Streaming and emission

Emission is the first byte of governed content that crosses the enforcement boundary. Caller-visible metadata that carries governed content is content. Pure framing, heartbeats, and flow control that cannot carry governed content are not emission. (CAES-STR-01)

The Conformance Statement MUST name one mode. (CAES-STR-02)

• Buffered. No governed byte is released until one receipt covers the complete output.
• Segmented. Each segment is defined before release, hashed, and covered by a receipt before its first byte is released.

A receipt cannot bind the hash of an output that does not exist yet. A completion record is outcome evidence of what left the system. It is not prior authorization of unknown bytes. (CAES-STR-03)

Replay lifecycle

Fields do not make a receipt single-use. Before the effect, the executor MUST atomically and durably reserve execution authority for the tuple (issuer, tenant_id, audience, action_id, payload_hash, receipt_id). (CAES-REP-01)

Retry with the same receipt is allowed only from Reserved or Abandoned, inside exp, and only when no effect has started. If the executor crashes after the effect and before completion, the state MUST become Uncertain. A fresh receipt MUST NOT repeat that effect until reconciliation shows it did not occur. While the state is Uncertain, further execution of that action is blocked. (CAES-REP-02)

Offline verification checks the signature, the hash, and the recorded claims. It MUST NOT report that the authority is unused. Consumption state is an online enforcement fact. (CAES-REP-03)

Chaos fixtures

Each mode has its own pass condition. A shared error code is not sufficient. When two modes fire together, every applicable prevention still applies and every applicable evidence record is required. Integrity failures outrank availability failures: do not allow an unauthorized effect in order to finish a pack. (CAES-CH-00)

BINDING_MISSING remains the code when a delegation omits its target binding. (CAES-L3-02)

Evidence Pack

Level 2 and Level 3 MUST produce an Evidence Pack that conforms to governance/CAES_EVIDENCE_PACK_SPEC.md at pack spec version 0.2.0. That document is a normative annex of this draft. (CAES-PAK-01)

A pack that omits required evidence fails verification. Verification MUST be possible with no call to a private issuer service. Offline success MUST NOT be reported as "this authorization is still unused."

Conformance claims

Implementations claiming CAES compliance MUST publish a complete Conformance Statement that includes all of the following:

Unversioned or incomplete Conformance Statements are non-conformant.

Conformance Statements MAY be self-attested. Self-attested Statements MUST be clearly labeled as self-attested. Independent third-party audit is RECOMMENDED for Level 2 claims and STRONGLY RECOMMENDED for Level 3 claims. Self-attestation does not constitute certification by the CAES Working Group.

CPP conformance fields, required where CPP applies, are listed in CPP §16.

Reference implementation and governance

The CAES Working Group designates one reference implementation per version. Designation does not imply commercial endorsement. Other implementations may independently conform.

Working Group

CAES is maintained by the CAES Working Group (CAES-WG). The Working Group publishes normative specification versions, amendment proposals, conformance guidelines, and mark usage policy. Specification changes are versioned. There are no informal amendments.

Amendment process

To propose a change:

1. Identify the normative requirement affected.
2. Describe the structural issue.
3. Document backward compatibility impact.
4. Submit as a versioned proposal.

Changes are incorporated only via published version increment. Related material: amendment process, governance, conformance template.

Mark usage

"CAES" and associated marks are used to designate conformance with a specific published version. Use of the CAES mark requires a complete Conformance Statement. Mark usage guidelines are provided in /assets. See also mark usage policy.

License

The CAES specification text is published under a permissive documentation license to encourage adoption and independent implementation. See LICENSE.

Purpose and scope

A policy is not a configuration. It is a deterministic contract whose outcome can be proven, reproduced, and independently verified.

CPP defines the canonical structure, evaluation semantics, and verification model for policies governing AI systems operating under CAES. If policy is not standardized, governance is not provable.

CPP applies to all policy systems used to evaluate execution actions, behavioral outputs, data operations (capture, use, retention, deletion), communication with material consequence, and any output crossing a CAES Effect Boundary.

CPP is mandatory for CAES Level 2 and Level 3 systems. It is optional at Level 1.

Core requirements

A CPP-compliant policy system MUST be:

Canonical policy model

A CPP policy MUST conform to the following structure:

{
  "policy_id": "string",
  "version": "string",
  "effect_type": "Execution | Communication | BehavioralInfluence | DataMutation | SensoryCapture | Deletion | ExternalInvocation",
  "scope": {
    "tenant_id": "string | wildcard",
    "actor_roles": ["string"],
    "resource_types": ["string"]
  },
  "rules": [
    {
      "rule_id": "string",
      "priority": 0,
      "condition": "deterministic expression",
      "action": "allow | deny | modify | escalate",
      "constraints": {}
    }
  ],
  "obligations": [
    {
      "type": "log | notify | require_human | redact | delay",
      "parameters": {}
    }
  ],
  "evaluation": {
    "mode": "deny_by_default",
    "conflict_resolution": "priority | most_restrictive | first_match"
  }
}

Deterministic evaluation and PolicyHash

Policy evaluation MUST NOT depend on:

• LLM interpretation alone
• Probabilistic scoring
• Implicit reasoning chains

Allowed

• LLM-assisted input classification, before policy evaluation
• LLM-assisted suggestions

Not allowed

• An LLM deciding the authorization outcome

If evaluation cannot be reproduced byte-for-byte, it is non-compliant.

PolicyHash

Each policy instance MUST produce a deterministic hash of the effective policy bundle (CPP-HASH-01):

PolicyHash = lowercase-hex(SHA-256(JCS(effective_policy_bundle)))

JCS is RFC 8785. The bundle is the declared policy after imports are resolved and defaults are expanded. Runtime context is excluded. Array order that changes meaning MUST be preserved. Duplicate property names are rejected. Strings are not Unicode-normalized.

PolicyHash is the cryptographic fingerprint of governance itself. Without it, audits become interpretive, policy drift becomes invisible, and decisions become non-reproducible.

Evaluation output and decision binding

Every policy evaluation MUST produce:

{
  "policy_id": "...",
  "policy_version": "...",
  "policy_hash": "...",
  "matched_rules": [
    {
      "rule_id": "...",
      "action": "...",
      "priority": 0
    }
  ],
  "disposition": "Approved | Denied | Modified | RequiresHumanAuthorization",
  "enforcement_outcome": "authorized | blocked | denied | uncertain | not_applicable"
}

At Level 2 and Level 3, CPP outputs MUST be embedded into the CAES Decision Receipt, including policy_id, policy_version, policy_hash, matched_rules, and disposition.

A decision without policy binding is not proof.

Conflict resolution, denial, and obligations

Conflict resolution

Policy systems MUST define a deterministic resolution strategy.

Allowed: priority-based, most-restrictive-wins, first-match.

Not allowed:

• Ambiguous rule resolution
• Implicit precedence
• Runtime-dependent ordering

Deny-by-default

default_disposition = Denied

If no rule matches, evaluation fails, or context is incomplete, the disposition is Denied.

Absence of permission is denial.

Obligations

Policies MAY define obligations that accompany decisions. Examples include logging requirements, human approval workflows, redaction transformations, and notification triggers.

• Each obligation MUST set phase to pre_effect, continuous, or post_effect. (CPP-OBL-01)
• Obligations MUST NOT override disposition. (CPP-OBL-02)
• Obligations MUST be auditable and deterministic. (CPP-OBL-03)
• A failed pre_effect obligation MUST leave execution authority ungranted.
• A failed continuous obligation MUST stop further covered effects. Bytes already released stay in the outcome evidence.
• A failed post_effect obligation MUST be recorded with a remediation duty and MUST NOT be treated as undoing a completed effect.

Change control, behavior, and lifecycle

Change control

• Immutable history. No in-place edits.
• Version creation. Every change is a new version.
• Traceability. All versions MUST remain accessible.

Prohibited:

• Silent policy updates
• Retroactive mutation
• Version aliasing

Behavioral policy enforcement

CPP MUST support governance of AI-generated responses, recommendations, instructions, and persuasive outputs. Behavioral outputs MUST pass policy evaluation, produce a Decision Receipt, and bind the output to policy.

Words can be actions. CPP governs both.

Lifecycle governance

CPP MUST support policies for:

• Data capture. Consent validation and scope enforcement.
• Data usage. Purpose limitation.
• Retention. Time-bound policies.
• Deletion. Pre-authorized only, and receipt-bound.

Deletion without pre-authorization is non-compliant.

Non-compliant CPP patterns

Policy design failures

• Hidden logic in application code
• Non-versioned policies
• Runtime mutation

Evaluation failures

• LLM-only decision making
• Non-deterministic evaluation
• Missing rule trace

Governance failures

• Execution without policy binding
• Behavioral output without evaluation
• Silent policy fallback

CPP conformance and CAES integration

A CPP-compliant system MUST publish:

• canonical policy schema
• canonicalization method, which for interchange is RFC 8785 over the effective policy bundle
• hashing algorithm, which for interchange is SHA-256 lowercase hex
• evaluation engine description
• conflict resolution strategy
• obligation execution model, including the phase of each obligation type
• tenant-selector rules and whether cross-tenant wildcards are installed
• the action-to-disposition mapping

CPP enables PolicyHash binding, deterministic audit, offline verification, and cross-system governance portability.

A policy is not a configuration. It is a deterministic contract whose outcome can be proven, reproduced, and independently verified.

Design rationale (non-normative)

Deterministic, verifiable policy allows governance claims to be checked independently rather than accepted on trust. Where policy exists only as informal or mutable configuration, conformance cannot be reproduced or audited after the fact.

Under CPP, policy is expressed as a deterministic, hashable contract. Decisions are replayable against the exact policy state that produced them. Governance evidence is portable and independently verifiable across systems.

This rationale is informative. It imposes no requirements beyond the normative sections above and does not modify the canonical statement.

Changes from v0.1.1

v0.2.0 is a hardening pass. The three primitives remain. The requirements around them are now testable. Full rationale is in CAES_v0.2.0_CHANGES.md. CPP v1.0 is published with this version and is required from Level 2 upward.

Unchanged from v0.1.1: why CAES exists, the reference-implementation practice, the Working Group, the amendment process, mark usage, and the license. No implementation architecture is required.

Status

CAES v0.2.0 is a public draft released for review and comment.

This version supersedes v0.1.1. It introduces normative strengthening of the core primitives, compliance levels, fail-closed semantics, authorization-execution separation, decision dispositions, the Effect Boundary definition, behavioral governance, and privacy and recording requirements.

This public draft also includes the interoperability completion: separate Level 1 Decision Records and Level 2 receipts, the applicability matrix, the JWS profile, effect composition, the enforcement state machine, streaming, the replay lifecycle, obligation phases, chaos fixtures, and the v0.2.0 Evidence Pack annex. Where an earlier paragraph of this page conflicts with Interoperability contracts, the contracts control.

Implementations conforming to v0.1.1 SHOULD review this version for new testable requirements before claiming v0.2.0 conformance.

CPP v1.0 is a public draft. It is the canonical policy protocol for systems claiming CAES Level 2 or Level 3 under v0.2.0.

Feedback and formal amendment proposals are welcome.