Who built this packet?

Integrity starts after construction

Imagine an assistant turns a product request, two repository files, and an operating policy into a bounded task packet. The packet is hashed. An authorized human approver reviews it and allows one narrow action. A runtime service admits the continuation, and a worker attempts the work.

If the packet later has the same digest, its content has not changed. That is useful integrity evidence. It does not identify the assistant that selected and interpreted the sources, show that those sources were authentic, or establish that the packet was assembled correctly.

This is the boundary exposed by the public WITS interworking work. The evidence remains valid for what it actually tests: production and validation of pinned candidate artifacts across separate implementations. Authenticated packet-construction provenance was not part of that claim. Its absence is therefore a real but non-breaking HACP v0.3-candidate limitation—not a reason to discard the current integrity or interworking evidence.

One packet, four accountable roles

Role	Question it answers	What it cannot silently become
Builder or assembler	Who constructed this packet from which declared inputs?	The human approver, runtime issuer, or executor.
Authorized human approver	Who permitted which bounded continuation?	Proof that the packet was correctly assembled or the work occurred.
Runtime issuer or admitter	Which trusted runtime admitted this exact claim under which profile?	The source of human authority or proof of execution.
Executor	Who or what attempted the authorized work?	The builder, approver, or issuer merely because it received the packet.

The protocol needs those roles to stay separate even when one person or system happens to perform more than one of them. Collapsing the nouns makes evidence look stronger than it is.

What the digest says

The HACP v0.3-candidate task-packet schema requires a domain-separated digest and source references. The executable success fixture shows that binding in a concrete packet.

A digest proves integrity after construction. It gives later participants an exact value to compare and makes changed bytes detectable. A digest does not establish builder identity, source authenticity, correct interpretation, approval, or execution authority. It is a content binding, not a biography, endorsement, or permission slip.

Adding createdBy: "agent-7" would not solve the problem. A bare string can be copied, invented, or reassigned by the caller. It says what the packet claims about its builder; it does not show who authenticated that principal or cryptographically bound the principal to this construction claim.

A concrete WITS sequence

1. WITS produces candidate artifacts against an exact, pinned HACP package.
2. HACP independently validates the artifacts and preserves the public interworking evidence.
3. The owner accepts that bounded evidence with its disclosed limitations.
4. The packet digest and source revisions allow later reviewers to inspect what was evaluated.

That sequence supports the published interworking claim. The public WITS qualification decision packet records the pinned production, validation, owner decision, and remaining limitations. It does not claim that HACP v0.3-candidate authenticates the builder of every task packet or proves correct construction.

What authenticated construction provenance could add

A future record could make the builder's claim inspectable without changing the meaning of the current task packet. A packet-construction-receipt or packet-assembly-attestation could bind:

• an authenticated builder principal and authentication method;
• the exact packet digest;
• exact source revision and digest references;
• the construction profile, tool, and runtime identity;
• construction time;
• declared transformations and limitations; and
• a cryptographic binding between the builder and the construction claim.

Even then, the result would be an attestation: evidence that an authenticated principal made a specific construction claim. It would not prove that the principal chose the right sources, interpreted them correctly, omitted nothing important, or produced a packet that deserves approval.

What this does not prove

• The limitation does not invalidate the current HACP v0.3-candidate integrity, conformance, or WITS interworking evidence.
• A digest does not authenticate the packet builder or any source.
• An authenticated assembly attestation would not prove correct construction.
• Builder authentication would not grant approval or execution authority.
• Human approval would not prove that construction, execution, or external effects were correct.
• Runtime admission would not prove exactly-once external effects.

Candidate disposition

No v0.3-candidate schema is being changed, republished, or version-bumped because of this finding. The candidate status and existing non-claims remain intact. This becomes a correctness problem only when an implementation claims that its packet builder was authenticated or that correct construction was proven.

Future protocol design is tracked in HACP issue #69. The issue explores a separate provenance record with explicit verification and failure semantics instead of adding an unauthenticated identity label to the current packet.