Claude Anvil: Work Orders That Learn

Claude Anvil is an internal instrument developed under Project Lattice, and this entry is its opening log: what the system actually does today, in plain terms, and what it has not yet proven. It is not a research initiative of its own — it is Lattice's second real-world case, alongside RECON, for the same question the initiative was already asking: what survives, and what has to be verified rather than assumed, when something is translated from one representation into another. Anvil is active and in daily internal use: every work order it drafts, every audit it runs, and every lesson it records is a real operational result. Whether that discipline measurably improves representation fidelity is a separate, still-unpublished research question, and this entry is careful not to blur the two.

The premise is narrow and checkable. A capable implementer can still return the wrong thing — not because it misunderstood the task, but because the task itself left something load-bearing unstated: what already exists and is accepted, what the owner has already decided, what condition marks the work as actually finished, and what standard of proof a completion claim has to meet. Treated as a disposable prompt, each of those gaps has to be rediscovered by hand, every time. Treated as an engineering artefact, they can be specified once, tested against, and improved when they fail.

Anvil runs as three named cycles rather than one generic prompting habit. Forge drafts a new work order from the project's currently verified state — a stated terminal outcome, the owner's invariants and boundary cases, and an investigation mandate — deliberately leaving ordinary implementation choices to the implementer rather than prescribing an architecture in advance.

Temper is what happens once an implementation comes back. Every material claim in it is checked, where evidence is available, against the repository, a deployment record, or a live result, and labelled proven, contradicted, incomplete, or not independently verifiable. Reforge is what runs when an owner corrects the record: the correction is treated as the authoritative current intent, the prior work order is examined for exactly what allowed the gap, and a replacement is issued rather than a negotiation.

The most common failure Temper exists to catch is a set of distinct states collapsing into one word: “done.” Code written, committed, pushed, deployed, actually executed, accepted by whatever external provider is involved, and visible to a real person are six different facts, each with its own evidence. A report that blends them reads as more finished than it is. Anvil's standing rule is to require each state separately and to prefer an identifier or an independently checkable result over a narrated description of what supposedly happened.

Each Temper or Reforge pass can produce a lesson worth keeping past the task it came from: a rule about how source priority should be stated, a boundary case a prior work order missed, a pattern of claims that sounded complete but weren't. Those distilled rules go into a small internal learning ledger — rewritten and consolidated over time, not appended to forever. It is deliberately not a transcript archive: it holds the reusable rule, not the raw exchange, the incident detail, or anything that would need to stay private to be safely kept at all. Nothing from that internal record is reproduced here.

What is true today is narrower and more useful than a launch claim would be: three cycles exist and are used daily on real engineering work, and a small ledger of distilled rules is maintained rather than left to be relearned each time. What is not yet true is a measured claim of improvement, an independent audit of the audit itself, or a general theory of what makes an AI work order succeed rather than a working set of rules learned from a small number of cases. This log will be corrected in place, with a dated entry, if any of that changes.