Two implementations, one candidate contract

What actually crossed the boundary

WITS independently produced all seven HACP v0.3-candidate record kinds through its native Product Decision and candidate persistence services. It emitted eleven public-safe records arranged into three branches: successful continuation, pre-start stop, and a later non-authorizing human response to that stop. HACP imported the bytes and validated them without importing WITS runtime code.

For example, the success bundle carries a task packet, authority-basis decision, decision request, consumption receipt, continuation context, and agent report. HACP validates each record’s schema and digest, then checks that the decision, claim, request, scope, start evidence, and report refer to the same bounded chain.

Three kinds of evidence, kept separate

Source	What it contributes	What it does not contribute
WITS	Independent production of the candidate encoding and three public bundles.	Proof of provider effects or full WITS requirement completion.
HACP	Schema, digest, branch, and cross-record validation; 43 passing candidate tests and 22 exact negative cases.	Authority, execution, or independent production by itself.
who-decides	A separate 44-case proof of local one-use continuation semantics, including concurrency and restart cases.	Production or validation of the broader v0.3 encoding.

This separation matters. Saying “two implementations” does not mean both systems perform every role in both directions. WITS produces the candidate encoding; HACP cross-validates it. who-decides supplies owner-accepted semantic evidence for local single-consumer admission.

Negative cases are part of the contract

A happy-path parse is weak evidence. The canonical suite also changes one relationship at a time: it strips continuation context, replays stale context, expands scope, uses expired or trusted-revoked authority, claims after start, crosses a loop ceiling, or splices records from different chains. All 22 cases must fail with their exact diagnostic sets.

The external validator first revalidates that canonical package. Only then does it admit the WITS bundle, verify byte digests and schema pins, and apply the same branch rules. That ordering prevents an external producer from quietly redefining the target it claims to pass.

What this does not prove

• It is not cross-vendor adoption, bidirectional production, a final release, or a formal standard.
• The proofs are local and synthetic. They do not make provider calls or demonstrate external effects.
• HACP and WITS use the same Apache-2.0 canonicalize library, so agreement retains common-mode JCS risk.
• WITS Task 1.3f’s single-read timestamp provenance remains unproven.
• A valid receipt does not authenticate its issuer or grant authority.

Review the evidence

Inspect the qualification packet, emitted WITS bundles, validation receipt, and who-decides evidence reconciliation.