CAES Standards

Versioned standards.Verifiable conformance.

CAES defines the minimum structural requirements for governed execution. This page keeps the public claim narrow: versioned standard language, explicit conformance boundaries, and reviewable evidence posture without pretending to certify a deployment.

Request Access Review Proof

CAES version: v0.2.0. Policy profile: CAES governed execution sample policy. Reference implementation scope does not imply certification, universal conformance, or default Level 3 posture.

What CAES Enforces

A standard has to deny cleanly before it can claim authority.

Conformance posture is structural, versioned, and fail-closed.

[01]

CAPTURE INTENT BEFORE EFFECT

Execution starts too early.

INTENT: CAPTURED

[02]

EVALUATE THE ACTIVE POLICY

Conformance becomes interpretation.

POLICY: EVALUATED

[03]

BIND DECISION TO RECEIPTS

Receipts lose structural meaning.

DECISION: BOUND

[04]

REQUIRE FAIL-CLOSED DENIAL

Ambiguity still passes.

ENFORCEMENT: FAIL-CLOSED

If the system cannot deny under missing authority, the standard has not become runtime behavior.

Standard-Safe Fixture

The default scenario on this page is a deterministic denied request: missing authority anchor blocks regulated export. It demonstrates structural posture, not a deployment-wide conformance claim.

receipt_id

d711a2d4-d9ee-429b-a970-c129d0d62f4d

receipt_name

CAES sample decision receipt

caes_version

v0.2.0

requested_capability

data.export.regulated

decision_status

denied

execution_status

not_attempted

denial_reason

missing_required_authority_anchor

enforcement_mode

fail_closed

policy_profile_name

CAES governed execution sample policy

policy_hash

sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

signature_status

verifier_bound_fixture

Reference Implementation Scope

Keon is presented here as the reference implementation for the governed execution requirements shown on this page. This is not third-party certification, standards-body approval, or a claim that every deployment mode is automatically conformant.

Deployment conformance depends on the configured policy set, receipt persistence, verifier material, and governed effect boundaries in scope.

Conformance Levels

CAES version: v0.2.0. Keon public reference scope currently demonstrates selected governed execution requirements. Formal deployment conformance requires a complete conformance statement.

Level names matter, but the public claim stays limited to the evidence and scope shown here.

Level 1

Receipt-Bounded Execution

Level 2

Verifiable Evidence Chain

Level 3

Full Constitutional Conformance

Level 1: receipt-bounded execution with fail-closed denial.

Level 2: verifiable evidence chain with policy canonicalization.

Level 3: full constitutional conformance with a scoped conformance statement.

Receipt Shape

A CAES-governed outcome must produce the evidence appropriate to the decision path. A denied action may produce directive, intent, decision, and outcome receipts while intentionally omitting execution.

Receipt Shape

Receipt shape depends on the decision outcome

Decision

Intent typed + policy evaluated

Boundary

PolicyHash + decision receipt

Evidence Pack

Verifier-bound evidence bundle

Verifier Review

trust material required

✓

What a CAES conformance claim must include

A credible conformance statement has to be explicit about version, scope, verification method, and evidence location. Broader claims fail closed.

CAES version

Claimed conformance level

Receipt verification method

PolicyHash canonicalization method

Fail-closed enforcement description

Governed Effect Boundary categories

Evidence artifact location

Trust material required for verification

Source Links

CAES normative specification →

Versioned requirements: effect boundaries, structural primitives, and conformance tiers.

CAES source repository →

Source material for the public draft and related doctrine.

Proof surface →

Review proof posture without turning this page into a verifier.

CAES Boundary Check

Does this governed request satisfy the minimum CAES structural requirements?

This route uses a safe denied regulated-export scenario when the MCP Gateway is configured. It demonstrates structural CAES requirements only: boundary shape validated, deployment conformance not claimed, certification not claimed, and third-party approval not claimed.

Fixture shown because the gateway was unavailable.

Boundary shape valid

Minimum CAES structural fields are present.

Execution not attempted

Denied path intentionally omits execution.

Receipt-backed denial

Directive, intent, decision, and outcome remain in scope.

Deployment conformance not claimed

This check validates boundary shape only.

Structural Result

check_type

caes_boundary_shape

caes_version

v0.2.0

requested_capability

data.export.regulated

decision_status

denied

execution_status

not_attempted

policy_hash

sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

receipt_id

d711a2d4-d9ee-429b-a970-c129d0d62f4d

conformance_result

shape_valid

deployment_conformance

not_claimed

source

fixture

Non-Compliant Patterns

CAES rejects posture theater. These patterns weaken the governed effect boundary and should not be presented as conformance.

Prompt-only policy enforcement

Post-hoc logs presented as authorization proof

LLM-only policy decisions

Mutable logs presented as evidence ledgers

Silent degradation under failure

Invocation-layer governance bypass

What comes next

Ready to review the standard posture in context?

Request access when you are ready, review proof posture, or read the source draft directly.

Request Access →Review Proof →Read CAES Source →