Correctover Conformance Shape

CCS Receipt Specification: Compliance Checklist

A field- and control-level checklist for evaluating whether an agent runtime produces, verifies, propagates, and enforces CCS receipts consistently with the published CCS specification.

Specification tracking document 22-field receipt 7 verification dimensions Levels 0–4 10 conformance vectors Not yet an RFC number

Status note. This checklist is based on the publicly posted CCS specification (Correctover Conformance Shape, revision 08, August 2026), archived on Zenodo (DOI 10.5281/zenodo.21783723). It deliberately uses the neutral title “Compliance Checklist”: the document is Correctover’s own conformance material, not a third-party certification.

How to use this document

Use it as a buyer audit sheet, vendor response matrix, or implementation test plan. A conforming deployment should answer each question with evidence: a signed receipt sample, configuration hash, public key, test log, source-code reference, or API response.

01 / SCHEMA

Do not accept a receipt by vibe

Require every required field, exact type, canonical JSON, and a detached Ed25519 signature over fields 1–21 for Level 1+.

02 / LIFECYCLE

Admit, execute, finalize

Pre-admission evidence must be persisted before the call proceeds; the finalized post-execution receipt binds the response hash and final outcome.

03 / ENFORCEMENT

Evidence must be consumed

A receipt that is generated but not enforced is telemetry. The enforcement interface must consume the verdict and fail closed on invalid or missing evidence.

The seven verification dimensions

The draft abstract defines seven dimensions: Structure, Schema, Latency, Cost, Identity, Integrity, and Security. They are not marketing labels; they map to concrete runtime evidence and controls.

StructureThe command, intake envelope, and receipt must be well-formed and complete. Malformed intake must fail closed with no receipt.

SchemaField names, types, enum values, canonical JSON, and the 22-field receipt schema must match the specification.

LatencyVerification must have bounded runtime behavior. The draft records in-process and out-of-process deployment performance and timeout requirements.

CostPolicy and rule behavior must be deterministically bound by configuration; outcomes must not silently depend on hidden or mutable internal state.

IdentityThe issuer, audience, verifier source class, public key, and agent/tool identity are bound into the evidence.

IntegrityRequest, response, runtime context, config, and signed bytes are hash-bound; Ed25519 provides non-repudiation at Level 1+.

Security16 structural security rules, fail-closed enforcement, replay prevention, freshness windows, and key isolation controls are required.

22-field receipt compliance table

The field list follows the CCS Receipt Schema and Receipt Field Summary table. Required levels and normative status are reproduced from the draft.

