Status: Living document. Updated as milestones land.
Last reviewed: 2026-06-14 (corpus release v1.1.8 cut — the 2026-06 monorepo split + the RFC 0089–0100 graduation cycle; conformance advanced
1.18.1 → 1.25.0, published independently on its ownopenwop-conformance/v*tags). The generated protocol snapshot lives atdocs/PROTOCOL-STATUS.md. RFC status: Accepted 96 / Active 3 (0035, 0043, 0100) / Draft 1 — seedocs/PROTOCOL-STATUS.mdfor the authoritative counts. SECURITY surface now at 125 invariants (99 protocol-tier, 24 reference-impl, 2 advisory) againstSECURITY/invariants.yaml; the per-RFC addition history lives in the README status banner +CHANGELOG.md.
This roadmap distinguishes stable v1 (locked contract), v1.X minor work (additive, conformance-only), and post-v1 ecosystem (extension profiles, infrastructure, governance).
The v1 protocol contract is frozen. Implementations validate themselves against @openwop/openwop-conformance 1.0 (or any later 1.X.0) at their own cadence. New scenarios ship as suite minors against the unchanged contract.
Stable: v1 (released 2026-04-27)
Released and locked:
- 32 prose specs under
spec/v1/at the v1.0 release — the corpus has since grown additively to 52 (seedocs/PROTOCOL-STATUS.mdfor the live tally) - 24 first-class JSON Schemas at release (now 63; all compile clean under Ajv2020)
- OpenAPI 3.1 + AsyncAPI 3.1
- 3 reference SDKs (now in
openwop/openwop-sdks):@openwop/openwop(TS),openwop-client(Python),github.com/openwop/openwop-sdks/go(Go) @openwop/openwop-conformance1.0 with server-free and server-required scenario groups (the suite has since shipped minors through1.20.0)
See CHANGELOG.md for the release record.
v1.X minor: conformance suite expansion
These ship as @openwop/openwop-conformance minor releases (1.X.0) against the unchanged v1 protocol. They do not modify the wire contract. Each line is a tracked trigger; status reflects the most recent suite release.
| Trigger | Closes | Status |
|---|---|---|
| SSE buffering scenarios | S3 | Included in the v1.0 conformance baseline |
| Mixed-mode SSE scenarios | S4 | Included in the v1.0 conformance baseline |
| Sub-workflow node module fixture | F2 | Included in the v1.0 conformance baseline (subworkflow.test.ts exercises core.subWorkflow parent/child round-trip) |
| Recursion-limit enforcement scenarios | F4 + CC-1 | Included in the v1.0 conformance baseline (cap-breach.test.ts asserts cap.breached precedes run.failed; RunOptions.configurable.recursionLimit is the per-run override) |
| Channel TTL reducer fold scenarios | C3 | Included in the v1.0 conformance baseline (channel-ttl.test.ts exercises post-TTL writes evicting prior entries) |
| AI cost attribution scenarios | O4 | Included in the v1.0 conformance baseline (e2e content scenario via conformance.cost.emit fixture node + openwop-smoke-cost-emit fixture workflow; gated on OPENWOP_CONFORMANCE_FIXTURES=1) |
v1.X minor: protocol gap closure queue
These are additive profiles, conformance expansions, or clarifying annexes that close the remaining gaps identified in the 2026-05-10 deep-dive review. They MUST NOT break v1 wire compatibility.
Phases H + I close-out (2026-05-12 — myndhyve.ai launch-readiness)
The 2026-05-12 architect review framed the remaining gap-closure work as myndhyve.ai launch-readiness on the Postgres reference host. Two phased batches landed:
- Phase H — launch-blockers (9/9 closed): BYOK /
aiProviderswith 4-mode policy enforcement (disabled/optional/required/restricted) +core.llm.chat+core.llm.completion; MCP client (core.mcp.toolCallover HTTP/JSON-RPC,trustBoundary: "untrusted"perthreat-model-prompt-injection.md§UNTRUSTED); HTTP client (core.http.requestwith SSRF guard + 1 MiB response cap); cap-breach + configurable-schema enforcement; SECURITY invariantsmcp-toolcall-payload-redaction+http-client-ssrf-guard; SDK wire-type + error-code catalog additions (TS/Python/Go). - Phase I — enterprise-blockers (11/11 closed): MemoryAdapter (RFC 0004) read-side
list+getwith CTI-1 cross-tenant isolation + TTL enforcement;capabilities.agentsadvertisement (Phase 1–6) + reasoning verbosity governance helpers; API-key rotation (two-key overlap + canary-redaction; conditional advertisement); auth-scoped discovery (tenant2 narrowed view, strict subset); OAuth2-CC + OIDC user-bearer JWT validators (RS256 + ES256 vianode:crypto; JWKS fetch + 10-minute cache with re-fetch onkidmiss;alg: "none"rejected; canary-redaction; 10-path smoke); mTLS termination; reasoning-event emission; subworkflow outputMapping + parent linkage (G3); protocol-tier SECURITY invariants for agent memory, auth rotation, MCP redaction, HTTP SSRF, and memory compaction. Pack-registry consumption landed 2026-05-15 viaexamples/hosts/postgres/src/pack-consumer.ts— canonical SRI + Ed25519 + version-drift + lockfile-schema validation with typed fail-closed errors; 9-path host smoke againstcore.openwop.examples@1.0.0— closing the 11th line and the Phase I batch as a whole.
Postgres host conformance pass rate: 2068/2161 (95.7%), 0 deterministic failures — re-measured 2026-06-01 against suite 1.18.1 with conditional profiles advertised. (The earlier 781/850 = 91.9% figure was the suite-v1.1.0 reading at the Phase-H/I close-out, before the v1.1→v1.18.1 suite growth.) See INTEROP-MATRIX.md for the current per-host table.
| Track | Gap closed | Deliverable |
|---|---|---|
| Capability handshake hardening | Capabilities-Etag, non-HTTP negotiation, per-tenant capability views | Spec annex shipped in capabilities-change-detection.md; discovery.test.ts covers optional Capabilities-Etag. Auth-scoped discovery (RFC 0011 §A "Scoped capability views") verified end-to-end on the Postgres host (2026-05-12 Phase I.5) — OPENWOP_TENANT2_API_KEY activates a narrowed view (orchestrator + dispatch omitted, strict subset per the spec annex line 69) alongside the existing SQLite host implementation. |
| Auth profile | OAuth2 client credentials, API-key rotation/grace period, OIDC user-bearer, optional mTLS | Spec annex shipped in auth-profiles.md. API-key rotation verified end-to-end on the Postgres host (2026-05-12 Phase I.6). OAuth2-CC + OIDC user-bearer verified end-to-end on the Postgres host (2026-05-12 Phase I.3 + I.4) via examples/hosts/postgres/src/jwt-validator.ts — JWKS fetch + RS256/ES256 verification with node:crypto, 10-minute cache with re-fetch on kid miss, explicit alg: "none" rejection, canary-redaction in 401 envelope; 10-path smoke (test/oauth2-oidc.test.ts) covers positive + 6 negative + canary paths. Conditional advertisement when issuer/audience env vars are set. mTLS is verified end-to-end on Postgres when OPENWOP_MTLS_CERT_PATH + OPENWOP_MTLS_KEY_PATH are configured. |
| Interrupt profile | Multi-approver quorum, parent/child cancellation, external-event matching, auth-required | Spec annex shipped in interrupt-profiles.md; four fixtures shipped 2026-05-10 (conformance-interrupt-{quorum,external-event,auth-required,parent-child-cancel}.json) + matching conformance scenarios (interrupt-{quorum-resolution,external-event-correlation,auth-required-resume,parent-child-cascade}.test.ts). Track closed. |
| Replay profile | Fork from arbitrary event types, retention/GC, PII replay policy, determinism scoring | Retention, privacy, and scoring semantics added to replay.md; arbitrary-event fork shipped (replay-fork-arbitrary.test.ts) + deterministic replay shipped (replayDeterminism.test.ts) + retention-expiry shipped (replay-retention-expiry.test.ts) — graded B in coverage.md:63 (capability-shape always; 410/422 envelope assertions gated on OPENWOP_TEST_EXPIRED_REPLAY_RUN_ID). Remaining work is host-side: RFC 0009 Q#1 (force-expire endpoint normation) gates the path from B to A. The new LLM cache-key recipe scenario (replay-llm-cache-key.test.ts, replay.md §"LLM cache-key recipe" §B) also shipped in @openwop/openwop-conformance@1.3.0. |
| MCP/A2A roundtrip | Integration docs are strong but roundtrip proof is thin | mcp-tool-roundtrip.test.ts + a2a-task-roundtrip.test.ts shipped with synthetic peer fixtures; real-impl interop env vars (OPENWOP_MCP_REAL_SERVER_URL, OPENWOP_A2A_REAL_PEER_URL) wired 2026-05-11. Cross-impl evidence published — INTEROP-MATRIX.md now carries a "Composition partners — interop evidence" subsection (MCP @modelcontextprotocol/sdk all-transports + A2A @a2a-js/sdk reference peer, both passing). Track closed. |
| Endpoint coverage manifest | Ensure every OpenAPI operation has positive + negative conformance evidence | Manual map shipped in conformance/coverage.md; route-coverage.test.ts adds direct workflow/artifact/webhook probes; spec-corpus-validity.test.ts now verifies every OpenAPI operationId appears in the map. |
| Production profile | Queueing/backpressure, retry durability, event retention, high-volume debug bundle behavior | Spec annex shipped in production-profile.md; INTEROP-MATRIX.md records production-profile claims separately. 7 production-profile scenarios shipped (production-backpressure, production-retention-expiry, restart-during-run, staleClaim, debug-bundle-truncation, idempotency, idempotencyRetry); Postgres reference host advertises capabilities.production.supported: true since 2026-05-11 and passes all 11 assertions across the 5 non-opt-in scenarios per coverage.md:58. Track is substantively closed at B+; path to A gated on RFC 0009 Q#1 + Q#3. |
Hosts publish which suite version they pass; non-pass on a later suite is not a v1 conformance regression.
RFC 0099 + 0100 — Active, corpus implementation landed (2026-06-14)
RFC 0099 (external-event trigger ingestion, extends RFC 0083) and RFC 0100 (async/durable A2A tasks, extends a2a-integration.md) were promoted Draft → Active (#700). Both are additive + capability-gated. Their normative corpus artifacts are now landed — the capability-honesty gap (host advertisement outrunning conformance coverage) is closed:
| RFC | Normative artifacts (✅ landed) |
|---|---|
| 0099 | ✅ schemas/trigger-event.schema.json + schemas/trigger-subscription-registration.schema.json; capabilities.schema.json triggerBridge.ingestion sub-block; spec/v1/trigger-bridge.md §F; api/openapi.yaml POST /v1/trigger-subscriptions; SECURITY invariants trigger-ingestion-ssrf + trigger-ingestion-content-redaction + public conformance tests (trigger-ingestion.test.ts); profiles.md + profiles.ts predicate widening. |
| 0100 | ✅ schemas/a2a-task-state.schema.json; capabilities.schema.json a2a block; spec/v1/a2a-integration.md §"Async / durable Tasks"; api/openapi.yaml durable-task read seam; SECURITY invariant a2a-push-egress-ssrf + async subtests in a2a-task-roundtrip.test.ts. |
The openwop-app reference host already wires both (its ADR 0034 / 0035), so it advertised triggerBridge.ingestion / a2a.durableTasks ahead of corpus conformance — these landings close that gap. Each RFC's MUST-NOTs (0099: SSRF + content-redaction; 0100: trust-boundary / push-egress SSRF) now carry a public conformance test. Remaining work for Active → Accepted: the reference-host durable-delivery / durable-Task behavioral evidence (the gated legs soft-skip until a host wires the /v1/host/sample/{trigger-bridge,a2a}/* seams).
v1.2 outlook (projected)
A projection of what would land in a v1.2 minor — each item carries a gate condition that determines whether it ships. The list is descriptive, not a commitment: surfaces only ship when their gate condition is met. Items can move to "Withdrawn" if no implementer adoption signal arrives within the RFC comment window.
| Candidate | Gate | Status |
|---|---|---|
| RFC 0012 — Memory compaction profile | Accepted 2026-05-15 after the bootstrap-phase waiver; Postgres advertises and verifies §A advertisement + §B memory.compacted event + §D SR-1 carry-forward when memory compaction is enabled | Accepted. Keep monitoring implementation uptake outside the Postgres reference host and add cross-host provenance evidence when a second host advertises the profile. |
| WASM Component Model sub-RFC | First adopter requests runtime.language: "wasm-component" packs; manifest enum already reserved in node-pack-manifest.schema.json; capability already declared in capabilities.schema.json nodePackRuntimes.wasmComponent | Reserved. The hand-rolled imports/exports of RFC 0008 §C get replaced by WIT-defined interfaces. Loader implementation gated on Wasmtime ≥ 14 (Component Model GA). |
| Rust SDK v0.1 | Concrete adopter asks for it OR a non-steward host implementation lands in Rust | Demand-gated. The conformance suite is language-agnostic, so a Rust client tests against the same wire contract; the question is whether anyone is writing one. No flip without adopter pull. |
**4 audit-gated core.openwop.* packs** | External security audit completes per SECURITY/external-audit-engagement.md; the community-openwop-team-demo-1-style namespace-scoped per-tier key for the steward team is operational | Built + signed at registry/v1/packs/core.openwop.{ai,http,mcp,triggers}/-/1.0.0.{tgz,sig,sbom.json,json} in openwop/openwop-registry (the pack registry's home since the 2026-06 split). Publication to packs.openwop.dev is the only blocked step. Audit outreach drafts ready at SECURITY/outreach/external-audit/ for Trail of Bits / NCC Group / Doyensec / Cure53 / Latacora. |
| Cross-host SSE replay verification | core.subWorkflow advertised + capability-gated trace-propagation scenario added | Closed 2026-05-13. Shipped as otel-trace-propagation-subworkflow.test.ts (Track 11 close-out) — asserts parent + child runs share the inbound traceparent's traceId across the core.subWorkflow dispatch boundary. conformance/coverage.md:56 records it as A-grade with full scope. Now consumer-installable via @openwop/openwop-conformance@1.3.0 (published 2026-05-19) — downstream hosts pick up the assertion on their next suite-version pin. |
| mTLS certificate-matrix hardening | Operators need documented CA/server/client-cert recipes and optional reverse-proxy deployment guidance beyond the Postgres direct-listener smoke | Postgres now verifies openwop-auth-mtls end-to-end when configured. Remaining work is operator documentation and broader certificate-matrix coverage. |
| Multi-region idempotency end-to-end fixture | Host advertises capabilities.idempotency.crossRegion: "best-effort" (or "strict") | Spec is in idempotency.md §"Multi-region idempotency (annex)"; existing scenario multi-region-idempotency.test.ts covers capability-shape only. ~half-day to add behavior assertion against the documented MUSTs. |
v1.2 ships when 1-2 of these mature; the rest move to the next minor or to Withdrawn. No fixed calendar.
Post-v1 ecosystem
These are larger initiatives that expand the openwop ecosystem without modifying the v1 contract.
Optional capability profiles
Capability profiles are clusters of optional behaviors a host can advertise via /.well-known/openwop. They are documented as separate spec annexes. Each profile has its own conformance scenarios shipped as part of @openwop/openwop-conformance and run only when the profile is advertised.
| Profile | Status | Notes |
|---|---|---|
| BYOK / secret resolution | Spec landed (run-options.md §"Credential references"); conformance coverage includes capability-shape, redaction, adversarial redaction, and positive-path resolve roundtrip via conformance.secret.echo fixture node | Optional. Hosts that don't advertise capabilities.secrets.supported = true skip these scenarios. |
| Replay / fork | Spec landed (replay.md); conformance shipped — replay-fork.test.ts + replayDeterminism.test.ts cover replay-cache hit / divergence-event / receipt-required, and fork-from-arbitrary-event-types shipped as replay-fork-arbitrary.test.ts (with retention-expiry in replay-retention-expiry.test.ts) — see the "Replay profile" track above | Optional. |
| Channel TTL | Spec landed (channels-and-reducers.md); included in the v1.0 conformance baseline (channel-ttl.test.ts) | Optional. |
| Cost attribution | Spec landed (observability.md §"AI cost"); included in the v1.0 conformance baseline (e2e via conformance.cost.emit fixture node) | Optional. |
| Memory compaction | Accepted — RFC 0012 (RFCS/0012-memory-compaction-profile.md, accepted 2026-05-15). Defines optional capabilities.memory.compaction advertisement, memory.compacted event, and the SR-1 carry-forward invariant that extends RFC 0004 §D through host-side memory distillation. Postgres implements the profile when OPENWOP_MEMORY_COMPACTION=true; conformance scenarios cover event emission, SR-1 carry-forward, and provenance tag shape. | Optional. Drives no v1 contract change; implementation remains host-advertised. |
Hosted infrastructure
| Item | Status | Notes |
|---|---|---|
Hosted node-pack registry (packs.openwop.dev) | Live | Discovery + index + per-pack manifest + tarball endpoints serve from packs.openwop.dev per registry-operations.md. 62 packs published as of 2026-05-21 across four trust tiers: 22 core.openwop. (framework primitives), 1 community.openwop-team. (community demo), 1 vendor.openwop. (rust-hello WASM reference), 38 vendor.myndhyve. (canvas-vertical reference packs). Categorized inventory: docs/PACK-CATALOG.md. Reference compositions: examples/market-intel-pipeline/ (9 packs) + examples/ads-publish-pipeline/ (8 packs × 3 platform variants). Stage 1–4 (operational maturity) shipped 2026-05-12: WIF auto-deploy, CycloneDX SBOMs, registry CVE feed + OSV scanning, Cloud Monitoring uptime check. Write API and lifecycle ops (yank / deprecate / key rotation) ship via pull-request publishing on GitHub. Public healthcheck: conformance/src/scenarios/registry-public.test.ts. |
Hosted docs + conformance leaderboard site (openwop.dev) | Live | Published at openwop.dev, built + deployed from the separate openwop/openwop-site repo (renders this corpus at a pinned commit; tracks main via a daily pin-bump). Rendered spec docs, conformance leaderboard, profiles, sitemap, OG assets, and per-host badges all serve live. |
| Public CI for community contributions | In source tree | Workflows exist in .github/workflows/; remaining work is public runner validation after repository publication. |
SDK expansion
Additional SDKs ship only when there is concrete demand. The current set (TS, Python, Go) covers the most common host implementation languages. Candidates if requested: Rust, Java/Kotlin, Ruby, .NET.
Implementation ecosystem
| Item | Status | Notes |
|---|---|---|
| Production-host conformance certification | In progress | Four reference hosts in the openwop/openwop-examples repo under examples/hosts/ (in-memory, SQLite, Postgres, Python) demonstrate the protocol cross-implements; the Postgres host satisfies the production-profile predicate. RFC 0089 (conformance certification bundle) is Accepted — a machine-readable per-profile evidence bundle is committed at examples/hosts/in-memory/certification-bundle.json in that repo. Public conformance evidence is tracked in INTEROP-MATRIX.md. |
| Second independent host implementation (non-steward maintainer) | Not started | Needed to graduate to working-group governance per GOVERNANCE.md. MyndHyve — a steward-affiliated sibling host (separate deployment, same maintainer org; tier-2 evidence per GOVERNANCE.md §"Acceptance evidence tiers") — advertises capabilities and passes conformance, and drove the RFC 0078–0092 Active → Accepted graduations; but the governance tripwire requires a maintainer from a genuinely independent organization, which has not yet happened. |
| Third-party node-pack catalog | Not started | Depends on hosted registry. |
Canonical Domain
Forward-looking domain references in the spec corpus and roadmap use openwop.dev.
Three rules for domain usage:
1. All forward-looking public URLs (packs.openwop.dev, openwop.dev/openwop-conformance, etc.) use openwop.dev. 2. Published package names stay verbatim (@openwop/openwop on npm, openwop-client on PyPI) and are guaranteed stable through any v1.x release per PUBLISHING.md. The 2026-06 repo split moved the SDK _source_ to openwop/openwop-sdks; the npm/PyPI identifiers are unchanged, but the Go module path changed from github.com/openwop/openwop/sdk/go to github.com/openwop/openwop-sdks/go (a module is identified by its path, so this is a forced re-import for Go consumers — documented in the openwop-sdks README migration note rather than minimized). 3. Internal references in steward-private docs are not normative and may use any name; this convention applies only to the public spec corpus, this ROADMAP, and the conformance suite.
Vendor-neutral org migration
The repository is currently at github.com/openwop/openwop. Migration to a vendor-neutral org (target name: openwop-spec/openwop) is planned but not on a calendar schedule. The migration has a single tripwire:
Migration to
openwop-spec/openwopis initiated whenMAINTAINERS.mdlists at least one maintainer not affiliated with the original steward (OpenWOP).
When the tripwire fires, the migration plan is:
1. Open an RFC per RFCS/0001-rfc-process.md proposing the new org name and the mechanics (redirect, DNS, package owner transfer, CHANGELOG entry). 2. Ratify by maintainer lazy consensus (per GOVERNANCE.md). 3. Move the repository; configure github.com/openwop/openwop as a permanent redirect. 4. Transfer ownership of npm scopes and PyPI/Go module names; old names continue resolving via metadata redirects where the package registry supports it. 5. Update all in-spec links to the new canonical URL in the next minor release.
Until the tripwire fires, the canonical URL remains github.com/openwop/openwop. External implementers can rely on this URL through any v1.x release; migration will be announced via CHANGELOG, README banner, and direct outreach to known third-party implementers (per MAINTAINERS.md if the maintainer set has expanded).
Recruiting external maintainers is out of band. MAINTAINERS.md documents the criteria and process; this roadmap does not commit to a recruitment timeline.
Research & publications
- OpenWOP: A Vendor-Neutral Protocol for Durable, Portable Agentic Workflow Orchestration — published on Zenodo, DOI 10.5281/zenodo.20576239 (CC BY 4.0). A protocol-level position paper with a reproducible cross-language portability result: the same workflow definition yields identical terminal state and
RunEventtype-sequence across an independent TypeScript and a Python reference host. Source and the full evidence artifact live inopenwop/openwop-paper. The paper is steward-authored and states so explicitly; independent external review and a non-steward host remain the decisive validation steps, tracked as the tripwires above.
What this roadmap does not commit to
- A specific date for v1 or v2.0.
- Any breaking change to the v1 wire contract.
- Adoption by any specific vendor or platform.
- Hosting infrastructure on any specific cloud. Forward-looking spec/registry/leaderboard URLs use
openwop.dev; the deployment substrate (cloud provider, runtime) is similarly undecided. - Migration of the repository to a different organization on a specific timeline (planned but not scheduled — gated on the tripwire described above and in
MAINTAINERS.md).
How to influence the roadmap
- File an issue with the
roadmaplabel. Include the use case, not just the feature request. - Open a conformance report if your implementation needs a scenario that doesn't exist yet.
- Author an RFC for a new capability profile. Profile RFCs follow the spec change process in
GOVERNANCE.md.