Verification
It is checked before you see it
Every build runs a four-stage chain in order. The founder sees the application only after all four pass, and a failure at any stage starts a repair loop rather than producing an error message.
Last updated
| # | Stage | Measured | What it catches |
|---|---|---|---|
| 01 | Typecheck | 4.2s | Every type in the generated application is checked. Catches the largest class of generated-code error — a call that does not match the thing it is calling — before anything is run. |
| 02 | Tests | 4.3s | The scaffold arrives with tests, and generated logic is tested against them. This is the stage that notices behavior changed, not just that the code compiles. |
| 03 | Production build | 24.0s | The application is built the way it will actually run. Plenty of code typechecks and tests cleanly and still fails to build; this stage finds it before you do. |
| 04 | Smoke test | 3.9s | The built application is started and exercised. The question at this stage is the simplest one: does it come up and respond. |
| Total | 37s | Marketing-site scaffold, network-less sandbox. |
Why do the stages run in that order?
Cheapest first. A typecheck takes seconds and rules out the largest class of error, so running it before a 24-second production build saves the build. Each stage is a wider net than the last, and each one is slower — so the order is not stylistic, it is what makes running the whole chain on every build affordable.
The stages also catch genuinely different things. Code that typechecks can fail its tests. Code that passes tests can fail to build. An application that builds can still fail to come up. Skipping any one of them makes the other three misleading.
What is a repair loop?
A repair loop is an automatic cycle that takes a verification failure, feeds the actual error back into generation, and re-runs the chain. It repeats until the build passes or the attempt is abandoned. Nothing reaches the founder mid-loop.
newc0 does not publish a repair success rate on this site. There is an internal engineering target for it, and an internal target is not a product promise. It goes on the claim sheet when it has been measured in a way that can be stated with its scope.
What does 'per-project isolated sandbox' actually mean?
Each project generates inside its own isolated environment, with its own filesystem, and previews run from there. One project cannot see or affect another. Isolation is what makes the verification results meaningful: a build that passes did so on its own, with nothing left over from anything else.
Questions about verification
What happens when verification fails?
- A repair loop starts automatically. The failure — the type error, the failing test, the build output — is fed back and the application is repaired and re-verified. You are not shown a broken build with an error message attached, because a broken build is not a deliverable.
How long does verification take?
- On the marketing-site scaffold, in a network-less sandbox, the full chain measured 37 seconds: typecheck 4.2s, tests 4.3s, production build 24.0s, smoke test 3.9s. That is one scaffold under one set of conditions. A larger application takes longer.
Does the model have access to my files or the internet while it builds?
- No. The model proposes structured file-edit operations and a deterministic executor validates and applies them atomically. The model never touches a filesystem or a network directly, and generation runs inside a per-project isolated sandbox.
Can I go back to a previous version?
- Yes. Builds are immutable and content-hashed, so every version is a fixed, addressable artifact. Rolling back is a pointer change rather than a rebuild, which means it takes effect immediately and cannot partially succeed.