What HACP v0.3-candidate proves—and does not prove

The short version

HACP v0.3-candidate has a closed, executable encoding for seven record kinds and three valid workflow branches. HACP validates those branches, their canonical digests, and 22 deliberately invalid mutations. WITS independently produced the same candidate encoding from its native services, and HACP accepted the three emitted bundles. A separate who-decides proof covers local one-use continuation semantics across 44 cases.

Those are useful, bounded results. They do not turn the candidate into a standard, prove external execution, or show that two distributed systems will create exactly one real-world effect.

A concrete sequence

1. A task packet names the bounded request and denied authority.
2. A human decision binds an exact request, action, packet, scope, and expiry.
3. A consumption receipt records one admitted local claim on that decision.
4. A continuation context and start record bind the admitted successor.
5. An agent report returns evidence and asks for the next human decision.

The candidate corpus checks this success branch, a pre-start stop branch, and a later human response to that stop. The flat set of fixtures is not itself a chain; only the manifest-declared bundles are semantic inputs.

What is supported by evidence

Claim	Evidence boundary
Record shape	Closed JSON Schemas for seven candidate record kinds.
Cross-record binding	Three declared bundles, RFC 8785 digests, and exact relationship checks.
Negative behavior	22 mutations must fail with the exact expected diagnostic sets.
Independent production	WITS emitted three bundles; HACP validated their public-safe bytes.
One-use continuation semantics	who-decides passed a separate 44-case local, same-file SQLite proof.
Restart readback	Local tests cover durable claim readback after restart.

What this does not prove

• No formal standard, final release, or cross-vendor maturity.
• No distributed consensus, cross-store atomicity, provider execution, settled cost, or exactly-once external effects.
• No provider-issued receipt. Candidate receipts are implementation records whose issuer trust must be established separately.
• No agent comprehension. Transport acknowledgement and valid JSON do not prove that an agent understood a request.
• No authority created by HACP. Organizational authority must already exist and be admitted under an approved policy.
• No general no-decision stop representation. The current stop response requires a real decision identity; issue #52 tracks that future contract gap.

Two additional limitations matter: WITS and HACP share the same canonicalization library, leaving common-mode risk, and WITS Task 1.3f has not proven the stronger single-read timestamp provenance required by its own requirement. The candidate evidence is synthetic and local.

Inspect or reproduce it

Start with the pinned candidate README, publication-readiness record, and WITS validation receipt. From a checkout at that revision, run npm ci, then npm run hacp:v03-candidate.