Adopters & interop matrix

Last updated: 2026-09-13 (the reference host re-cut on suite 2.1.6 — 187 / 0 / 0 / 44 / 0, 1606 assertions, all three claimed profiles certified, and check-cut-gates --host-bundle clears all ten predicate groups, 0 failed 0 blocked: the only fully-clean host bundle in this table. It had been the STALEST row here, measured on 2.0.0-rc.61 while the suite moved sixty-plus releases — accurate for the suite that ran it, which is all this table asks, but unable to answer suiteVersionCheck's question, "did this bundle run everything this corpus now requires of a host at its major". A stale row is not a neutral default, and the steward's own host should not be the last to act on that.) Previous, 2026-09-10 (v2 is the released major — v2.0.0 tagged 2026-09-05, corpus v2.1.6 tagged 2026-09-11 and suite 2.1.4 on npm; the v2 table below is no longer a release-candidate table. Rows are unchanged: each still carries the suite that measured it, and MyndHyve's 2.0.8 re-cut — 136 / 0 / 90 / 0, openwop-discovery-core certified, discovery.document present — is that host's bundle to check in, not the steward's to transcribe.) Previous, 2026-09-05 (the reference host re-cut on suite 2.0.0-rc.61 and still certifies every profile it claims — openwop-host-v2-reference@2.0.0-rc.1 at d029f8fe, 181 / 0 / 0 / 42, Identity through Front door PASS. The rc.59 bundle went stale the moment rc.60 landed: the Front door gate refused it because 1 of 72 major-2 scenario files had no row in it, so its totals said nothing about v2-run-fork-prefix — a bundle that never measured a scenario cannot speak for it. The two rows added since are that fork-boundary witness (this host is exclusive and passes it) and rc.61's kind: other note assertion (vacuous here). Earlier: the first bundle from any host to clear all of §F, at 48e26b72 on suite 2.0.0-rc.58; it replaced the rc.57 bundle checked in earlier that day, which measured a stale local process (disclosed in its row), and the clock anchor for this host stays on that commit by the mechanical rule. Earlier: every v2-table host now carries a non-vacuous major-2 bundle — the reference example re-cut on suite 2.0.0-rc.57 under the rotated key v2-reference-2: witnessCount 3 / 8 / 4, certified: none because the corpus moved past its own example between rc.16 and rc.57 (10 executed-fail rows, host fixes queued in openwop-examples); with all three hosts anchored the v1 end-of-support clock computes its first date. Earlier: both production hosts carry non-vacuous major-2 bundles — openwop-app openwop-app-backend-00678-2sr at f8e24beb7 joins MyndHyve below: suite 2.0.0-rc.56, signed and self-verified, cut at one worker through the Firebase Hosting + Cloud Run front door, openwop-discovery-core witnessCount 3 → non-vacuous, certified: none (2 v2-poll-cursor-v2 fails = Gap C, seams surface not advertised = Gap A). Earlier the same day: first production major-2 bundle checked in — MyndHyve workflow-runtime-00330-cjg at 847d2425e, suite 2.0.0-rc.56, signed and self-verified, openwop-discovery-core witnessCount 3 → non-vacuous, so it anchors the v1 end-of-support clock (spec/v2/core/overview.md §v1 end-of-support; the anchor date is the merge commit that first carries the file, recorded by scripts/generate-v1-eos-clock.mjs in a follow-up commit). Not certified: its seams surface is not advertised, so the Coexistence rows stay blocked. Previous update, 2026-08-24: MyndHyve webhook delivery headers corrected and SERVING — workflow-runtime-00574-baw at 100%, replacing 00572-noc: X-openwop-Signature: sha256={hex} and X-openwop-Webhook-Id, matching webhooks.md §"Delivery headers". The header shape is not live-witnessed — the host carries zero webhook subscriptions, so nothing observed a real delivery; the bytes are covered by unit and wire-level tests, red-before-green by sabotage. Rollback --to-revisions=workflow-runtime-00572-noc=100.) 2026-08-19 (MyndHyve bundle v2 #15, suite 1.136.11). Per-bundle conformance history is in the Update log below; release-level changes are in CHANGELOG.md.

A live record of OpenWOP-compatible hosts — their advertised compatibility profiles and the conformance evidence behind each claim. A row is a claim plus evidence: the claim is the host's advertised profile; the evidence is the conformance result published with the host (or under conformance.md). Evidence vocabulary (RFC 0148 §A/§C, RFC 0155 §E): a claim is certified only when a bundle v2 shows every floor requirement of the profile in a certifiable disposition with a witnessed assertion count; rejected when a floor requirement returned unclassified (no row, or a zero-assertion pass); unprovable when the profile has no floor in PROFILE_FLOOR_SCENARIOS (RFC 0148 §C G6); and a self-declaration otherwise. Evidence tiers (steward / steward-affiliated sibling / independent-organization) follow GOVERNANCE.md §"Acceptance evidence tiers"; no independent-organization row exists. openwop-discovery-core is the canonical name of the discovery predicate; openwop-core is its deprecated v1 alias and both derive together — an unqualified "OpenWOP conformant" statement means openwop-core-standard. openwop-node-packs is runtime-derived (profiles.md): from suite 1.117.0 a bundle claims it only when the host holds it (both floor scenarios witnessed passes); the 1.116.0 rows below that read rejected for it would read not held under 1.117.0 — same evidence, honest name.

v2 — the current major (corpus v2.1.7; suite 2.1.4 published)

The rows below were cut on release candidates and early 2.0.x patches — the suite version in each row is the one that measured it, and a row is never rewritten to a suite that did not run. v2.0.0 was tagged 2026-09-05; a host that has re-cut on a later suite replaces its own row with its own bundle (evidence/v2-host-bundles/<host>.json).

The charter's §F Witness and Front door predicates are measured on a host implemented from spec/v2/core/ rather than adapted from a v1 host — that is what the Front-door predicate asks, and building it is what found seven corpus and six suite defects before the cut. Neither the in-memory nor the SQLite reference host can reach the v2 floor (no fork substrate, no packs, no Subject), so they stay on the 1.x line through the overlap and appear only in the table below this one.

Verify a row with node scripts/check-cut-gates.mjs --host-bundle <bundle>.

How to read the reference row (rc.58 measurement). Zero executed-fail, zero blocked: the host caught up with the rc.40–rc.53 prose on 2026-09-05 (the example's conformance.md lists each rule), and the suite fixed v2-era-2-append-vocabulary in rc.58, which had read events off the response object and could never witness the writer rule on any host. The 42 inapplicable rows are optional families the host does not advertise (a2a, mcp, saml, scim, packs), recorded with their reasons, plus the corpus-ledger row (inapplicable since rc.57). The paragraph below describes the rc.16 measurement and is kept for the history of the row.

What the 16 blocked rows were (rc.16). Optional families the host does not implement and therefore does not advertise (a2a, mcp, saml, scim), a rate limit no run provoked, a windowed revocation lane, an alias family, and the corpus ledger the published tarball does not ship. Each row states its reason; none is a silent skip. The row claims self evidence tier: the steward built the host, so it is not independent evidence about anyone else's implementation, and it certifies nothing.

Hosts

SAML ⟷ SCIM subject linking — key class + same-IdP trust root (RFC 0159 + 0163 — capabilities.auth.subjectLinking / subjectLinkKey)

RFC 0163 graduated Active → Accepted on 2026-09-02 on tier-1 single-witness evidence per GOVERNANCE.md §"Acceptance evidence tiers" — the steward's own reference host, under the bootstrap waiver, exactly as RFC 0159 did on 2026-09-01. RFC 0164 (the contract becomes mandatory for any host advertising both profiles; subjectLinking is derived) graduated the same way on 2026-09-02 — openwop-app #3620 (873efc466, ADR 0623). Not dual-witness, not independent-organization evidence.

The claim is narrow: a host that advertises both openwop-auth-saml and openwop-auth-scim and sets subjectLinking: true MUST also name the class it joins the two lanes on (subjectLinkKey ∈ {opaque-idp, configured-immutable}, schema-required by conditional), MUST join only on that class, and MUST NOT form a link unless the SAML assertion's signed <saml:Issuer> equals the IdP entityID bound to the SCIM connection. No production host advertises subjectLinking — openwop-app emits it only when both seams are configured, MyndHyve's live discovery carries no auth block — so this row records a seam-witnessed implementation, not a production advertisement.

RFC 0165 — v2 preparation wire shapes (protocolVersions[], owner.subject, OpenWOP-* dual emission, discovery ETag)

Graduated Active → Accepted on 2026-09-03 on tier-1 + tier-2 evidence (both steward-owned hosts; not independent-organization evidence). What each host does, and what the suite can witness against it:

Neither host mints keyClass on a run today (openwop-app only when both identity profiles are advertised under the RFC 0164 gate); neither emits actor. The §B.3 legacy-link negative remains blocked in the suite (RFC 0165 G4) until a host wires a seam that mints a legacy-issuer subject bound to a SCIM record. | In-memory / SQLite / Postgres / Python (reference examples) | Not applicable | None advertises openwop-auth-saml or openwop-auth-scim. |

Replay side-effect suppression (RFC 0140 — capabilities.replay.sideEffectSuppression)

RFC 0140 graduated Active → Accepted on 2026-08-08 on tier-1 single-witness evidence per GOVERNANCE.md §"Acceptance evidence tiers" — the steward's own reference host, under the bootstrap waiver. Not dual-witness, and not independent-organization evidence.

The claim being advertised is narrow and worth stating precisely: recorded-outcome says a mode: "replay" fork resolves a side-effecting node from the source run's recorded outcome or fails it closed with replay_source_missing — never a new effect — and that a default-deny guard sits at the host's effect seams behind the classifier. spec/v1/replay.md §"Determinism guarantees" caveat 1 binds every host regardless; hosts that omit the capability are not thereby permitted to re-fire, they simply do not expose a probeable mechanism.

Host-initiated fan-out on a replay fork (replay.md §"Host-initiated fan-out is an external effect")

The rule landed 2026-08-18: a host that projects its event log outward — webhook delivery, outbound streams, analytics sinks — MUST NOT emit those deliveries for events a mode: "replay" fork re-emits as fixed history. It is unconditional and not gated on sideEffectSuppression, which describes what a host does with node effects. Replay-ness MUST be read from the run, never from the event type.

Why two hosts is the interesting number here. MyndHyve found it by inspection of its own delivery path; openwop-app then found the identical hole — as a written, reasoned exemption (ADR 0533 recorded the seam as a deliberate residual, on the stated ground that "a replay is a distinct run whose events are genuinely new", which the new section negates). A gap found in two trees is a coincidence; a gap found in a third where the question had been explicitly asked and answered wrong is the case for a normative rule.

What this row does not claim. The conformance scenario does not independently witness the seam guard — classification and the guard mask each other in the fixture, so disabling either alone leaves the scenario green (RFC 0140 gap G8); the guard's evidence is host-side. Three node-reachable effect paths remain unguarded in openwop-app (gap G9: webhook fan-out, s3Blob.put, openSearchSearch), the first deliberately, since it is host-level fan-out with no node to fail closed. Out-of-process pack execution is uncovered — AsyncLocalStorage does not cross a worker boundary. branch-mode forks re-fire effects by design (§D).

Poison work terminates within a bounded number of attempts (RFC 0158 §C.8 — durability/poison-exhaustion)

RFC 0158 is Draft. This row records evidence for one requirement, not a rung: the RFC's ladder mints no advertised capability (§E.10 — rung and recovery bound are published in the evidence bundle), so nothing here is a claim a host advertises. Of the RFC's six conformance rows this is the only one causable without terminating a process — the other five need a host seam, a supervisor, or ≥2 instances, and none exists yet. Seam-gated on the existing /v1/host/sample/test/runs/{runId}/events log seam and outside every profile floor.

Agent Platform profile (RFC 0085 — openwop-agent-platform)

The aggregate platform profile defined in spec/v1/agent-platform-profile.md (RFC 0085, Accepted 2026-06-01). A host populates the status column when it reaches partial/full. MyndHyve — the steward-affiliated sibling host whose graduation evidence accepted the RFC — derives full; no example reference host claims it yet (honest).

Connection packs (RFC 0095 — capabilities.connections.packsSupported)

The portable provider-definition pack kind defined in spec/v1/connection-packs.md (RFC 0095, Accepted 2026-06-12). A host populates the status column when it advertises connections.packsSupported: true and implements the §Manifest clause 6 resolution contract; verification is the two capability-gated behavioral scenarios (connection-provider-resolution + connection-pack-write-reconsent) run non-vacuously against the published suite.

Multi-party group conversation (RFC 0101 — capabilities.multiPartyConversation)

The shared-transcript / speaker-attribution surface defined in RFC 0101 (Accepted 2026-06-22). A host populates the status column when it advertises multiPartyConversation.supported: true, emits the optional participants: AgentRef[] on conversation.opened, stamps speakerId on role:'agent' turns, and rejects a turn from a non-participant. The always-on leg of multi-party-conversation-shape.test.ts verifies the schema shapes server-free; the capability-gated behavioral leg (isMultiPartyConversationSupported()) verifies live roster + attribution + non-participant rejection against an advertising host.

Localized content surface (RFC 0103 — capabilities.content.supported)

The capability-gated authored-content surface defined in spec/v1/localized-content.md (RFC 0103, Accepted 2026-06-17). A host populates the status column when it advertises content.supported: true (requires i18n.supported) and serves GET /v1/content/pages/{slug} with the §C resolveSection merge; the always-on legs of localized-content-delivery.test.ts verify the schemas + merge + capability coherence server-free, and the gated legs verify live delivery + tenant isolation.

Multi-turn conversation primitive (RFC 0005 — capabilities.conversationPrimitive)

The multi-turn conversation suspend variant defined in RFC 0005 (Accepted 2026-05-11), wiring the core.conversationGate typeId + the conversation.start / conversation.exchange / conversation.close suspend variants (normative surface in spec/v1/interrupt.md + spec/v1/capabilities.md). A host populates the status column when it advertises conversationPrimitive: true and takes the conversation path over the clarification.requested fallback; verification is the capability-gated conversationLifecycle / conversationReplayDeterminism / conversationVsLegacySuspend scenarios run non-vacuously, with conversationCapabilityNegotiation covering the negative refusal contract on hosts that do not advertise.

Self-hosted / OpenAI-compatible provider class (RFC 0108 — aiProviders.selfHosted[])

The operator-/tenant-configured OpenAI-compatible endpoint class defined in spec/v1/capabilities.md §aiProviders.selfHosted (RFC 0108, Active 2026-06-24). A host populates the status column when it advertises aiProviders.selfHosted: string[] (a subset of supported[]) for a configured, reachable endpoint — honestly (§A.2, under OPENWOP_REQUIRE_BEHAVIOR), with an opaque non-URL id (§A.3), keeping the endpoint location off every wire surface (self-hosted-endpoint-no-disclosure). The always-on aiproviders-selfhosted-shape.test.ts verifies the §A field shape + the §A.1 subset / §A.3 no-URL rules server-free; the gated aiproviders-selfhosted-honesty.test.ts (lands at Active → Accepted) verifies a real dispatch against a selfHosted id with no endpoint-URL leak.

Parallel sub-workflow fan-out and join (RFC 0118 — capabilities.dispatch.fanOutSupported)

RFC 0118 graduated Active → Accepted on 2026-06-28. Both legs are now dual-witness and steward-verified (2026-06-28): the discovery/advertisement leg by /.well-known/openwop curl of each host, and the behavioral leg by a direct steward probe of each host's seam-enabled POST /v1/host/sample/dispatch/fanout returning a real, non-vacuous coordinator+fold. (At the original flip the behavioral leg was single-witness host-self-reported with a steward cross-check deferred; the deferred cross-check was subsequently run once both hosts stood up auth-exempt conf-fanout seam revisions — see the rows below. The full @openwop/openwop-conformance harness against openwop-app's tag URL tripped that host's per-IP 429 read budget during its multi-file discovery burst and soft-skipped the gated legs, so the direct seam probe is the steward behavioral artifact, alongside each host's own harness runs.) Per GOVERNANCE.md §"Acceptance evidence tiers" this remains a tier-2 (steward-affiliated sibling) + reference-host graduation — not independent-organization dual-witness.

The joinModes / onChildFailureModes divergence between the two witnesses (["wait-all"] + ["collect","absorb"] vs the full four-mode + three-mode sets) is the intended, discoverable outcome of the capability gating — a portable workflow pinning joinPolicy.mode:'quorum' or onChildFailure:'fail-fast' registers on MyndHyve and is honestly rejected at registration on openwop-app, and the author can see exactly that from each host's /.well-known/openwop at edit time (the gap RFC 0118's joinModes + openwop#789's onChildFailureModes descriptors close).

Subscription-reuse provider auth mode (RFC 0121 — aiProviders.authModes: "subscription")

The subscription auth mode defined in spec/v1/capabilities.md §aiProviders.authModes (RFC 0121, Active 2026-07-01; conformance 1.47.0). A host advertises subscription when it accepts a credential derived from reusing the caller's personal consumer subscription (Claude Pro/Max, ChatGPT Plus) — the mode is a BYOK path (§B.7, MUST be in byok), its credential MUST bind at host.credentials scope:"user" and MUST reject a tenant/workspace binding with credential_scope_forbidden (§B.8, the protocol-tier subscription-credential-user-scope-only invariant), and it MUST be advertised only when a real acquisition mechanism is configured (§B.9, truthful-advertisement). The always-on aiproviders-subscription-scope.test.ts verifies the enum shape server-free; the §B.7 leg is advertisement-gated; the §B.8 leg is bind-seam-gated (POST /v1/host/sample/credentials/bind, soft-skip on 404) so the user-scope safety rail is witnessable without a live subscription advertisement.

Partial graduation (2026-07-01): scope-safety rail only; 0121 stays Active. UQ1 (does any provider's consumer ToS permit third-party API-shaped reuse?) is UNRESOLVED — no citation exists; the steward issued an at-own-risk waiver (RFC 0121 Status history) of the acquisition-bearing gate. No host advertises subscription on a live discovery doc — the reference host is the scope-safety / reference-impl witness, not a full-advertisement witness. A full Active → Accepted graduation remains open, pending a deploy-model-compatible + UQ1-cleared advertising host (candidate: MyndHyve tier-2, per steward direction).

Anonymous-actor authorization (RFC 0132 — capabilities.anonymousActor)

The anonymous-actor model defined in spec/v1/capabilities.md §anonymousActor + spec/v1/auth.md §"Anonymous actors" (RFC 0132, Active 2026-07-22). A host advertises anonymousActor { supported:true, tiers, writeEgressControls?, failClosed:true } when it honors authorization for a caller on a public agent surface who authenticated no identity: an opaque, origin-bound, ephemeral, non-cross-linkable, non-PII principal (owner.principalKind:"anonymous") whose authority is a default-deny, explicit per-surface tool grant — never a role, never the ADR 0315-style default-on tool baseline. The read tier is tenant-scoped with no egress and no secret/BYOK reach; the bounded-write-egress tier is permitted only behind a mandatory HITL/approval (RFC 0051) or rate-limit + per-session cap, over the RFC 0076/0079 SSRF-guarded, audience-bound egress path. Every anon tool call audits via the existing RFC 0049 authorization.decided event (no new event type). The always-on anonymous-actor-shape.test.ts verifies the advert shape + the §B.2 conditional + owner.principalKind + the audit reuse server-free; the five gated behavioral scenarios (anonymous-actor-default-deny, -no-secret-reach, -egress-guarded, -write-gated, -audit-opaque) drive the POST /v1/host/sample/anon-surface/dispatch + GET /v1/host/sample/anon-surface/tools seam and soft-skip until a host wires a tool-enabled public surface.

Graduated Active → Accepted 2026-07-22 on the openwop-app tier-1 reference witness. The five SECURITY invariants landed at reference-impl tier at Active and GRADUATED to protocol tier at Active → Accepted once openwop-app wired the surface and passed all five behavioral scenarios non-vacuously under OPENWOP_REQUIRE_BEHAVIOR=true (RFC 0079 egress-credential-audience-bound precedent). The host ships the surface gated behind OPENWOP_ANON_ACTOR_ENABLED (default OFF) — honest-off, not advertised on the live production discovery doc until an operator opts in.

Self-hosted runner (RFC 0122 — capabilities.selfHostedRunner)

The runner↔host channel defined in spec/v1/self-hosted-runner.md (RFC 0122, Accepted 2026-07-02; conformance 1.48.0). A host advertises selfHostedRunner { supported:true, dispatchKinds? } when it routes a run's per-step model/tool dispatch to a user-controlled runner that dials OUT (SSE receive + POST result, no inbound exposure) and holds local credentials the host cannot reach. The host stays the sole orchestration/persistence/replay authority; dispatch is per-step ({runId, stepId, seq, kind, provider?/model?/tool?, inputs}), results persist as normal step records (replay never re-dispatches), subject-first match rejects a cross-subject dispatch with a retriable runner_unavailable, and a redelivered {runId, stepId} is dropped at-most-once (deduped:true). The always-on self-hosted-runner.test.ts schema legs verify the frame/registration/capability shape server-free (the closed frames are the runner-credential-non-transit rail); the gated behavioral legs drive the POST /v1/host/sample/runner/{register,dispatch} seam (host-sample-test-seams.md §19) to assert subject-first runner_unavailable+retriable and at-most-once dedup non-vacuously. The runner_unavailable numeric HTTP status is host-chosen (any >= 400) — the witness asserts the envelope { error: { code, retriable:true } }, not a fixed status (mirrors run_forbidden / capability_required; registered in rest-endpoints.md §"Common error codes" per #815).

Graduated on dual-witness evidence vs suite 1.48.0 — per GOVERNANCE.md §"Acceptance evidence tiers" a tier-1 reference (openwop-app) + tier-2 (MyndHyve steward-affiliated sibling) graduation, not independent-organization dual-witness. Both invariants (runner-credential-non-transit, runner-output-untrusted-transport) are protocol-tier.

Data-parallel dispatch per-item input (RFC 0126 — capabilities.dispatch.perItemInput)

RFC 0126 graduated Active → Accepted on 2026-07-04 on a single-witness bootstrap steward waiver (0120/0121/0125 precedent); it is now dual-witness live (2026-07-05) — openwop-app (tier-1) + MyndHyve workflow-runtime (tier-2 steward-affiliated sibling), both advertising dispatch.perItemInput: true on live-deployed hosts, steward-curl-verified. The nextWorkerInputs[] array on NextWorkerDecision (orchestrator-decision.schema.json) lets a next-worker decision fan ONE childWorkflowId over N runtime items with distinct per-item inputs, projected over the RFC 0022 inputMapping (per-item wins on collision). A host advertises capabilities.dispatch.perItemInput: true (a prose descriptor in capabilities.md §dispatch, alongside the prose-only RFC 0118 dispatch.* family) when it honors per-index projection, the length-equality + fail-closed runtime validation_error gates, and the replay-freeze re-read of the recorded runOrchestrator.decided decision. The always-on dispatch-per-item-input.test.ts schema legs verify the nextWorkerInputs shape + the additionalProperties:false fail-closed rail server-free; the capability-gated behavioral legs (projection, merge-precedence, length-mismatch, replay-freeze, fail-closed) drive the POST /v1/host/sample/dispatch/per-item seam and soft-skip until a host wires it.

Portable per-run parameter deferral (RFC 0124 — capabilities.workflowChainPacks.deferredParameters)

RFC 0124 graduated Active → Accepted on 2026-07-04 on a single-witness bootstrap steward waiver (0120/0121/0125/0126 precedent; the dual-witness path is a tracked follow-up per gap G6 — MyndHyve workflow-runtime and the in-memory host both lack a chain-expansion / PromptTemplate-compose path). Deferred mode materializes a workflow-chain pack's parameters into top-level variables[] and rewrites {{params.}} into spec'd runtime bindings (PromptTemplate {{varName}} source:"variable", or a variable-sourced PortValue), keeping parameters overridable per run via configurable while the persisted definition holds ZERO {{params.}} tokens. A host advertises workflowChainPacks.deferredParameters.supported: true when it implements this AND the §Security handling for x-openwop-sensitive params (materialize source:"secret", prompt-body-only, fail-closed sensitive_param_not_deferrable 422 elsewhere, per-run supply = credentialRef not plaintext). The always-on workflow-chain-deferred-parameters.test.ts legs verify deferred expansion + the §Security fail-closed/no-plaintext MUSTs server-free against the reference expandChainDeferred; the capability-gated host legs drive the POST /v1/host/sample/chain/deferred-expand seam (override / :fork replay / untrusted-fence / [REDACTED] compose) and soft-skip until a host wires it.

Streaming & CDC trigger sources (RFC 0127 — triggerBridge.sources: "stream" | "change")

RFC 0127 graduated Active → Accepted on 2026-07-06 on a single-witness bootstrap steward waiver (tier-1 reference host). It additively extends the RFC 0083/0099 trigger source enum with stream (a Kafka/Kinesis/Pub-Sub broker message) and change (a warehouse/DB CDC row; op insert|update|delete REQUIRED in the ChangeEvent sub-object). Both reuse the RFC 0099 TriggerEvent envelope, SSRF posture, SR-1 content-free trigger.* events, and the RFC 0083 ≥24h dedup floor unchanged. A host advertises stream/change in triggerBridge.sources[] + ingestion.externalSources[] only when it operates a real broker/CDC consumer (RFC 0099 honesty rule). The always-on trigger-stream-cdc-sources.test.ts schema legs verify the envelope shape (op-required negative, exactly-one rule, vocabulary pins) server-free; the capability-gated behavioral legs drive the POST /v1/host/sample/trigger-bridge/{ingest,deliver} seams.

Purpose-propagation permitted-use labels (RFC 0128 — capabilities.purposePropagation)

RFC 0128 graduated Active → Accepted on 2026-07-06 on a single-witness bootstrap steward waiver + maintainer call. Gap G4 (a real onward label-carrying egress, steward-witnessed) — CLOSED 2026-07-06: tier-1 openwop-app built the openwop-app.cdp.sync-to-openwop-host reference workflow (prepare-onward node → the sanctioned core.openwop.http.fetch node → a steward capture bin) and fired the four onward legs local-on-origin/main; the steward independently read the bin and verified ⊆received / never-widen (marketing dropped on the real send) / []-drop with an unlabelled positive control. openwop-app is now the first host with a real onward label-carrying OpenWOP-envelope egress. An OPTIONAL permittedPurposes: string[] label (opaque purpose categories; absent = unlabelled, [] = no onward use) rides the A2A metadata.openwop.permittedPurposes extension + the top-level TriggerEvent.permittedPurposes field; a host advertising purposePropagation {supported, propagatesOnward} MUST re-emit the label on onward OpenWOP-envelope hops (MAY narrow, MUST NOT widen), a derived output MUST NOT carry a purpose absent from any contributing labelled input, and []-labelled data MUST NOT be forwarded onward. Non-OpenWOP destinations are a field-mapping SHOULD (untestable); internal use is §4 declared-intent (not gated). The always-on schema legs verify the label + family shape; the seam-gated purpose-propagation.test.ts behavioral legs drive the POST /v1/host/sample/purpose-propagation/forward two-hop seam.

Front-end plugin packs (RFC 0117 + 0119 — capabilities.uiPlugins)

RFC 0117 (+ 0119 isolation mechanism-neutrality) graduated Active → Accepted on 2026-07-06 on a single-witness bootstrap steward waiver + maintainer autonomy grant. A host advertising uiPlugins {supported:true, isolation} loads SIGNED, SANDBOXED kind:"frontend-plugin" packs in an origin/execution-isolated boundary and talks to them over the closed ui-plugin/1 host-RPC allowlist. Four protocol-tier SECURITY invariants: frontend-plugin-isolation / -egress / -rpc-allowlist / -no-byok. Witness ruling: isolation + egress are serve/apply-control MUSTs — the host MUST apply a sandboxed cross-origin iframe (no allow-same-origin) and serve the plugin under a deny-egress CSP; those controls are falsifiable by the steward on the wire + the reference host's FE unit tests, while the browser's runtime enforcement of correctly-applied controls is a platform guarantee (the §4-parallel unobservable-runtime split). rpc-allowlist + no-byok are wire-observable and steward-curl-verified.

Portable prompt-prefix cache (RFC 0116 — aiProviders.promptPrefixCache)

RFC 0116 graduated Active → Accepted on 2026-07-06 on a single-witness bootstrap steward waiver. A supporting host MAY route a stable, tenant-namespaced, secret-free cachePrefixId label to its provider's context cache; the outcome is cost-hint-only + replay-invariant (a hit/miss MUST NOT change the recorded envelope or inputTokens/outputTokens), witnessed by the cost-only provider.usage.cacheReadTokens/cacheWriteTokens. Protocol-tier invariant prompt-prefix-cache-cross-tenant-isolation mandates a (tenant, cachePrefixId) cache key.

A2UI surface deltas (RFC 0114 — a2uiSurface.deltaTransport)

RFC 0114 graduated Active → Accepted on 2026-07-06 on a single-witness bootstrap steward waiver. A host MAY deliver RFC 6902 (JSON-Patch) delta frames over the run event stream to subscribers that negotiate ?a2uiDelta=1; the RECORDED envelope stays the FULL ui.a2ui-surface (replay-pinned, unchanged) and the consumer re-validates the post-patch surface against the closed A2UI catalog fail-closed.

Connection-pack provider vendor grouping (RFC 0123 — provider.vendor)

RFC 0123 graduated Active → Accepted on 2026-07-06 on a single-witness bootstrap steward waiver — an OPTIONAL presentational vendor string on the RFC 0095 connection-pack provider object, so a host/registry groups pack-delivered connectors by commercial vendor. It gates no capability and carries no wire behavior, so the observable contract is the schema shape (accept string / accept-absent / reject non-string), witnessed by three conformance legs; the rendering MUSTs (SHOULD-group / MUST-fallback-to-displayName) are the 0128/0129 §4 unobservable-runtime class. Evidence UPGRADE 2026-07-07 (CARRIED-FORWARD → host-served real grouping): the flip was steward-only on the schema-shape witness, but a tier-1 host now serves pack-delivered vendor grouping on the wire — lifting the host row from "schema-shape witnessed" to "host-served real grouping witnessed." Tier-2 (a second host) is carried forward.

Agent-manifest role + the Skill profile (RFC 0131 — AgentManifest.role)

RFC 0131 graduated Draft → Accepted on 2026-07-07 via the bootstrap single-maintainer comment-window waiver (steward architect-reviewed). It adds an additive OPTIONAL AgentManifest.role ("skill" | "assistant") plus a schema-encoded Skill profile (if role==="skill" then {required:["handoff"], memoryShape.{conversation,longTerm} !== true}). Enforcement is universal JSON-Schema validation at publish/install — it introduces **no capabilities.* advertisement and no host runtime behavior — so, unlike a capability-gated surface, there is no per-host interop variance to track: every conformant validator rejects a stateful/handoff-less skill manifest identically, and an absent role (or role:"assistant") is unconstrained on every host. The witness is therefore the always-on, server-free** agent-manifest-role-profile.test.ts (validate skill/assistant/no-role; reject the stateful skill, the handoff-less skill, and a bad enum value) — no host-witness table applies. SECURITY invariant agent-skill-profile-stateless. Reference host: openwop-app ADR 0312 (Phase-0 marketplace "Skill" label; Phase-2 worker-memory normalization).

Conformance pass rates

Measured against @openwop/openwop-conformance@1.22.0 (the published suite has since advanced to 1.46.0 — 1.23.0 added the +5 RFC 0095 connection-pack scenarios, 1.24.0 the RFC 0096/0097/0098 scenarios, 1.25.0 the RFC 0099/0100 scenarios, 1.26.0 the RFC 0102 A2UI scenarios, 1.27.0 the RFC 0103 localized-content scenario, 1.28.0 the RFC 0104 approver-routing scenario, and 1.29.0–1.46.0 a further sequence of capability-gated scenarios (1.29.0 RFC 0105 speech-synthesis through 1.46.0 RFC 0120 connection-pack apiHosts egress allow-list); all are capability-gated and soft-skip on these reference hosts (which advertise none of those surfaces), so applicable rates are unchanged, and the table below re-measures on the next suite cycle) — all five hosts measured 2026-06-11, then re-measured the same day after the gap-closure fixes landed (openwop-examples#7 + openwop-app#164): the morning run's findings — the RFC 0093 §A3 webhook-tenant-isolation registration-gate gap on SQLite/Postgres/Python, the Python RFC 0058 runTimeoutMs gap, and the workflow-engine's 12 long-carried pre-existing failures — were all root-cause fixed and verified. Current posture: zero deterministic failures on the workflow-engine, Postgres, SQLite, and Python hosts; the in-memory host's 45 failures remain its documented honest-non-claim set (advertised-fixture surfaces the minimal host doesn't implement). Modes: in-memory/python/postgres default (Postgres via pglite), SQLite strict with honest profile/fixture opt-outs, workflow-engine in-process serial. Suite total 1963. Measurement basis: full 82-fixture catalog (fixture resolution now env-overridable + sibling-probing and loud on fallback — the silent degraded loading of pre-1.22.0 readings is fixed). Pass rate is passed/total.

Workflow-engine row re-measured 2026-06-21 at suite 1.29.0 (in-process, serial via --no-file-parallelism, full repo corpus via OPENWOP_CONFORMANCE_ROOT, OPENWOP_TEST_SEAM_ENABLED=true, memory://): 2059 / 0 / 89 / 2148, zero deterministic failures. The total rises 1963 → 2148 because the 1.23.0–1.29.0 scenarios now register (and the repo corpus carries the spec-corpus-validity prose/link/index cases the published package omits by design — so the repo-corpus total is the apples-to-apples basis the other reference rows are also measured on). The 89 skips are honest-non-claims: capability-gated families this host advertises none of (RFC 0104 approver-routing, RFC 0105 speech-synthesis, the unadvertised-profile families) soft-skip in default mode. The other four reference rows remain at the 1.22.0 basis pending their next re-measure cycle.

Composition partners — interop evidence

The conformance suite's MCP and A2A probes run against live reference implementations of the adjacent protocols. See A2A vs MCP vs OpenWOP for how the three layers compose.

Compensation and partial-failure profile (RFC 0151 + 0157 — capabilities.compensation)

The host-ordered, persisted, retried unwind of committed business effects (RFC 0151, Accepted 2026-08-12; spec/v1/compensation.md). A host populates the row when it advertises capabilities.compensation and the capability-gated witnesses execute non-vacuously — the base seams (compensation-behavior.test.ts: plan-before-effect, reverse-completion order, replay no-refire, content-free events, snapshot rollup ⇄ events) and the §21 recovery extension (compensation-recovery.test.ts: retry-stable identity, tenant-bound operator authority, recorded-facts replay).

Memory profile (RFC 0080 §C — capabilities.memory, openwop-memory)

The agent-memory surface (RFC 0080 §C memoryDegraded / attribution / injection budget; floor = memory-attribution-emits-on-write + the agentMemory* scenarios, two-sided since S35 at suite 1.136.1). A host populates the row when it advertises capabilities.memory.supported: true and the profile evaluates under --certify bundle v2.

Versioned composition profiles — A2A 1.0, MCP 2026-07-28, workload identity (RFCs 0152 / 0153 / 0154)

Witnessed with the suite's dual-era fake peer / fake server (OPENWOP_A2A_FAKE_PEER=true, OPENWOP_MCP_FAKE_SERVER=true) under OPENWOP_REQUIRE_BEHAVIOR=true, suite 1.120.0–1.122.0, on local memory:// boots of openwop-app (tier-1). Real upstream peers in CI remain externally gated (RFC 0152/0153 acceptance).

Deployed origin, 2026-08-16 (suite 1.133.0, https://app.openwop.dev/api, deploy 1b2dd6fbb = Cloud Run rev openwop-app-backend-00644-njl, /api/readiness stamped: true): the credential-free legs of the A2A 1.0 and MCP 2026-07-28 families now hold on the wire, not only on a boot — a2a-card-runtime-consistency 5/5 (14 asserts, including the S18 header-less-GET-is-0.3 rule), a2a-1-0-agent-card 10/10 (52; the suite's peer, but the host's own card resolution), a2a-version-negotiation (§A advert + interop error envelope; the host-as-client legs need a peer reachable from Cloud Run and stay local-only), mcp-version-negotiation (same shape), versioned-composition-profiles 11/11, contract-provenance 6/6, protocol-version-grammar 20/20, replay-side-effect-suppression (none, as withdrawn 2026-08-15). The authenticated halves — MCP server mount (mcp-2026-07-28-discover, mcp-stateless-request, MRTR server half), multi-party behavioural — answer 401 to the suite's credential-less run and are witnessed on the local boots above only; auth.workloadIdentity, orgChart and triggerBridge are env-gated OFF in production (inapplicable on the wire), and compensation is not yet advertised (ADR 0554 flip pending). So: RFC 0152 §C is a deployed-wire claim; RFC 0153 §B/§D/§E and RFC 0154 remain local-boot claims until an authenticated production run or the toggles flip.

Six RFC 0152/0153 invariants were registered on these witnesses (SECURITY/invariants.yaml, 2026-08-16): a2a-card-runtime-consistent, a2a-peer-no-authority-escalation, mcp-cache-tenant-scoped, mcp-extension-no-authority, mcp-peer-no-authority-escalation, mcp-header-body-consistent.

MyndHyve workflow-runtime — conformance evidence

Detailed evidence narrative for the MyndHyve row in the host table above (relocated from the table cell; newest measurement first). Per-bundle history is in the Update log.

Re-measured 2026-08-17 (M1–M6, bundle v2 #3, suite 1.135.1, deployed rev workflow-runtime-00528-vip, promoted 11:05Z; scoped 3h key on ws-openwop-conformance, revoked after the run; discovery sha256 ffde9549…60e26): the RFC 0149 UQ3 caveat is CLOSED — the live document now advertises protocolVersion: "1.0" (M1), the RFC 0155 canonical vocabulary (M3), root-first families with an identical capabilities mirror retained for external clients (M2), a2a { protocolVersions: ["0.3"], preferredVersion, profiles: ["a2a-0.3-legacy"] } (M6) and mcp { supported, protocolVersions: ["2024-11-05"], preferredVersion, serverUrls } — a version listed without its profile per mcp-integration.md §A (M5). Latest: bundle v2 #15 at suite 1.136.11 (2026-08-18, deployed revision workflow-runtime-00572-noc): executed-pass 304 / executed-fail 1 / skipped 0 / inapplicable 75 / blocked 89 across a 469-row ledger, all 14 profile lines certifiable (the 13 claimed + the openwop-core alias) — steward-re-derived from the published artifact (services/workflow-runtime/conformance/results/myndhyve-cloud-run-2026-08-18-bundle15-v2.json at ff0f8b7f4), not transcribed: all 36 floor rows sit in a certifiable disposition, 35 as executed-pass with a non-zero assertion count and one (prompt-list-and-fetch) as inapplicable with a stated reason, and the bundle contains zero zero-assertion passes. Discovery sha256 6ed605aa…45d4 — byte-identical to #13/#14, so the wire contract did not move. This is the first bundle in the programme measured against a reproducibly built image, which is what conformance-certification.md §"A bundle attributes to a BUILD" (gap G3) asks for: the Dockerfiles now npm ci under a pinned npm@11.6.2 (b9c1ddebc → ce44e7037 → 587c02bc7), so this revision's dependency closure is fixed by the lockfile and installed by the npm that wrote it. G3 exists because of this host — two builds of the identical commit 21db7e21d with byte-identical revision config scored 283/22 and 303/2, which falsified the corpus's own claim that v1 bundles are reproducible from a commit. The one failure, run-transport-economy (20 assertions, a wall-clock latency leg that passed in isolation against this same revision), is recorded as executed-fail and not re-run until green — a deliberate choice to publish what the run observed rather than the flattering score. Of four runs only the last is evidence, and both discarded modes are named on the record: attempt 1 (227/65) was discarded as invalid** because the API key expired ~6 minutes in — it would have read as a catastrophic regression caused by the build change shipped minutes earlier, a plausible story that was entirely wrong; attempt 2 (293/12) was cold-start latency on a scale-from-zero tag URL, made attributable by an isolation run rather than asserted.

Stated limitation, carried not solved: package-lock.json is still missing entries an npm < 11.5 expects, worked around by pinning the installer rather than regenerating the lock (declined for blast radius); the host's determinism guard asserts a pin exists and cannot assert it is the right one. Prior: #14 at suite 1.136.10 (2026-08-18, workflow-runtime-00566-vim): executed-pass 305 / executed-fail 0 / skipped 0 / inapplicable 75 / blocked 89, exit 0 — the same 13 claimed profiles certifiable, and memory-attribution-replay-stable now records assertionCount: 2, both halves of the recorded-fact rule. Under the pre-1.136.10 leg this host passed with its assertion loop running over zero events; it passes now because it re-emits, and the assertion count is what tells those two apart. Exactly one disposition moved from #13 — the new spec-section-citations records blocked in the published layout, where the package ships no spec/ by design (a missing dependency, RFC 0148 §A); it is in no profile floor, so no claim is affected. Prior: #13 at 1.136.7 (same revision; discovery sha256 6ed605aa…45d4; scoped key revoked after the run): executed-pass 305 / executed-fail 0 / skipped 0 / inapplicable 75 / blocked 88, exit 0 — and every one of the 13 claimed profiles is certifiable on its floor rows: discovery-core (+openwop-core alias) · core · interrupts · stream-sse · stream-poll · secrets · provider-policy · node-packs · replay-fork · fixtures · memory · trigger-bridge · core-standard · agent-platform. The BUNDLE still does not certify — blocked 88 are scenarios this host cannot witness (seams it does not mount, capabilities it does not advertise) — and the host records that rather than rounding it to "all green". Deltas from #12b, each with a real assertion count so none is a vacuous pass: eventOrdering 18 (host fix H1 — the terminal-status-before-terminal-event race, now stated in observability.md), pack-registry-publish 17 (suite S45), replay-observable-sequence-determinism 9 (host fix H2 — the replay fork re-emits the source's session-end memory events; on the RFC 0057 §D contradiction this host is on the re-emit side and therefore takes the assertion path), agentMemoryTtlExpiry 7 (suite S35), memory-attribution-emits-on-write 1, speech-synthesis-roundtrip 5 (a known external-TTS flake that passed this run, reported as a flake rather than as a fix). Both host fixes were verified on the wire before the suite was trusted — H1 by polling status to terminal then reading the log 3/3 runs, H2 by comparing source and fork sequences byte-for-byte. Prior: #12b at 1.136.3 (00564-lec) 299 / 5 / 89; #11 at 1.136.0 (00555-xih) 289 / 6 / 97, which added openwop-replay-fork. Bundle #3 detail follows. Emitter, unrounded: executed-pass 267 / executed-fail 23 / skipped 0 / inapplicable 76 / blocked 101 (exit 3 — blocked > 0 does not certify the BUNDLE); per profile: openwop-discovery-core ✓ (+openwop-core alias) · interrupts ✓ · stream-sse ✓ · stream-poll ✓ · secrets ✓ · provider-policy ✓ · fixtures ✓ · trigger-bridge ✓ · openwop-core-standard ✓ certifiable (all nine floor rows pass: auth 4, discovery 110, eventOrdering 14, failure-path 6, idempotency-key-determinism 1, idempotency 6, runs-lifecycle 7, webhook-negative 8, any.interrupt- 27) · openwop-node-packs not held (runtime-derived) · openwop-replay-fork NOT certifiable (replay-side-effect-suppression blocked — no sideEffectSuppression advertised; replayDeterminism executed-FAIL) · openwop-memory NOT (memory-attribution-emits-on-write blocked) · openwop-agent-platform NOT (inherits). Two of the four host fixes it took were the corpus's fault and are fixed at 1.135.1 (capabilities.mcp.serverUrls was scenario-required and schema-forbidden; webhook-negative read the wrapper only); the others were host defects (conformance-failure stripped from fixtures[] at boot; canonical POST/DELETE /v1/webhooks accepted user tokens only). The 23 executed-fail scenarios are the host's own follow-up queue, listed in the run record, and are NOT rounded here. This is the first tier-2 host to certify openwop-core-standard on a deployed origin under bundle v2.**

Update log

Per-bundle and per-deploy conformance history for the rows above (newest first). Release-level changes are recorded in CHANGELOG.md.

• 2026-08-19 (MyndHyve bundle v2 #15 at suite 1.136.11 on workflow-runtime-00572-noc: 304 / 1 / 0 / 75 / 89 over a 469-row ledger, all 14 profile lines certifiable, zero zero-assertion passes — the first bundle in the programme measured against a reproducibly built image, which is what conformance-certification.md gap G3 asks for; the one executed-fail (run-transport-economy, a wall-clock leg) is published as failed rather than re-run until green, and the host's #224 replay-fan-out fix ships on this revision — deployed but not suite-witnessed, because the rule still has no conformance scenario).
• 2026-08-18 (openwop-app deploy #7 — 4c10c3a8eb42, both halves verified: first deployed-wire implementation of replay.md §"Host-initiated fan-out is an external effect" (H72 — production had been delivering webhooks asserting work a replay fork never performed); sideEffectSuppression stays none, withheld with a stated reason rather than as a gap; pin still 1.136.3).
• 2026-08-18 (openwop-app deploy #6 — d0b6b588acd8, Cloud Run rev openwop-app-backend-00651-mdh: 11 profiles certified in the host operator's bundle v2 (468 requirement rows, evidence 38d3ff4430cd, digest matched), contractProvenance.suiteVersion 1.136.3 — the pin is the host's installed package and is recorded as measured, not rounded up to the current 1.136.10, so this deploy's bundle contains neither the strengthened replay leg nor the citations gate).
• 2026-08-18 (MyndHyve bundle v2 #14 at 1.136.10 on workflow-runtime-00566-vim: executed-fail 0 holds and memory-attribution-replay-stable is witnessed non-vacuously at assertionCount: 2 — both halves of the recorded-fact re-emission rule; one disposition moved, the new corpus-self-check spec-section-citations, blocked in the published layout by construction and in no profile floor).
• 2026-08-18 (MyndHyve bundle v2 #13 at 1.136.7 on workflow-runtime-00566-vim: executed-fail 0 — 305 pass / 0 fail / 0 skipped / 75 inapplicable / 88 blocked, and every claimed profile certifiable (13 claimed, 14 lines with the openwop-core alias) including openwop-core-standard, openwop-node-packs, openwop-memory, openwop-agent-platform and openwop-replay-fork; the bundle itself does not certify because blocked > 0, which the host reports rather than rounds).
• 2026-08-18 (MyndHyve bundle v2 #12b at 1.136.3 on 00564-lec: openwop-memory + openwop-agent-platform certifiable — 12 profiles; core-standard held by one host race, fix pending deploy; pack-registry-publish red was suite S45).
• 2026-08-18 (openwop-app deploy #5 83c1385ca rev openwop-app-backend-00650-8rz: capabilities.memory.supported: true on the wire (RFC 0080 §C, host H51) and openwop-memory certified in the host operator's authenticated bundle-v2 certify lane — the first host to certify that profile on a deployed origin (postgres reference certified it locally at 1.130.0); ADR 0553 P3 (H53) + ADR 0554 P3 operator recovery (H50) shipped; steward credential-less strict re-drive at suite 1.136.4 86/86 across the nine credential-free files).
• 2026-08-17 (MyndHyve bundle v2 #11 at 1.136.0 on 00555-xih: openwop-replay-fork certifiable — 11 profiles; three suite defects it surfaced fixed at 1.136.3).
• 2026-08-17 (openwop-app deploy #3 3318d7062 rev 00648-pwz: H43 auth-boundary ✓ on the wire, contractProvenance.suiteVersion 1.135.2 first honest value, flat error envelope everywhere).
• 2026-08-17 (RFC 0153 §B/§D DEPLOYED-WIRE on app.openwop.dev 756a9938d — host operator's authenticated pass; mcp-current-auth-boundary red there = host defect H43 caught on the wire).
• 2026-08-17 later (openwop-app deploy #2 756a9938d: RFC 0151 compensation advert + §B/§D/ordering/replay-no-refire DEPLOYED-WIRE, §C/§E/§F local-boot — compensation.md G9).
• 2026-08-17 (MyndHyve tier-2 row re-measured as bundle v2 #3 at suite 1.135.1 on the deployed origin — openwop-core-standard certifiable, RFC 0149 UQ3 caveat closed; the same host surfaced three suite defects fixed at 1.135.1–1.135.3).
• 2026-08-16 (the four reference-host rows re-measured as bundle v2 against suite 1.130.0, openwop-examples#15 — zero zero-assertion passes on every host; earlier the same day the RFC 0147 criterion 11 sweep re-measured them at 1.116.0 and canonicalised profile names per RFC 0155 §A; MyndHyve row caveated per RFC 0149 UQ3).

Reading Rows

• Compatibility profile claim is derived from /.well-known/openwop according to spec/v1/profiles.md.
• Scale claim follows spec/v1/scale-profiles.md.
• Production profile claim follows spec/v1/production-profile.md and is recorded separately because durability, retention, backpressure, and observability are operational evidence, not discovery-payload predicates.
• Conformance evidence should name the suite version, command used, target URL class, and pass/fail/skip counts. Do not include private deployment identifiers, secrets, or internal result paths.

Add A Host

1. Implement the openwop v1 wire contract. 2. Run @openwop/openwop-conformance against the host. 3. Publish a result file or Markdown summary in a public repository. 4. Add a row above with compatibility, scale, production-profile, and evidence claims.

See Also

• conformance/README.md — how to run the suite.
• spec/v1/profiles.md — compatibility profile predicates.
• spec/v1/scale-profiles.md — scale tier definitions.
• spec/v1/production-profile.md — public-release operational profile.