If Approval Says 40 but the Tool Would Send 120: Check Before Forwarding

Suppose an agent has approval to order 40 units. Will the tool still mean “40 units” when the agent finally dispatches it? A change to a tool definition or its conversion logic may change the effect even if the action arguments look unchanged. That is the concrete question Netsujo brought from Agent Role Contracts (ARC) declaration tests into discussions with external researchers about a joint ERP experiment.

A change outside the preflight declaration

ARC G1 checks the consistency of supplied task, action, and binding declarations. If an underlying tool definition changes after those declarations were frozen, the same declaration may still pass while the resulting external operation changes. That is a boundary of declaration validation, rather than evidence of a shipped ARC runtime failure.

In ARC #117, we proposed a T4 tool-definition-drift experiment separating three evidence planes: declaration checks, authorization immediately before forwarding, and persisted ERP effects. One candidate scenario maps an approved quantity of 40 to a resulting quantity of 120 after a consequential definition change. That 40-to-120 comparison is a proposed test case, not a jointly frozen or approved test result.

The dangerous ambiguity of “allow”

The reference-model maintainer's explanation of the Guardian mock, described a specific behavior: a dispatched result report triggers a digest recheck that, in enforced mode, moves the reservation into HELD. Reviewing that mock, we pointed out that the steps/toolCallResult envelope still replies with allow / result recorded. This is an acknowledgement that a report was received, not a permit to forward the ERP operation.

After that finding was raised, the reference suite at commit 943a495 introduced an R1 mapping on a pre-forward steps/toolCallRequest. The gateway measures the active definition, presents a fresh attempt and provenance, and forwards only when the corresponding request receives a schema-valid allow. This is different from inventing a dispatched report before dispatch or treating a post-result acknowledgement as permission. These are measurements on a reference model, kept distinct from proof that a real ERP send was prevented.

What Netsujo independently reproduced

Netsujo reran the revised reference tests on a separate M3 host. Our record reports successful dynamic testing across 13 cases, T1–T10 regression coverage (with T9 an expected miss), self-tests and transcript verification. That establishes reproducible reference-mock behavior. It does not establish that a real PostgreSQL ERP gateway blocked a physical network send, and it is not the final independent code-QC decision for a jointly executed pilot.

Separately, the published ARC 1.0.1 ERP-shaped synthetic declaration check exercised a G1 binding with fictional parameters. Those results remain about supplied declarations, with execution_authorized:false in every case. They do not authenticate the Guardian's decision or a durable ERP effect.

What external collaborators changed about the plan

According to Netsujo's record of the reply, an external researcher collaborating on the pilot design agreed with the ARC-side clarifications that the two drift conditions (C2 and C3) must use the same frozen tool-definition mutation and that three boundaries must be fixed before implementation. The ARC-side proposal labels them A1, where authority is captured; R1, where the effective definition is revalidated; and K1, where the ERP effect may become durable. That reply was given outside GitHub and summarized by Netsujo; it is not a frozen joint agreement. The reference-model maintainer's reply mapped C2 to enforcing reconciliation and C3 to declaration-only controls, and said the recorded-but-not-enforced T4b variant can run as an additional, separately labelled case.

A meaningful joint run would require byte-exact definitions and hashes, authenticated provenance, distinct operation/attempt identities, gateway no-forward records, and independent ERP readback after the relevant commitment window—even after a timeout or 409. The external laboratory's reuse, modification, execution and publication permissions must also be established rather than inferred from the availability of a public repository.

As recorded in the November 10 checkpoint on ARC #117, the V0.3.2 proposal was under review and the joint contract was not frozen; no new joint ERP C0–C3 execution has been run. Keeping that distinction visible is part of responsible experimentation.

Questions to bring to your own gateway

When does your agent platform measure the tool definition it will actually use? Who computes and authenticates that version or hash? Which concrete signal permits the gateway to send the external request? What durable receiver-side evidence is required to conclude that the resulting effect occurred? A preflight declaration check, a Guardian decision, and an actual receiver record should be reported separately.

Related background: How much should an AI agent be allowed to do? and what an ARC PASS does and does not guarantee.

Can your runtime detect a tool-definition change after approval but before forwarding? We welcome implementation experiences and examples where an existing gateway or IAM design already covers this risk in ARC #117.

Primary sources: Guardian semantics, pre-forward mapping, Netsujo reproduction, joint-pilot status. Netsujo develops ARC. AI-assisted editing was used; the source and scope of each claim are linked above.