13. Conformance
This section specifies the conformance criteria for runtimes that claim to implement this protocol.
13.1 Conformance Classes
The protocol defines three primary conformance classes and one orthogonal axis.
The three primary classes plus one intermediate federation class are:
- Core. The runtime implements the seven primitives (Worker, Role, Signal, Intent, Capability, Audit Envelope, Knowledge Base), the two deployment artefacts, the three cross-cutting requirements, the runtime behavioural semantics, the Capability Provider contract, the Audit Envelope structure, and the Cost Record. Compliance Profile support is OPTIONAL. Knowledge Base support (§3.7) is REQUIRED: every Core-conformant runtime MUST implement the Knowledge Base primitive, the two-axis Authority Grant (§3.2.4 Knowledge Base authority), the resolved-version-and-content-hash audit fields (§9.2), and the Knowledge Base event kinds (§9.1). Cross-Workforce Knowledge Base reads (§3.7.5) are NOT required at Core — Core runtimes MAY refuse them.
- Compliance-Capable. Core, plus full Compliance Profile attachment, evaluation, and enforcement per §11.
- Federated-Read. Compliance-Capable, plus cross-Workforce read of Knowledge Bases per §3.7.5: the runtime accepts retrievals against Knowledge Bases owned by other Workforces (subject to reader-side Authority Grant and owner-side
export_grants), records the retrieval with provenance refs per §9.2, and implements the replicated-read staleness audit (synced_at,kb_version_at_sync) where it operates replicas. Federated-Read is the v1 federation surface for shared state. - Federated. Federated-Read, plus federation per §9.5 (cross-Workforce work with linked Audit Envelopes across Intent dispatch and co-owned writes). Co-owned writes to Knowledge Bases are not specified in this draft; the full Federated conformance class is not currently claimable.
The orthogonal evaluation axis applies independently to any primary class:
- Evaluation L1. The runtime emits the Evaluation and Recalibration event types specified in §9.1, permits Operators (§7.4) to commission Evaluations on demand, and supports the
worker-instanceandrolescopes specified in §12.2.1. - Evaluation L2. L1, plus support for all six Evaluation scopes (§12.2.1) and honouring of Compliance Profile evaluation thresholds (§12.6).
- Evaluation L3. L2, plus full Recalibration workflow per §12.4, full Worker decommissioning protocol per §12.5 including handover, and Compliance Profile evaluation cadence enforcement.
A runtime claiming a class MUST satisfy all requirements of that class and all lower classes (and lower Evaluation levels, if it claims an Evaluation level). A runtime MUST NOT claim a class or level it does not satisfy. A Core-conformant runtime MAY claim Evaluation L1, L2, or L3 independently of Compliance-Capable; conversely a Compliance-Capable runtime MAY omit Evaluation entirely (in which case it MUST refuse Compliance Profiles that contain Evaluation cadence or threshold constraints). A Federated-Read runtime MUST be at least Compliance-Capable; cross-Workforce Knowledge Base reads are tightly bound to the Authority Grant and audit-envelope guarantees that Compliance-Capable runtimes provide.
13.2 Required Behaviours
A Core-conformant runtime MUST:
- Permit Worker instantiation, decommissioning, and persistent state.
- Issue stable Worker IDs and stable Workforce IDs in conformance with §3.1.2 and §4.2.2.
- Verify Function signatures before instantiation (§4.1.5).
- Enforce Authority Grants on every outbox action (§6.7).
- Enforce Intent Grammar on every Dispatch (§6.4).
- Enforce Escalation Routes on every Escalation attempt (§6.5).
- Deliver Signals to subscribed Workers per §6.1’s guarantees.
- Emit all event types listed in §9.1 to Audit Envelopes, per their schemas in §9.2.
- Hash-chain and sign Audit Envelope events per §9.3.
- Seal Envelopes on root Intent resolution per §9.4.
- Emit Cost Records per §10.1.
- Mediate Capability invocations per §8 and §6.7.
- Provide a query interface for aggregating Cost Records per §10.2.
- Support at least the synchronous Capability invocation semantic. Asynchronous and streaming MAY be optional for Core; a Core-only runtime that does not support them MUST refuse registration of Providers requiring them.
- Mutually authenticate with Capability Providers per §8.5.
- Refuse and audit-log unauthorised actions; never silently drop them (§6.7).
- Register Knowledge Bases per §3.7.2 (manifest validation, owning-Workforce signature verification, URI uniqueness within the Workforce).
- Enforce the two-axis Authority Grant (Capability authority and Knowledge Base authority, §3.2.4) on every Knowledge Capability invocation. Refuse retrievals where either axis denies.
- Emit
KnowledgeBaseRegistered,KnowledgeBaseVersionCreated,KnowledgeBaseCurrentPointerMoved,KnowledgeContributionProposed,KnowledgeContributionAccepted,KnowledgeBaseRetentionPolicyChanged, andKnowledgeBaseRetiredevent types per §9.1. - Persist
knowledge_base_id,knowledge_base_version, andretrieved_content_hashon every Knowledge Capability invocation event per §9.2. Re-fetches at the same(kb_id, version)MUST be bit-identical. - Honour
contribution_policyon the Knowledge Base manifest (§3.7.2, §3.7.6): refuse contributions to Bases with policyclosed; queue contributions to Bases with policycuration-required; materialise immediately for Bases with policyauto-accept.
13.3 Test Vectors
This draft does not include test vectors. A companion test-vector document will be published alongside subsequent drafts. Conformance test vectors will cover:
- Authority Grant evaluation for representative Roles.
- Intent Grammar enforcement on Dispatch.
- Audit Envelope hash chaining and signature verification.
- Cost Record aggregation correctness.
- Escalation propagation.
- Compliance Profile constraint evaluation (Compliance-Capable class).
Implementations claiming conformance SHOULD pass all applicable test vectors and SHOULD publish their test-vector pass rate.