The Correctover Conformance Shape (CCS) specification — IETF Internet-Draft draft-correctover-ccs-06
, Experimental status — defines a runtime verification framework for AI agent tool calls across seven dimensions: Structure, Schema, Latency, Cost, Identity, Integrity, and Security.
As of August 2026, two independent implementations from separate codebases now pass all 14 conformance checks. This post documents what was achieved and what it means.
correctover
at version 2.4.9ccs-verifier
Python package5fb2eae9b20d17685e1ecbe061eb4ced03dbe64e
The EMILIA runner is located at conformance/composition/ccs-v13-aeb-v1
in the emilia-protocol
repository.
The EMILIA runner passes all 14 checks:
params_hash
)The v1.3 receipt contains 22 fields. A detached Ed25519 signature is computed over the RFC 8785 canonical JSON serialization of fields 1–21. Field 22 carries the signature itself and is excluded from the signing input.
Key mechanisms:
ensure_ascii=False
to maintain proper Unicode handling during canonicalization.The -06
revision includes several substantive clarifications:
ensure_ascii=False
is required for RFC 8785 compliance; the previous text did not make this explicit.response_hash
(the receipt is updated with the response digest after the action completes).The IETF's founding principle is "rough consensus and running code." Two independent implementations from separate codebases achieving 14/14 on the conformance suite is the strongest available evidence that the specification text is sufficient to build an interoperable implementation without reference to the author's own code. This is the bar for an Experimental RFC: demonstrate that the protocol can be built independently and that independent builds agree.
It is important to be precise about scope:
Interoperability testing confirms that the specification is implementable from the text alone. It does not, by itself, prove production readiness, security at scale, or real-world deployment. Those are separate questions that require separate evidence.