Rebuild from the spec. Keep what passes.

What it is

Most code is kept by editing it. Regenerative software is kept by keeping its specification, and rebuilding the code from it when something changes: the spec, the language, or the model doing the building. The specification is the part that lasts. The implementation is replaceable.

That only works if the specification can be checked before anything is built, and if the rebuild can be judged by something other than the builder. Graft uses duramen for both. A duramen record is one .duramen file, or a folder of them, holding a program's requirements, worked examples, decisions, deliberate gaps, and an executable model of the program (its oracle). duramen check runs every example through the oracle before any build exists, so a typed example that disagrees with its formula is caught at the start. duramen build writes the builder's brief and the test suite from that one record, so the two can't drift apart.

How Graft does it

First, the spec report. Before anything is spent, Graft grades your record. It runs duramen check and, when the record names an oracle, plants mistakes in the oracle (duramen mutate) to see whether the cases catch them. No builder and no model run. The record comes back thin, usable or strong, with the reasons first. A report runs when you connect a spec, when a push changes the record (for a spec that doesn't rebuild on push), and whenever you ask: graft regen report <spec> --refresh, or the Specs tab. Grading a spec is free for up to 20 reports a day; past that, a report you ask for costs $0.10 of agent work (Graft never charges for the ones it starts itself).

1. The brief. In a sandbox that holds a read-only copy of your repository, Graft runs duramen check and duramen build on your record, with duramen pinned to a release. The brief is SPEC.md and DECISIONS.md, plus duramen's description of how an implementation is run and judged.
2. The blind build. A separate Claude session gets the brief and nothing else, and writes the implementation in TypeScript, Python, Rust or Go (Rust and Go with the standard library only). It also writes CHOICES.md: every place the spec left it to decide.
3. The judge. Back in the first kind of sandbox, Graft builds the brief again (it must come out the same). Each build is judged on its own, next to the record, in a copy of your repository with your implementation's folder removed: the record's own suite runs against it with duramen run. A build that passes the suite then meets a hidden holdout: requests generated from the record (300 for each operation, from a seed this rebuild alone uses), which no builder saw, answered by the build and by the oracle. One different answer and the build stays. A request the oracle itself can't answer doesn't count against the build; it's reported, because it's a gap in the record. With two or three builds, duramen agree also compares them with each other and with the oracle.
4. Keep or stay. A rebuild is kept only when duramen run reports every case passing. Only then does it go in your implementation's folder, on a branch, graft/regen/<id>, that waits for you to take it, the way Graft delivers a move. A pull request happens only if you chose one. Anything less stays, with the reason, and nothing changes in your repository.

Rebuilds run when you ask, when a push changes the record (if you turn that on), and when a new model ships (if you turn that on too). Every rebuild gets a signed record: the commit, the duramen release, the brief's hashes, each build's verdict, and what it cost.

The blindness rule

A rebuild means something only if the builder couldn't copy the answer. So the builder's session has no copy of your repository, no token of any kind, and no network at all: its sandbox can't reach GitHub, a package registry, or anything else. It gets three files, the brief and the build instructions, through Anthropic's Files API. Before they go, Graft checks the brief carries no credential, local path or clone address. The record's oracle, its evidence and your current implementation never go to the builder.

When a build is judged, its driver runs with no network, so it can't fetch your implementation or pass work to it. It also runs as a user of its own, which can't read the record or its oracle: the build's driver, its build command and its own tests all start as that user, in its own folder. A Rust or Go build is compiled the same way, offline, before it's judged. The judge fails closed: a sandbox that can't give a build its own user and cut its network judges nothing, and the rebuild isn't kept. The signed record says both, and so does the rebuild's detail in your dashboard and the API.

Blind means the builder wasn't shown the code. It doesn't mean the model never saw similar code in training, and the signed record doesn't claim it.

Where the words don't settle it

Every builder records its choices. Graft compares each passing rebuild's CHOICES.md with the previous passing rebuild of the same record, matching entries by the requirement or open item they cite (or by heading when they cite none), and shows you where they differ. A build that wrote no CHOICES.md Graft could read is compared with nothing. Those are the places where your spec's words leave behavior open. Either that's on purpose, and the spec can say so, or it's a gap, and an example will pin it.

A neutral referee: judging a rebuild again

A verdict is only as good as the judge that gave it. So any finished rebuild can be judged again: its builds, as Graft stored them, run once more on today's runner, at the rebuild's commit, against the brief its builders were given and in the folder the first judge used, by the same rules. The hidden holdout is drawn from a fresh seed unless you ask for the rebuild's own. The re-judge shows each build's verdict beside the first judge's and whether they match, and gets its own signed record. It spends no agent work, delivers nothing and never changes the rebuild it judges. Ask for one from the rebuild's detail in your dashboard, with regen_rejudge, or with POST /api/v1/regen/runs/{id}/rejudge.

How often the judge is fooled

On heat-engine, we planted 133 faults in a passing build: 114 by machine (every operator, condition, boolean and constant in its code) and 19 by hand (boundaries moved a hair, a clamp nudged, a constant rounded, a unit conversion swapped). 130 of them changed its behaviour. Graft's judge, the record's 215 cases plus 1,500 hidden requests, rejected 129: the cases caught 128 and the hidden requests one more. The one it passed is wrong only in the audit text for temperatures above 1,000 °C, which no case covers and 1,500 random requests didn't reach. That is 1 in 130, under 1%, with a 95% upper bound of about 4%. This is one small program; we haven't measured the rate on others yet, and a record with fewer examples will catch less.

The 1 in 130 above is measured for rebuilds; the spec gate's own checks report their false-pass rate as not yet measured.

Results

Every finished rebuild of the specs we publish, as it happened. Nothing here is typed by hand: the table is read from Graft's database each time the page loads.

Finished	Spec	Language	Builder's model	Suite	Outcome	Choices that differ
2026-11-03	duramen-core 0.15.1 github.com/craigm26/duramen: spec	ts	claude-sonnet-5-5	251/251 no holdout: the record draws no requests	Passed: kept $2.52 of agent work	first
2026-11-03	heat-engine 1.5.0-slice github.com/craigm26/duramen: examples/heat-engine/heat.duramen	ts	claude-sonnet-5-5	215/215 + 1500 hidden, agreed	Passed: kept $0.85 of agent work	first

Who it's for

Rebuilds are part of Premium, Team and Enterprise, and spend agent work from your monthly allowance: at most $2 a rebuild by default, split between its builds, or a budget you or your agent set, up to $10. Given a budget the estimate is over, Graft answers with the price and spends nothing. The free plan can't start one, but it can connect the heat-engine example in the dashboard, read its grade and check its weakened record. The spec report is free for up to 20 a day.