An approval with no object
N17Q bound human consent to normalized arguments, current policy, a precise run checkpoint, effect identity, expiry, and world preconditions that could still invalidate execution.
N17Q asked a reviewer, “Allow the agent to create a request?”
The reviewer approved. Before execution, the agent changed the target branch, regenerated the body, and retried under a newer policy. The interface still showed a green approval because it was attached to the tool name and run stage.
The person had agreed to a category. The system used that agreement as permission for an object they had never seen.
Approval that can float from one consequence to another is not approval. It is a durable gap in the policy gate.
The early record was too small
My first approval table stored run, tool name, reviewer, decision, and time. It answered who clicked yes to which general capability.
It did not answer which normalized arguments were shown, what world state made them meaningful, which policy required review, which effect identity would consume the decision, or when the agreement should expire.
The missing fields were not audit decoration. They were the difference between one bounded authorization and reusable permission.
I redesigned approval as a prepared capability tied to exact state.
Preparation froze the review object
Before asking for consent, N17Q normalized the candidate request, resolved opaque handles, prepared immutable artifacts, evaluated current policy, and captured relevant world preconditions.
The result was an approval object with a content digest. The UI rendered only from that canonical object. It did not ask the model to summarize the action again or reconstruct meaning from raw arguments in the browser.
Any change produced a new approval revision and digest. The old review remained historical and non-transferable.
The person and executor referred to the same bytes and conditions.
Normalized arguments came before consent
Friendly aliases, optional defaults, relative paths, and flexible input were resolved before review. A destination name became a stable destination identity. A repository path became a canonical scoped path. An export became an artifact digest.
The review showed human meaning and technical identity where relevant. Approval bound the normalized product arguments, not the model's raw spelling or provider schema.
Changing a default or alias mapping could not alter an existing permission. An ambiguous value stopped preparation.
Consent followed consequence after interpretation, not before it.
One effect identity consumed the receipt
The prepared request received a stable semantic effect intent. The approval receipt named that identity and could be consumed only to make it executable.
Retries under the same intent followed its effect contract and idempotency key. A second semantic intent, even with similar arguments, required another receipt. Reusing one receipt with a different digest failed.
Consumption was atomic with durable creation or activation of the effect intent. Two workers could not race the same unused approval into two consequences.
The green decision represented one opportunity to pursue one effect.
An agent run changed as it gathered evidence and made plans. Approval needed to state which checkpoint supplied the relevant context.
N17Q included checkpoint identity, tool registry revision, selected evidence, known prior effects, and remaining budget where those changed the decision. The reviewer could open that context without reading the entire trace.
If the run resumed from another checkpoint and produced different arguments, the old receipt stayed attached to its historical branch. It did not drift forward because the tool name matched.
The checkpoint made consent local in the trajectory.
Policy digest explained why review existed
The approval stored the policy revision and decision that required it. A reviewer could see whether the trigger was external mutation, sensitive data, broad scope, missing idempotency, or a scenario-specific rule.
If policy changed before execution, N17Q evaluated current rules again. A newly prohibited action stopped even with a valid historical approval. A newly relaxed policy did not automatically consume or broaden an old receipt.
The trace preserved both decisions: allowed to request approval then, no longer executable now.
Consent could satisfy a policy condition. It could not supersede policy.
World preconditions stayed live
The reviewed patch targeted a repository tree digest. The destination request targeted an artifact and assumed no existing effect for the semantic intent. Those facts could change after review.
Approval recorded the exact preconditions and the worker checked them immediately before execution. A changed branch, modified file, disabled destination, or newly observed prior effect made the receipt stale.
N17Q did not silently rebase or regenerate. It prepared a new object, highlighted what changed, and requested a new decision if the action remained eligible.
Approval was not a lock on the world. It was conditional on the world still matching.
A browser tab could remain open overnight. A run could pause for days. Membership, policy, destination ownership, and the reviewer's own intention might change.
Each receipt had a server-evaluated expiry appropriate to effect class. The client displayed time remaining as convenience but could not extend it by changing its clock or staying offline.
Expiry did not discard annotations or the prepared object. The reviewer could prepare again under current state and inspect any difference.
Short-lived authority and humane recovery could coexist.
Identity was re-established at decision time
The server established the current reviewer from authentication. Hidden fields and model messages could not name who approved.
The approval policy checked reviewer role, delegation scope, separation-of-duty rules where configured, and current membership. Reauthentication could be required for sensitive destinations.
Reauthentication confirmed identity. It did not substitute for inspecting changed content. If the object changed during the authentication step, the digest no longer matched and review restarted.
Who approved and what they approved were independent necessary facts.
I had initially asked the model to summarize the tool call for the reviewer. It produced fluent explanations and occasionally omitted the detail that mattered most.
N17Q generated confirmation text deterministically from the product capability and approval object. It named artifact, target, destination, visibility, effect count, idempotency, queryability, compensation limits, and expiry as relevant.
The model's rationale remained labelled proposal material below the consequence. It could help explain why the action was suggested and could not define what the system would execute.
The application owned the promise made by the button.
Recovery limits were part of the decision
Two actions with identical visible results could have different failure semantics. One destination supported idempotency and status lookup; another could become permanently uncertain after a lost response.
The approval view stated these limits before consent. It explained whether Retry was safe under one effect identity, whether completion could be queried, and whether compensation existed.
This was not an exhaustive distributed-systems lecture. It was the information needed to understand the downside of authorizing the effect.
A person could reject or choose a safer alternative based on recovery, not only outcome.
N17Q allowed review of several homogeneous read requests or local patches when every item was materialized in advance. The receipt named the exact set, individual digests, total effect budget, and all-or-partial execution policy.
Adding an item invalidated the batch. A tool returning more work did not inherit approval. Partial failure preserved per-item states and did not repeat successful effects.
Open-ended permission such as “approve the next ten calls” did not exist. Count alone did not define consequence.
Batching reduced review overhead without turning consent into a blank cheque.
Policy could deny a broad request and suggest a narrower path. The agent might change a repository-wide write into one file patch or a public delivery into local preview.
N17Q created a new request and approval object for the narrower consequence. It did not mutate the denied one under the same green state.
The review history showed original proposal, policy reason, narrowed alternative, and final decision. This helped evaluators see whether the agent respected the boundary or repeatedly paraphrased the broad action.
Permission attached to the accepted scope, not the conversational theme.
Rejection closed one path
Rejecting an approval request made that exact object non-executable. The reviewer could provide a bounded reason such as wrong destination, insufficient evidence, scope too broad, unsafe recovery, or prefer manual action.
The agent could propose a meaningfully different alternative. Repeating equivalent normalized arguments after rejection triggered a policy signal and could stop the run.
The system did not keep presenting the same request with rephrased rationale. Rejection was a state transition, not an obstacle for persuasive retry.
Human control included the ability to end the proposal.
An unused receipt could be revoked manually or automatically after membership or policy change. Revocation prevented consumption and recorded its reason.
Revoking after an effect had committed did not undo it. A cancel, delete, supersede, or correction was another product capability with new policy, approval, attempts, and receipt.
The interface used different verbs and explained residual effects. External observers, logs, or copied artifacts might remain.
Approval lifecycle governed permission to act, not the entire future of the world.
The client could optimistically show a submitted decision while the server processed it. Execution never relied on client state.
The server stored receipt, consumption, expiry, revocation, and current eligibility. Reloading or opening another device reconstructed the same record. A duplicated approval submission converged under a stable request identity.
The UI did not treat a green toast or disabled button as proof. It linked to the durable receipt and current effect state.
Visual confidence followed committed product state.
Long review did not freeze the run globally
While one consequential action waited for approval, the agent could perform unrelated permitted reads or local analysis within budget. It could not change the prepared artifact and keep the old receipt eligible.
The checkpoint tracked which branches depended on the decision. If later evidence made the action unnecessary, the run could supersede the request and revoke its unused approval object.
This avoided holding the whole system still while preserving the exact boundary around consequence.
Concurrency was explicit rather than accidental.
A scenario could require one owner, two independent reviewers, or a specialist for sensitive data. The approval policy named the rule.
Each decision linked to the same prepared object and reviewer identity. Conflicting decisions produced unresolved state according to policy; a majority did not emerge unless explicitly designed.
A later edit invalidated all decisions tied to the old digest. Delegation was bounded by workspace, capability, and time.
Shared review added evidence and separation of duty without turning authority into engagement counts.
Tool and model changes could invalidate consent
An adapter mapping or tool schema change might alter normalization, destination behavior, or recovery guarantees. A model change alone did not necessarily change the prepared consequence because model reasoning ended before approval.
N17Q bound adapter and effect-contract revisions. Meaning-bearing changes invalidated the receipt. Cosmetic provider metadata did not, under explicit compatibility rules.
The distinction reduced needless review and prevented an old decision from flowing through a new execution interpretation.
Version compatibility was a product decision, not a string comparison.
The audit record joined decision and outcome
The trace linked candidate request, normalization, policy, prepared approval object, reviewer decision, receipt, execution-time recheck, effect attempts, world observations, and final receipt.
An investigation could answer what the reviewer saw, why the system permitted execution, whether preconditions still held, which bytes were sent, and what evidence says the effect occurred.
Approval without outcome evidence would be incomplete. Outcome without approval evidence would be unauthorized success.
The chain made human control inspectable rather than ceremonial.
Unknown outcome did not reopen consent
If an approved action might have executed but its acknowledgement was lost, N17Q kept the original effect intent and approval relationship. It did not ask the reviewer to approve a duplicate call as if that resolved uncertainty.
Recovery followed the effect contract: query by stable identity, await a late receipt, inspect the destination, or pause. Another transport attempt could occur only under the same intent and proven idempotency semantics.
Where safe retry was unavailable, the interface explained that limitation. A new approval could not make a duplicate consequence harmless.
Consent authorized the intended effect once; it did not erase the need to discover whether that effect already happened.
A reviewer could open the prepared object on another authenticated device. The server reconstructed the exact diff, artifact, arguments, preconditions, and expiry from durable state.
The URL contained a random review reference, not a bearer token sufficient to approve. Authentication and current authorization remained required. Copying the link into another workspace or after revocation revealed no broader resource.
Offline review could inspect a downloaded artifact but could not submit a decision until the server rechecked current state. A signature over stale bytes remained historical evidence, not current execution authority.
Mobility applied to the review experience, not to an unbounded permission token.
Accessibility was part of exactness
If a reviewer using a keyboard or screen reader could not reach a deletion, destination warning, or changed precondition, the system had not really presented the exact consequence.
N17Q used semantic headings, a textual unified diff, labelled operation counts, clear focus order, and error links. Added and removed content never depended on color alone. Expiry updates avoided noisy announcements while important invalidation moved focus to a concise status.
The approval summary could be read independently of a visual trace canvas. Technical identifiers remained copyable without overwhelming the primary decision.
Consent quality depended on accessible comprehension, not only cryptographic binding.
Emergency disable sat above individual receipts
A connection, destination, or capability could require immediate suspension after a security concern. N17Q had a current policy switch that made every unused receipt for that scope non-executable.
The system appended revocation and policy events, stopped pending attempts where guarantees allowed, and reconciled unknown effects. It did not delete the approvals or claim already completed effects were reversed.
Restoring the capability did not revive old receipts automatically. New preparation and review used the repaired mapping and current policy.
An incident boundary could narrow authority globally without corrupting historical decisions.
Tests changed the object underneath approval
The most valuable fixtures approved a request, then changed one variable before execution: target digest, destination mapping, workspace role, policy revision, effect contract, budget, prior world effect, or expiry.
Every meaning-bearing change had to stop. The server could prepare a new review object and preserve annotations; it could not reuse the green decision.
Concurrent workers attempted to consume one receipt. Duplicate client submissions replayed the same decision. Revoked and expired receipts stayed unusable.
The happy path proved the button worked. Mutation tests proved it meant something.
Binding consent more tightly did not require asking about every model step. Read-only scoped observations and reversible local work could proceed under policy. Consequential actions were prepared and grouped coherently.
The product asked less often and with more specificity. Reviewers no longer had to approve vague stages because the agent had not yet materialized an effect.
This reduced fatigue while strengthening authority. The answer to approval overload was not broader permission; it was better placement and clearer objects.
Human attention went to decisions only a human was meant to own.
In the failure fixture, the green record remained attached to the old branch, body, policy, and checkpoint. It did not authorize the changed request.
The system prepared a new object and highlighted target, content digest, and policy differences. The reviewer rejected it because the branch change was unintended. No server call occurred.
Keeping the old decision in history clarified the failure without preserving its power.
This was the crucial property: approval could remain durable as evidence and expire as capability.
Consent needs edges
An agent trajectory invites broad language: continue, proceed, use tools, finish the task. Those phrases are useful goals and poor authorization objects.
N17Q gave consent edges—exact consequence, normalized input, requester and reviewer, checkpoint, policy, preconditions, effect identity, expiry, and consumption. Anything outside those edges returned to planning or review.
The system still depended on correct normalization, policy, adapter behavior, and interface presentation. Binding did not make approval infallible. It made mistakes local enough to inspect and test.
Approval should not follow the agent wherever its plan goes.
It should stay with the one thing a person actually agreed to let happen.