Table 1. CCS v1.3 receipt fields and minimum verification evidence.
#	Field	Type	Level	Status	What to verify	Spec anchor
1	`trace_id`	16-hex string	0	MUST	Uniquely identifies the verification event; derived from a high-resolution timestamp hash and truncated to 16 hex chars.	Section 4.1, Figure 4
2	`verdict`	enum string	0	MUST	Exactly one of `allow`, `deny`, or `escalate`.	Section 4.1, Section 4.4
3	`timestamp`	float	0	MUST	Time at which the verdict was finalized.	Section 4.1
4	`tool`	string	0	MUST	Binds the decision to the exact tool name from the command.	Section 4.1, Section 6.4
5	`params_hash`	16-hex string	0	MUST	SHA-256 of canonical JSON command parameters, truncated to 16 hex chars.	Section 4.1
6	`rule_summary`	string	0	MUST	Pipe-delimited `rule_name=verdict` pairs; must not expose internal thresholds or weights.	Section 4.1, Section 4.7
7	`receipt`	32-hex string	0	MUST	Legacy Level 0 HMAC-SHA256 authentication field; must not be used as the Level 1+ Ed25519 signature.	Section 4.2
8	`verified_at`	float	0	MUST	Verification timestamp; not part of the Level 1 signed field set in the summary table.	Section 4.1, Figure 10
9	`block_reason`	string	0	Conditional	Required and non-empty for deny/escalate; must be empty for allow.	Section 4.1
10	`request_hash`	hex string	1	MUST	Binds the receipt to the full canonical request bytes.	Section 6.1
11	`config_hash`	hex string	1	MUST	Binds the exact rule set, policy version, and canonical configuration.	Section 5, Section 5.3
12	`response_hash`	hex string	1	SHOULD	Post-execution response binding; finalized after the tool returns.	Section 6.2, Section 4.2 lifecycle
13	`runtime_context_hash`	hex string	1	SHOULD	Binds runtime context such as executor state and environment metadata.	Section 6.3
14	`action`	string	1	MUST	CAID-compatible action identifier; the draft records 14 enum values.	Section 6.4
15	`issuer`	URI string	1	MUST	Identifies the verifier that issued the signed receipt.	Section 6.6
16	`audience`	URI string	1	MUST	Identifies the intended enforcement consumer; wrong audience must reject the receipt.	Section 6.7, CV-005
17	`nonce`	hex string	1	MUST	Single-use anti-replay value.	Section 6.8
18	`sequence`	integer	1	SHOULD	Monotonically increasing counter for ordering and replay resistance.	Section 6.8
19	`issued_at`	float	1	MUST	Receipt issue timestamp.	Section 6.9
20	`expires_at`	float	1	MUST	Receipt expiry timestamp; expired receipts must be rejected.	Section 6.9, CV-006
21	`max_clock_skew`	float	1	SHOULD	Clock tolerance in seconds; default recorded as 30.0.	Section 4.1, Section 6.9
22	`signature`	128-hex string	1	MUST	Detached Ed25519 signature over RFC 8785 canonical JSON of fields 1–21; v1.3 is Ed25519-only for this field.	Section 4.2

Canonical signature example

// 1. Build fields 1-21 only.
// 2. Apply RFC 8785 JSON Canonicalization Scheme.
// 3. Sign canonical bytes with the issuer Ed25519 private key.
// 4. Encode the 64-byte signature as 128 lowercase hex characters.

canonical_bytes = RFC8785_canonicalize(receipt_without_field_22)
receipt.signature = ed25519_sign(issuer_private_key, canonical_bytes).hex()

// Verification reconstructs fields 1-21, canonicalizes, and verifies.

Normative controls checklist

These are the make-or-break items for procurement. If a vendor cannot show evidence for these, the receipt should be treated as unauditable telemetry, not runtime verification evidence.

Fail-closed intake: malformed or incomplete intake returns the appropriate error and produces no receipt.
Detached Ed25519 signature: field 22 signs fields 1–21 after RFC 8785 canonicalization and does not sign itself.
Algorithm separation: HMAC truncation is only the legacy Level 0 field 7 mechanism; Ed25519 is required for Level 1+ non-repudiation.
Config binding: config_hash identifies the exact rule set and policy version so an old receipt cannot be reinterpreted under a new policy.
Request and response binding: request_hash and response_hash bind the evidence to the exact input and output bytes.
Pre-execution durability: admission evidence is persisted before enforcement permits the invocation to proceed.
Post-execution finalization: the final 22-field receipt is completed after response hashing and outcome determination.
Audience restriction: consumers reject receipts whose audience does not match their identity.
Freshness and replay controls: nonce, sequence, issued_at, expires_at, and max_clock_skew are enforced.
Verifier source classification: third parties can distinguish self-built, audited, and self-declared verifier sources.
Structural rule language: each security rule is expressed as a structural existence test with trigger and scope, not as hidden heuristic logic.
No hidden engine exposure: internal thresholds, weights, and rule internals are not required on the wire; the externally verifiable artifacts are hashes, signatures, and rule summaries.
Enforcement interface: the enforcement layer consumes CCS verdict/receipt artifacts and has a defined mapping to allow/deny/escalate behavior.
Transport and ledger independence: receipts can be verified without requiring a particular transport, transparency service, or ledger.

