§ 04 · Specimens Mochi

Mochi is the lab's coding studio, the architecture turned on the one vertical with the hardest answer key of all, where a change compiles or it does not, the tests pass or they fail, and the machine, not a model, has the last word.

Overview

Mochi is built for one job: producing a software change correct enough to ship without a human re-checking the mechanics. You state a change; one model authors the candidate; the candidate is run through the executable verifier, the build, the typechecker, the linter, the tests, and then through critics drawn from families that fail in a different shape than the author; a single concrete refutation sends the work back, and absent one, it ships.

Coding is the vertical because software has the hardest executable ground truth of any domain the lab works in. It compiles or it does not. The tests pass or they fail. It runs or it throws. The answer key is free, so the thesis the lab already runs in procurement meets the vertical where it is strongest.

It is not a public product yet. It is the lab’s coding studio, near-shipping and due to launch in August 2026: running on the bench today, headed for our own operations.

The thesis, applied to code

For code, ground truth is not a matter of opinion, and it is not a verdict a larger model stamps on a smaller one. It is whether the artifact runs. The compiler accepts it or rejects it. The typechecker is satisfied or it is not. The suite passes or it fails. Each is a binary the machine produces, not a judgement a model produces, and that is the structural gift of this vertical: the verifier does not have to be trusted, because it is not a model. It is the compiler. So the lab’s rule, that every critical artifact is checked against executable ground truth before it ships, costs almost nothing to enforce here, and admits no argument. A change that does not build, or that breaks a test, does not ship, however plausible it reads.

There is a known wrinkle. A clean build and a green suite are necessary, not sufficient: a test can pass vacuously, or cover a line without exercising its behavior. So the executable verifier is the floor, not the ceiling. It catches what no model catches, and the critic layer sits above it precisely for the class of wrong that still compiles.

A single model is not generically unreliable. It is unreliable in a specific, structural way, set by how it was built, and that makes its mistakes predictable: a model does not occasionally lose the thread of a long file, it loses it the same way every time. So Mochi routes across families that fail in different shapes, because the mistake one family is built to make is the mistake another is positioned to catch.

Fig. 1 · Four ways a model fails, and why one reviewer is not enough

Choose a failure family to see how it shows up in code

Drops the long tail

It commits hard to the loud part of the request and quietly omits the quiet one: an edge-case branch, a less prominent parameter, a stated constraint that was not the most prominent line.

type use

Loses long context

It contradicts something established far earlier, a type, a prior decision, an invariant, and reads as fluent and sure while doing it. The detail is not wrong on the page; it is wrong against the page four hundred lines up.

let x = ... let x = ... !

Forgets earlier work

It re-declares a name that already exists, re-introduces a helper it already wrote, or contradicts an invariant whose context has faded below the threshold where it can still see it.

required EPERM produced error

Averages to generic

It is correct in shape but reaches for the plausible norm and misses the one sharp requirement: the exact error code, the precise contract, the one-off rule that was the whole point.

Figure 1. Each failure is structural, not occasional: a model prone to one of these is prone to it every time. That predictability is what makes cross-family review work. A reviewer drawn from a different family is positioned to see exactly what the author is built to miss.

A critic built on the same family as the author shares the author’s blind spot by construction, and tends to read straight past it. So the critic is drawn from a different family, and it is kept cold: it never sees the author’s reasoning, only the task and the finished artifact, because showing it the reasoning would anchor it toward agreement, and agreement is the cheap outcome the design exists to avoid. Its mandate is adversarial: find why this is wrong, and if you cannot, say so plainly. Disagreement is never resolved by a vote. Either a critic produces a concrete, checkable refutation, a failing test, a cited contradiction, a violated invariant, which blocks the work, or the work ships.

How it works

The path a single change takes, from the task arriving to an accepted change shipping. Select a stage to see what it does and exactly how far along it is.

Fig. 2 · One coding change, from candidate to ship

◷ built and wired · not yet on our operations

Every input is screened before it reaches routing or building, so nothing unvetted reaches the model that authors the change.

◷ built and wired · not yet on our operations

The task is classified and routed across families that fail in different shapes, so a path that fails one way falls through to one that fails differently.

◷ built and wired · not yet on our operations

Exactly one model authors the candidate change. Never fused, never merged: a single author, so there is a single thing to check.

◷ built and wired · not yet on our operations · the verifier is the compiler, not a model

The candidate is checked against build, typecheck, lint, and tests, binary outcomes the machine produces, not a model. This is the cheap, unarguable floor: it is built to catch what no model catches, and it is why coding is the vertical.

◷ built and wired · not yet on our operations

Critics from a different family than the author, each kept cold, given the artifact and the task but never the author's reasoning, and told to find why it is wrong.

◷ built and wired · not yet on our operations

One concrete, checkable refutation blocks the change; absent one, it ships. Disagreement is never settled by a vote, only by a reason that can be checked.

◷ the record spine runs today on a live specimen · Mochi's traffic is not yet feeding it

