Code-existence annotation

A planning agent that writes “we’ll call OrderService.Cancel(orderId) and update the audit log” has made two existence claims. The code-existence annotation pattern requires those claims to be marked: OrderService.Cancel [VERIFIED — Api/Features/Orders/CancelEndpoint.cs:42], or [ASSUMED], or [MISSING]. The investigation-gate hook then refuses to execute any step containing [ASSUMED] or [MISSING] annotations until they are upgraded to [VERIFIED].

The annotations are produced during the planning pass: the planner must attach evidence — a file:line from an actual Read event — to upgrade a reference to [VERIFIED]. A plan fragment looks like:

3. Call OrderService.CancelAsync(cmd)    [VERIFIED — Api/Features/Orders/OrderService.cs:57]
4. Emit OrderCancelled to the outbox     [ASSUMED — outbox pattern present, publisher symbol unread]
5. Update Dashboard.RecentCancellations  [MISSING — no such component found]

Steps 4 and 5 cannot execute until investigated; step 5 has already earned a plan revision before any code was written. The adjacent public work is Boris Tane’s plan-annotation cycle and the plannotator repo, which add human review markers to agent plans. Code-existence annotation narrows the idea to a single machine-checkable claim — does the referenced symbol exist — which is precisely the claim agents most often get wrong.

When to use

• Pair with an investigation-gate hook to make confabulation a build error rather than a code-review surprise.
• Long planning passes (Opus xhigh) where the planner’s output is consumed by downstream Sonnet workers — the workers can trust the verified columns and skip re-reading.

Compare with

A simple “list the files you read” footer is human-friendly but the agent can omit symbols it lied about. The annotation pattern attaches the evidence to every reference, which the gate hook can mechanically check.