Conformance levels

Level 0

Baseline. Produces a signed Level 0 receipt covering trace, verdict, timestamp, tool, parameter hash, and rule summary, with fail-closed enforcement and in-process deployment.

Level 1

Extended bindings and Ed25519. Adds all 22 fields, including request/config/response/runtime hashes, action, issuer, audience, anti-replay fields, expiry, and detached Ed25519 signature.

Level 2

Out-of-process isolation. Verifier runs in a separate crash domain over Unix socket or TCP+TLS, with key isolation and cross-replica replay prevention.

Level 3

Multi-hop verification. Adds chain-of-custody verification across executor hops, local audience binding per hop, and non-negotiable server-side policy floor.

Level 4

Evidence propagation. Adds cross-organization Evidence Envelopes, Evidence Chains, offline chain verification, enforcement interface compliance, and EC summary hash support.

Conformance vectors

The draft defines self-contained test cases CV-001 through CV-010. A procurement POC should require these as executable tests rather than slide claims.

Table 2. CCS conformance vectors CV-001 through CV-010.
Vector	Level	Pass condition
`CV-001`	0	Basic ALLOW receipt has valid HMAC-signed bytes and complete rule summary.
`CV-002`	0	Basic DENY receipt produces a non-empty block reason and denies the RCE pattern.
`CV-003`	1	Different rule sets produce different `config_hash` values for the same command.
`CV-004`	1	Different parameters produce different `request_hash` values.
`CV-005`	2	A receipt issued to audience B is rejected by consumer C.
`CV-006`	2	An expired receipt is rejected after `expires_at`.
`CV-007`	4	Malformed intake fails closed with `INTAKE_MISSING_FIELD` and no receipt.
`CV-008`	4	Delegation creates an Evidence Envelope and a downstream receipt referencing the original receipt hash.
`CV-009`	4	Cross-org envelopes are self-contained and verifiable offline.
`CV-010`	4	EC summary hash is insertion-order SHA-256 over receipt hashes and changes when any receipt changes.

Procurement mapping: from compliance question to evidence

Table 3. Procurement questions mapped to cryptographic evidence.
Buyer question	CCS evidence to demand	Failure signal
Did the agent really make this exact tool call?	Canonical request bytes, `request_hash`, tool name, parameter hash, and signature verification log.	Vendor only shows application logs or a dashboard screenshot.
Under what policy was the decision made?	`config_hash` plus retrievable canonical configuration snapshot.	Policy version is mutable or not bound to the receipt.
Can a malicious actor forge or replay an approval?	Ed25519 public key, detached signature verification, nonce, sequence, and expiry test results.	Shared HMAC secret only, no replay test, or long-lived unsigned approvals.
What happened after admission?	`response_hash`, lifecycle state, and finalized post-execution receipt.	Evidence stops at request admission and cannot bind the response.
Can another organization verify the evidence independently?	Self-contained Evidence Envelope/Chain and offline verification result for Level 4.	Verification requires live access to the vendor’s cloud or control plane.
Can the policy engine hide malicious permissiveness?	Verifier source classification, audited build evidence, capability manifest, and structural trigger/scope audit.	“Trust our model” with no external verifiable artifact.
Does the gateway actually enforce the verdict?	Enforcement interface mapping, fail-closed test, and invalid/missing receipt rejection test.	Receipts are generated in observe-only mode with no blocking path.

Sales positioning. The buyer should not compare CCS as “another scanner.” The right question is: “Does this tool produce cryptographic, independently verifiable runtime evidence, or does it only generate detection alerts with false-positive risk?”

Implementation evidence and references

Use these links to validate that the specification is backed by running code and independent interoperability testing, not only prose.

Independent interop note. The draft records two interoperable implementations and a 14/14 conformance check using the exact detached Ed25519 signing procedure. Ask vendors to reproduce CV-001 through CV-010 against their own receipts rather than relying on a self-attested compatibility claim.