OpenWOP openwop.dev

Conformance Certification Bundle

A host's profile claims are derivable from its /.well-known/openwop discovery document, but the evidence that a host actually passes a claimed profile has lived as hand-authored prose in examples/hosts/*/conformance.md and INTEROP-MATRIX.md — not…

Status: Stable · v1.x — reached Accepted via RFC 0089 (2026-06-02). Additive v1.x extension. Defines a machine-readable conformance certification bundle — an out-of-band artifact that binds a host's claimed profiles to the reproducible run that substantiates them. NOT a runtime wire surface (no /v1/* endpoint); the only discovery touch is one optional pointer field. Keywords MUST, SHOULD, MAY follow RFC 2119. See auth.md for the status legend.

Why this exists

A host's profile claims are derivable from its /.well-known/openwop discovery document, but the evidence that a host actually passes a claimed profile has lived as hand-authored prose in examples/hosts/*/conformance.md and INTEROP-MATRIX.md — not bound to the run that produced it, and not machine-verifiable. An external standards-readiness review required that a standard "bind each claimed profile to a concrete suite version, pass list, host commit, and discovery document." This document defines that binding as a single JSON artifact with a falsifiable validity rule, so any third party (auditor, adopter, registry) reads the same shape and can mechanically re-check a claim. It is distinct from compliance.md (a non-normative control-vocabulary map) and from profiles.md (the discovery predicates the bundle _reuses_).

§A — The bundle (normative)

A conformance certification bundle is a JSON document conforming to conformance-certification-bundle.schema.json. It MUST carry: bundleVersion, generatedAt, generator, suite (@openwop/openwop-conformance + exact version), host (name + version, optional vendor/commit), discovery (url + sha256 + the verbatim document), claimedProfiles, and results (totals + the passed/failed/skipped scenario-ID lists). discovery.sha256 MUST be the SHA-256 of the canonical-JSON serialization of discovery.document. The generator MUST NOT place a scenario in results.passed that did not run non-vacuously.

§B — The binding rule (normative)

A bundle is valid for a profile P iff both hold:

1. Discovery-derivable. P is derivable from discovery.document via the canonical predicates (profiles.md deriveProfiles; core-standard-profile.md isCoreStandard; agent-platform-profile.md isAgentPlatform). A bundle MUST NOT list in claimedProfiles any profile its own discovery.document does not derive. 2. Floor-proven. Every floor scenario required by P appears in results.passed (never in failed or skipped). The required floor-scenario set per profile is machine-readable in conformance/src/lib/profiles.ts (PROFILE_FLOOR_SCENARIOS); for openwop-core-standard it is the nine black-box scenarios of core-standard-profile.md §C plus the interrupt- family.

A consumer that relies on a bundle MUST re-evaluate both conditions against the embedded discovery.document (the reference implementation is verifyBundle() in conformance/src/lib/profiles.ts) rather than trusting claimedProfiles verbatim. discovery.sha256 lets a verifier confirm the captured document matches one fetched live.

§C — Generation (normative behavior of the reference harness)

The reference conformance harness SHOULD provide a --certify <out.json> mode that: (a) fetches /.well-known/openwop and captures it verbatim plus its SHA-256; (b) derives claimedProfiles; (c) runs the suite, recording each scenario's terminal state into results; and (d) writes a bundle that validates against §A. A bundle is authoritative only when generated by an independent verifier (e.g. the steward or a neutral CI), not self-asserted by the host under test — host.commit is self-reported and otherwise unverifiable without re-execution.

§D — Optional discovery pointer

A host MAY advertise conformance.certificationBundleUrl (an optional format: uri field on the discovery document, per capabilities.schema.json) pointing at its most recent published bundle. Omitting it is fully conformant; clients MUST tolerate its absence.

Open spec gaps

  • Scenario-ID stability + floor-set source (G1/G2). §B(2) depends on stable scenario identifiers and the PROFILE_FLOOR_SCENARIOS map staying in sync with each profile's prose definition. Floor sets for profiles beyond openwop-core-standard are added as those profiles' floor scenarios stabilize.
  • Signing / tamper-evidence. v1 bundles are unsigned-but-reproducible (re-running the named suite against the same host commit reproduces the pass list). A future RFC MAY wrap the bundle in an Ed25519 / in-toto envelope.
  • Reference-host generation. The openwop-conformance --certify generator (conformance/src/cli.ts) and a committed reference-host bundle (examples/hosts/in-memory/certification-bundle.json) landed at RFC 0089 Accepted; this document defines the format + binding rule that they implement.