OpenWOP openwop.dev

For production evaluators

For production evaluators.

You're deciding whether OpenWOP fits your durability, security, interop, and operational requirements before you bet a production system on it. This page is the honest summary of what the protocol guarantees, what the reference hosts demonstrate, and what's explicitly out of scope.

Read the production profileAudit the leaderboard

The shortest honest pitch

OpenWOP is an open wire-level protocol for multi-agent workflow orchestration.

  1. Versionv2 is the current major, cut 2026-09-05.
  2. EvolutionAdditive-only within a major.
  3. EvidenceThe public conformance leaderboard lists every host that has published results. All of them are run by the steward or a steward-affiliated organization.
  4. LicenseThe specification, schemas and API definitions are CC BY 4.0; the SDKs, conformance harness, CLI and tooling are Apache 2.0, with no field-of-use restrictions.

Read these first

What the protocol guarantees

Additive-only evolution within a major
RFC review window; automated checks on every change
Safety-fix disclosure window
90-day public window OR embargoed advisory per disclosure policy
Cross-host portability
Black-box scenario suite runs against every claimed host
BYOK secret non-leakage
Public conformance test on every protocol-tier host
Cross-tenant memory isolation
Public test; mechanically verified on the Postgres reference host
Replay determinism
Fork-from-checkpoint scenarios in the conformance suite
Signed webhook delivery
HMAC-SHA256({ts}.{body}); replay-attack-resistant verification recipe

Questions worth raising in your eval

These are the questions a careful evaluator should ask. They're easier to answer up front than after the contract is signed.

  1. 1Which OpenWOP host will we run? Are we self-hosting, paying a vendor, or both?
  2. 2Which profiles does that host claim, and does the leaderboard back the claim?
  3. 3What's our migration path if the host vendor stops supporting OpenWOP?
  4. 4How do we get notified about safety-fix advisories? (Answer: GitHub releases on openwop/openwop.)
  5. 5What's our policy for adopting a new major version when one ships?

What's explicitly out of scope

  1. Runtime SLAOpenWOP defines the protocol, not the host's uptime. Your host vendor (or your own host) owns that.
  2. Throughput claimsThe production capability is operational-readiness (backpressure, retention, claim acquisition) — NOT a throughput floor. A single-pg.Client Postgres host can satisfy it while serializing writes.
  3. A managed service from the OpenWOP projectThe protocol is open; the reference hosts are reference implementations. There is no hosted, paid offering from the steward at this time. See Roadmap.
  4. Lock-in protection across major versionsEach major is additive within itself; breaking changes land only at a major boundary. Support past a major is a commitment your vendor would need to make.

The full guide

Everything on this page, in order, with every link.

The shortest honest pitch

OpenWOP is an open wire-level protocol for multi-agent workflow orchestration.

  • Version: v2 is the current major, cut 2026-09-05.
  • Evolution: additive-only within a major.
  • Evidence: the public conformance leaderboard lists every host that has published results. All of them are run by the steward or a steward-affiliated organization.
  • License: the specification, schemas and API definitions are CC BY 4.0; the SDKs, conformance harness, CLI and tooling are Apache 2.0, with no field-of-use restrictions.

If your evaluation criteria are "is this real, is it stable, can my team take it over if the steward disappears, and is it defensible against an audit" — this page is for you.

Read these first

  • Production profile — the canonical predicate set for hosts that claim production posture. Operational-readiness, NOT throughput.
  • Positioning & non-goals — what OpenWOP is and explicitly isn't.
  • Versioning & compatibility — the versioning axes and the rules they enforce.
  • Security posture — threat model, disclosure policy, public invariants.
  • Governance — how decisions get made, the sole-steward operating rules, the path to a cross-vendor working group.

What the protocol guarantees

GuaranteeSourceHow it's verified
Additive-only evolution within a majorCOMPATIBILITY.md §2RFC review window; automated checks on every change
Safety-fix disclosure windowCOMPATIBILITY.md §3, SECURITY.md90-day public window OR embargoed advisory per disclosure policy
Cross-host portabilityProfiles + ConformanceBlack-box scenario suite runs against every claimed host
BYOK secret non-leakageSECURITY/invariants.yaml SR-1Public conformance test on every protocol-tier host
Cross-tenant memory isolationagent-memory.md + CTI-1 invariantPublic test; mechanically verified on the Postgres reference host
Replay determinismreplay.mdFork-from-checkpoint scenarios in the conformance suite
Signed webhook deliverywebhooks.mdHMAC-SHA256({ts}.{body}); replay-attack-resistant verification recipe

What's explicitly out of scope

  • Runtime SLA. OpenWOP defines the protocol, not the host's uptime. Your host vendor (or your own host) owns that.
  • Throughput claims. The production capability is operational-readiness (backpressure, retention, claim acquisition) — NOT a throughput floor. A single-pg.Client Postgres host can satisfy it while serializing writes.
  • A managed service from the OpenWOP project. The protocol is open; the reference hosts are reference implementations. There is no hosted, paid offering from the steward at this time. See Roadmap.
  • Lock-in protection across major versions. Each major is additive within itself; breaking changes land only at a major boundary. Support past a major is a commitment your vendor would need to make.

The leaderboard

/conformance/ is the public record of which hosts implement which profiles, with their results against the conformance suite. Read it cynically. Exact counts change with every run, so they live there, not here. What each host claims:

  • v2 reference host (openwop-host-v2-reference, in openwop-examples): all three v2 profiles certified. Evidence tier self — the steward built it, so it is not independent evidence.
  • openwop-app (openwop-workflow-engine, the production host at app.openwop.dev): all three v2 profiles certified. Its latest run also records a few failures on optional checks outside the certified floor; the leaderboard lists them.
  • MyndHyve workflow-runtime: openwop-discovery-core and openwop-core-standard certified. Run by the same organization as the steward, so it is not independent evidence.

Security posture in one paragraph

Every protocol-tier MUST-NOT in SECURITY/invariants.yaml has a public conformance test, and CI refuses a change that leaves one untested. New invariants land with the RFC that introduces them. The threat models (secret leakage, prompt injection, node-pack supply chain, provider policy, auth profiles) are public under SECURITY/ on GitHub.

Governance posture

OpenWOP is a single-steward project today: one maintainer, one organization. While that lasts, comment windows and the two-approval rule are waived (and each waiver is recorded), but evidence requirements never are.

The project moves to a cross-vendor working group once three independent organizations each have a maintainer and a second host implementation exists outside the steward. Neither condition is met yet. If your evaluation needs multi-vendor governance today, raise it now. Governance has the current state.

Questions worth raising in your eval

These are the questions a careful evaluator should ask. They're easier to answer up front than after the contract is signed.

  1. Which OpenWOP host will we run? Are we self-hosting, paying a vendor, or both?
  2. Which profiles does that host claim, and does the leaderboard back the claim?
  3. What's our migration path if the host vendor stops supporting OpenWOP?
  4. How do we get notified about safety-fix advisories? (Answer: GitHub releases on openwop/openwop.)
  5. What's our policy for adopting a new major version when one ships?

Read the leaderboard cynically.