Skip to content
OWP

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, Worker Definition, Signal, Intent, Capability, Audit Envelope, Memory), 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. Memory support (§3.7) is REQUIRED: every Core-conformant runtime MUST implement the Memory primitive, the two-axis Authority Grant (§3.2.4 Memory authority), the resolved-version-and-content-hash audit fields (§9.2), and the Memory event kinds (§9.1). Cross-Workforce Memory reads (§3.7.10) 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 Memory items per §3.7.10: the runtime accepts retrievals against Memory items 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, memory_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 Memory items 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-instance and role scopes 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 Memory 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 Memory items per §3.7.4 (manifest validation, owning-Workforce signature verification, URI uniqueness within the Workforce).
  • Enforce the two-axis Authority Grant (Capability authority and Memory authority, §3.2.4) on every Memory Capability invocation. Refuse retrievals where either axis denies.
  • Emit MemoryRegistered, MemoryVersionCreated, MemoryCurrentPointerMoved, MemoryRead, MemoryReinforced, MemoryDecayed, MemoryInverted, MemoryContributed, MemoryContributionAccepted, MemoryRetentionPolicyChanged, and MemoryRetired event types per §9.1.
  • Persist memory_id, memory_version, and retrieved_content_hash on every Memory Capability invocation event per §9.2. Re-fetches at the same (memory_id, version) MUST be bit-identical.
  • Honour contribution_policy on the Memory manifest (§3.7.4, §3.7.11): refuse contributions to items with policy closed; queue contributions to items with policy curation-required; materialise immediately for items with policy auto-accept. Semantic contribution and Causal inversion route through Recalibration co-signature per §3.7.13.
  • Enforce the mandatory presence of leadership Worker Definitions at Function bundle load (§3.2.7, §6.11): exactly one role-kind:leadership/workforce-director per Workforce; exactly one role-kind:leadership/function-lead per Function. Refuse Function bundles that violate either invariant.
  • Validate the measurement_criteria schema on every Intent declaration at every scope (§3.4.10). Refuse Intents with absent or malformed criteria.
  • Validate the tradeoff_narration schema on every Outcome emitted by a leadership Worker when ≥ 2 Intents at the scope are active (§3.4.11). Refuse Outcomes that fail schema validation; emit TradeoffNarrationOmissionDetected when narration is expected but absent.
  • Emit StrategicIntentTransitionSuggested (and scope-appropriate equivalents) when measurement criteria reach achievement or TTL fires (§6.10). MUST NOT auto-apply terminal state transitions for org-, workforce-, or function-scope Intents; the originator MUST sign the transition for it to take effect.
  • Refuse Intent content mutation. Amendment to an Intent’s content (scope, kind, measurement_criteria, target, payload) MUST occur via supersession (§3.4.7): declare-new + withdraw-old with mutual provenance links.
  • Enforce empty-grammar semantics (§3.2.5): an empty accepts accepts nothing; an empty generates generates nothing; refusals are distinct, citable errors. MUST NOT treat an empty Intent Grammar as permissive.
  • Enforce declared Capacity (§3.2.9): never route a Dispatch to a Worker at its declared ceiling; queue and emit DispatchQueued when the eligible set is exhausted (§6.4.1).
  • Validate declared Output Contracts on Resolution (§3.2.10): refuse structurally non-conformant Outcomes with a citable error; never constrain the content of free-text fields.
  • Apply Measurement Defaults (§3.2.11): an Intent without explicit criteria inherits its kind’s declared default from the generating Worker Definition; explicit criteria win.
  • Evaluate structured decision-scope clauses (§3.2.4) on the relevant action paths: within-bound actions proceed; over-bound actions with on_exceed: escalate require escalation (a substituted Resolution is refused); bypass attempts emit authority-violation events.
  • Resolve allocation for workforce-scope Intents in the §6.12.1 trigger order (explicit target → live weighted route → deliberation); record route use with weight; emit the §6.12 deliberation and route events with their declared signers.
  • Persist the per-Authority Strategic Intent Registry (§9.6) with hash-chain integrity, signed events, and the storage layout described therein. Expose registry append + load + state-query operations behind mTLS-authenticated service interfaces.
  • Cascade org-scope Strategic Intents to every Workforce Director Worker in the Authority. Each Director MUST emit either a decomposition or a StrategicIntentDeclined resolution; silence is not acceptable.
  • Cache leadership-Worker decompositions per upstream Intent (§6.8). Re-reason only on upstream declaration or supersession, not on every Signal.

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 Worker Definitions.
  • 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.