The accepted change ships, and the decision is kept as a triple: the prompt, the action taken, the outcome. That record is what a later loop learns from.

  • the coding studio, near-shipping
  • executable ground truth, the floor
Figure 2. The lab's shared machinery already runs today on a live specimen: the verification-against-ground-truth rule, the cold-critic protocol, the refute-gate, the record spine. What is near-shipping is Mochi running that machinery as a coding studio on our own operations, so every stage is drawn dashed. The executable floor, gold, is the check the machine settles, not a model.

The rule is verification against ground truth, never a vote. A claim that can be checked is checked, and for code the check is unusually clean, because the refutation can be a test that fails. Where a model’s word is the only thing on offer, the cold critic earns its place: a reviewer from a different family, denied the author’s reasoning, has to produce a concrete reason to hold or block. Vague disagreement never counts.

What runs today

Mochi is near-shipping, and the line between what runs and what is only built is worth drawing exactly. That line is the whole honesty of this page.

Fig. 3 · What runs today, and what does not

  1. Live

    Runs on our own operations today

    The shared architecture: verification against ground truth, the cold-critic protocol, the refute-gate, the record spine, the cost accounting. Proven by one live specimen doing a real job every day, with a founder's sign-off on anything that leaves the building. Mochi is built on this.

  2. Coming

    Built and wired, not yet on our operations

    Mochi itself: the input screen, the router, the single author, the executable verifier, the cold critics, the refute-gate, the runner, and the record capture, all real code on one path and covered by tests. The gate to live is deploying the serving layer and finishing the frontend, not new research.

  3. Designed

    Not yet running

    The self-improvement loop, in three layers: re-estimating how well each pair of families catches the other's errors; a router that promotes the choices the record rewards; an orchestrator that learns to plan the routing itself. Each waits on the one below it, and the record that would train them is being captured now.

Figure 3. Near-shipping names the middle rung. Mochi's brain is built and wired; its hands, the serving layer and the finished frontend, and its memory, the closed self-improvement loop, are the work in progress the word points to. Nothing on this page claims it is today.

What near-shipping means, in one line: the backend is complete and prompt-stable, and what stands between the studio and live is deploying the serving layer and finishing the frontend, not new research. It is weeks of engineering, not quarters of speculation, but it is not today, and nothing here says it is.

Mochi is closed source. There is no public artifact, demo, or repository a reader could inspect without us at this stage, and the lab does not invent one. What the site can honestly point to is the architecture, stated plainly, and the one specimen that runs it today on a real job. An outside demonstration, or a measurement taken by someone who is not us, is itself a planned milestone: coming, not live, and this page says so.

The bet

The unit Mochi prices is the accepted outcome, a change that ships, not the token. Tokens are the input; the shipped, verified change is the output, and in code the two diverge sharply.

An unverified change is cheap on the token and expensive on everything else. If it is wrong, the cost does not appear at generation; it appears later, deferred into review time, into debugging, into the regression it introduces, into the incident it causes under a user. A model that authors fluently can ship a change that reads as correct, compiles, and is wrong, and the wrongness is quiet: it looks exactly like a correct answer until it breaks.

Fig. 4 · Where the cost of a change actually lands

One unverified call

cheap to make paid again, later

Verified work

paid once, up front
Figure 4. Shape, not measurement: nothing here is to scale, and the figure claims when a cost lands, not how large it is. The unverified call is cheap to make and paid for repeatedly afterward, in review, in debugging, in the regression, in the incident. Verified work is paid once, up front, for the gate and the critics, and ships only what survives. For code that up-front cost is unusually low, because the answer key, the build and the test suite, already exists.

A verified change costs more compute up front, because it pays for the executable gate and the cross-family critics to run. But it ships only accepted work, and on this vertical the verification leg is unusually cheap, because the ground truth is free: the build and the suite are already there. The architecture that is built to catch more of these errors does not pay a proportional premium to do it; it pays for the outcome, and the outcome is the only unit the lab counts.

What you pay for

Because the unit is the accepted outcome, the charge follows it in two plain layers, and there is one ending that costs nothing at all. Select how a change ends to see what it costs.

Fig. 5 · What a change costs you, by how it ends

Select how a change ends to see what it costs

you pay nothing

The build never ran, the tests never ran, nothing verifiable was produced. That compute is the studio's cost to bear, not yours.

you pay the floor

The change ran through the gate and the critics, so real, verified compute was spent, even if the result was not the one you wanted. You pay that floor, and no margin.

you pay the floor, plus a margin

The change passed verification and you accepted it. On top of the floor sits a margin, and that is the only place the studio makes anything.

Figure 5. You pay for verified work, never for a crash, and a margin only on a result you accept. The architecture is built to make a crash that produces nothing rare, which is what keeps most work in the paid, verified range.

The bet is one sentence, and it needs no number to be true: verified work on this vertical beats one unverified call to any single model. The release is the demonstration. Nothing is claimed before it ships. This page grows as it does: what held up, and what did not.