# Action approval record

**Version 0.1 · September 21, 2026 · Rethinking Agents**  
Companion to [What exactly did you approve?](/blog/what-exactly-did-you-approve). This is a design/review worksheet. It implements no enforcement and certifies no system.

## Use it for one consequential action

Choose an operation that creates an external consequence: sending a document, publishing a release or changing a shared resource. Record the model proposal separately from the reviewer-approved operation and actual submission. Do not collect credentials or unnecessary private document bodies in this worksheet. Keep sensitive evidence in an appropriately controlled store and reference it here.

For ordinary local draft edits, first consider whether constrained access and a normal diff review already solve the problem. Do not introduce per-edit approval merely because this worksheet exists.

## Worked synthetic case: send the migration note

**Status:** fictional specification; no actual approval, send, receipt or test. All identifiers below are illustrative. `.invalid` addresses cannot serve as real recipients. The proposed adapter fields are not asserted to be a LangChain API.

### 1. Useful task and scope

A support maintainer wants to send the cleaned SDK migration note to a designated customer review inbox. The agent prepares the note. The maintainer controls release. The sender can send only the reviewed immutable artifact to the reviewed recipient.

Successful authorized outcome: one message containing exactly the reviewed note, no attachments, delivered through the approved service identity to the specified address, with a recorded service receipt. A receipt's exact meaning must be established from the chosen sender API before implementation.

### 2. Model proposal

```text
pending action: fictional-thread-17 / fictional-call-03
operation: send_document
recipient: engineering@example.invalid
document reference: migration-note.md (mutable working path)
```

This proposal alone is insufficient for release: the document reference does not identify immutable bytes and the recipient needs correction.

### 3. Review artifact

The following UTF-8 text is the complete proposed approved body, with LF newlines and one trailing newline. No attachments, hidden fields, embeds or substituted signatures are part of the approved content.

```text
SDK migration note

Use parse_response_v2 for new integrations.
Existing parse_response calls remain supported in this example.
Validate the migration against your integration tests before release.
```

These are **fictional SDK statements**, not technical guidance about a real product. In a real review, verify factual and disclosure appropriateness separately from byte identity.

Review interface must show recipient, full body, attachments (none), operation and sending account. Show the recipient correction and content revision as separate changes. The example omits a digest intentionally: compute it from the exact executable artifact once one exists; do not treat a made-up hash as evidence.

### 4. Proposed authorized operation

| Field | Synthetic specification |
|---|---|
| Operation | `send_document` |
| Approved recipient | `sdk-review@example.invalid` |
| Approved artifact | Immutable `migration-note/revision-04`; bytes as above |
| Attachments | None |
| Sending principal | Fictional support sender, scoped to this workflow |
| Reviewer | Fictional role `support-release-maintainer`; no real person |
| Authority check | Application verifies role and action scope when recording and before dispatch |
| Decision | **Not obtained**; target behavior is approve the corrected operation |
| Invalidation | Changed bytes, recipient, attachments, operation, sender identity, revoked authority or expired review |
| Expiry | Choose from operational requirements; not specified or validated here |
| Operation identifier | `fictional-send-17-03-v04`; stable across recovery of the same intended effect |
| Receiver deduplication | **Unknown** until actual API is selected and checked |
| Submission/receipt | **No submission; no receipt** |

If the API cannot bind a body to an immutable artifact, the executor must compare the actual outgoing bytes with the reviewed content immediately before submission. Ensure validation and use cannot resolve different artifact versions. The architecture must explain the enforcing boundary; writing these requirements down does not implement it.

### 5. Allowed and rejected changes

- **Allowed before review:** agent revises the local draft; proposal is regenerated with a new revision.
- **Allowed after review:** internal trace annotations that cannot change content, principal, operation or destination, if the application explicitly defines them as nonmaterial.
- **Requires new review:** changing the recipient, note, attachment, sender or operation.
- **Stops execution:** authority revoked or approval expires before dispatch.
- **Needs reconciliation:** timeout after a possible send; do not assume the recipient received nothing.
- **Never a fallback:** discarding the reviewer's correction and sending the original proposal because a later configuration disallows edits.

## Blank record

```text
Record status: proposed / reviewed / submitted / confirmed / rejected / unknown
Useful task:
Action requiring review and why:
System/version/configuration reference:
Thread + pending-action identifiers:

MODEL PROPOSAL
Tool/operation:
Arguments and referenced resources:

WHAT THE REVIEWER SAW
Display snapshot/reference:
Exact destination and audience:
Artifact revision + byte digest/algorithm, if applicable:
Attachments and other transmitted content:
Execution principal:
Material changes from proposal:

DECISION
Reviewer identity and authority evidence (no credentials):
Decision + timestamp:
Approved operation/reference:
Expiry and invalidation conditions:
Revocation behavior:

EXECUTION
Final submitted operation + artifact reference:
Executor authorization/check results:
Stable intended-operation identifier:
Attempt identifier + timestamp:
External receipt/reference and what it proves:
Outcome: confirmed / rejected / unknown
Recovery/reconciliation:
Any divergence from authorized operation:

UTILITY AND LIMITS
Legitimate task complete?:
Human review/recovery effort:
Unobserved boundaries:
Evidence access/retention owner:
```

## Proposed acceptance cases — all unexecuted

Use a fake sender first. Capture invocation count, exact submitted fields and an artificial receipt. Real sender behavior requires separate authorization and its own evidence. For every test also verify a clean authorized send remains possible.

| ID | Variation | Required observable behavior | Evidence to capture |
|---|---|---|---|
| A01 | Approve unchanged immutable note | Exactly approved operation reaches fake sender | Reviewed artifact, invocation and fake receipt |
| A02 | Reviewer changes recipient | Corrected recipient reaches sender; original remains distinguishable in proposal | Four connected records |
| A03 | Reviewer edits note | Only corrected immutable revision is sent | Submitted bytes and reviewed digest |
| A04 | Reviewer rejects | No sender invocation for rejected call | Decision plus zero matching invocations |
| A05 | Mutable file changes after review | Changed content cannot be sent under old decision | Old/new revisions and refusal or renewed review |
| A06 | Sender account changes | Old decision invalidates | Principal comparison and blocked dispatch |
| A07 | Attachment added after review | Old decision invalidates | Complete outgoing-content comparison |
| A08 | Two concurrent pending actions | Each decision remains linked to its own request; crossing them rejected | Thread/action associations and capture |
| A09 | Restart while waiting | Correct pending request survives with persistent backend; absent state is reported | Checkpoint identity and resumed review |
| A10 | Authority revoked before dispatch | Action stops; original proposal does not run | Authority result and zero invocation |
| A11 | Receiver accepts but reply is lost | Status stays unknown until reconciled; no unobserved duplicate | Receiver operation log and attempt records |
| A12 | Retry same intended operation | Deduplication semantics prevent duplicate effect where supported; otherwise investigate | Stable operation ID and receiver evidence |
| A13 | New legitimate send with same body | Distinct intended operation remains possible with its own decision | New operation ID, review and outcome |
| A14 | Reversible local draft edit | No unnecessary external-send approval introduced | Completion and review-effort record |

A “pass” requires the expected evidence. Missing observations are unknown, not passes. Stop a later experiment if the capture cannot distinguish invocation from effect. Report blocked legitimate sends and human effort; successful rejection alone does not establish usefulness.

## Provenance

Framework observations and limitations are in the [approval source register](/research/approval-binding.md). The worked record, field choices and acceptance cases are original RA design proposals. No runtime, customer or incident evidence is implied.