Your agent said done. Who authorized the next step?

“Done” is a report state

Suppose an agent receives a task to inspect a pull request. It returns a detailed report: no blocking findings, unit tests green, and a recommendation to merge. That report may be excellent evidence. It is not a merge decision, deployment permission, risk acceptance, or proof that every claimed check ran correctly.

The next consequential transition needs its own authority. The person or owner system responsible for the merge must decide against the exact request, revision, evidence, consequences, and policy boundary. HACP keeps the report and that decision as separate records.

A bounded sequence

1. A task packet authorizes review of commit abc123; repository mutation remains denied.
2. The agent returns an agent report with findings, test evidence, and a request for the next human decision.
3. A reviewer checks that the report matches the packet and current revision.
4. A human decision approves one bounded successor: prepare the merge of abc123 under the repository’s policy.
5. A consumption receipt records which successor claim was admitted locally. Only then can that named continuation begin—subject to the actual runtime’s authorization checks.

If the PR changed after the report, the correct outcome is a stale-packet stop. If the decision approved preparation but not mutation, “prepare” must not silently become “merge.” If execution later becomes ambiguous, the system should return evidence for human review, not infer permission to retry.

Four questions that prevent the shortcut

• What was approved? The exact request, action, revision, scope, and expiry.
• What happened? The report and its evidence, including uncertainty and boundary statements.
• What was admitted? A named successor’s exact claim under a declared local rule.
• What happens next? A new human decision when another consequential transition is required.

The candidate bindings

The public task packet, agent report, human decision, and receipt show distinct roles. Invalid fixtures splice reports, authority, decisions, requests, or start evidence from another chain and require rejection.

What this does not prove

• Report presence or schema validity does not prove completion, merge readiness, deployment permission, or owner approval.
• Bot confidence and passing checks are inputs to a decision, not authority.
• A consumption receipt does not prove provider execution or exactly-once external effects.
• HACP does not execute or merge work by itself.
• HACP records authority; it does not create the organization’s authority model.