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.

The shortest honest pitch

OpenWOP is an open wire-level protocol for multi-agent workflow orchestration. v2 is the current major (cut 2026-09-05, currently v2.1.x) and v1.x continues as a maintained parallel track; the evolution policy is additive-only within a major; five host implementations exist in the public conformance leaderboard; the protocol is licensed Apache 2.0 with no patent or 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 four versioning axes and the rules they enforce.
• Security posture — threat model, disclosure policy, public invariants.
• Governance — how decisions get made, the bootstrap-phase amendment, the path to a cross-vendor working group.

What the protocol guarantees

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; a major boundary is where breaking changes land. v2 shipped 2026-09-05 and v1 was not dropped for it — COMPATIBILITY.md §5 runs both as parallel tracks, and v1 retires only on a host-inventory rule (every INTEROP-MATRIX host publishing a non-vacuous v2 bundle, plus 90 days), not on a calendar. Forward compatibility past a major is still a custom commitment your vendor would need to make.

The leaderboard

/conformance/ is the public record of which hosts implement which profiles, with the pass/fail/skip counts against the conformance suite. Read it cynically. Specifically:

• Postgres reference: claims the production profile end-to-end with mechanical proof. Recent measurement: 781/850 (91.9% total, 96.4% applicable).
• Python reference: 700/788 = 100% of applicable scenarios pass. Honest about NOT not advertising audit-log signing (stdlib lacks Ed25519).
• SQLite reference: 669/731, zero failures, claims interrupt + audit-log + auth-rotation profiles.
• In-memory reference: dev-tier; passes the core profile.
• MyndHyve (third-party): passes the ai-envelope-shape scenario class (18/18). NOT the full suite — this is partial third-party coverage and the leaderboard reflects it honestly.

Security posture in one paragraph

Every protocol-tier MUST-NOT in SECURITY/invariants.yaml has a corresponding public conformance test, enforced at merge time by scripts/check-security-invariants.sh. 56 protocol-tier invariants tracked at the time of this writing. New invariants land alongside the RFC that introduces them. The threat models for secret leakage, prompt injection, node-pack supply chain, provider policy, and auth profiles are all public under SECURITY/ on GitHub.

Governance posture

OpenWOP is a single-steward project today, with the bootstrap-phase amendment (GOVERNANCE.md) explicitly documenting one-approval review until a non-steward maintainer is named. The roadmap commits to a cross-vendor working group as v1 matures; that's an open governance question, not a closed one. If your evaluation requires multi-vendor governance today, that's worth raising as a deal-breaker now rather than later — see Governance for 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. v2 has landed and v1 is still maintained — what's our policy for adopting a new major, and for the eventual v1 retirement?

Next steps