The Trace Is the UI: Evarness Writes Its First Post, and the Interface It Argues For Is a File
Last post, the bench got its name and its first capability graduated. This post is shorter, because the product now does some of its own talking: Evarness has a blog, it lives inside the docs site, and its first post — “The trace is the UI” — makes the design argument behind the render artifacts. This is the personal-side pointer: why the product’s posts live over there, why its interface is a file instead of an app, and what to click to check both claims.
Why the product blogs from inside its own build
A rule I’ve held all series: no “trust me.” So when Evarness needed a place to write about itself, putting that place outside the repo felt wrong — a blog on some separate platform would be a second source of truth about the product, free to drift from what the code actually does. Instead, the posts are pages in the same gated docs build. That means the same machinery that fails the docs build when a demo’s digest drifts also stands behind every post: a post cannot cite a digest the build didn’t just reproduce. A broken link fails the build. The blog inherits the product’s honesty rules, because it has no way to opt out of them.
The division of labor from here: the product’s posts — design arguments, capability introductions — live on its site. The personal arc — why I’m building this, what it cost, where it bends — stays here. Each will point at the other, the way this one does.
The argument, in three beats
The full post is over there and worth the read; here is my personal-voice version of what it argues.
One — no app, on purpose. Evarness ships with two runtime dependencies, because its whole claim is “verify offline, from a wheel you built yourself.” A package.json would contradict that story before the README finished loading. So the “UI” is a generated artifact: one self-contained HTML file — inline SVG, vanilla JavaScript, zero external requests. A file you can email to a reviewer beats an app they must install, because an assurance tool’s real user is the person you’re trying to convince.
Two — the blocked run is the product in one picture. Open the blocked-run demo: the interceptor glows red, and everything downstream — including the model node — stays dim, because it was never reached. “A blocked run never reaches the model” is a contract in the repo; in the artifact it’s something you can see, and then check — the digest in the header recomputes from the canonical events embedded in the file itself.
Three — the island IS the bundle. The proof browser renders a whole proof bundle as one page — and the page embeds the entire bundle in its data island. Extract it, run evarness verify, and the proof re-checks offline, signature included, from the HTML file alone. The file isn’t a report about evidence; it’s a carrier of verifiable evidence. That sentence is the whole design.
And the boundary, stated the way this series always states them: rendering is not verification. The page shows; evarness verify checks. A signed bundle is labeled “signature NOT checked by this page,” because a page vouching for its own integrity would be worth exactly nothing. The artifact obeys the product’s honesty rules — that’s what makes it the product’s interface and not just its poster.
Where to go
- The post: The trace is the UI — the full design argument, including the XSS threat model and why the rendered bytes are pinned under a golden hash like any other regression.
- The demos: the replay, the blocked run, the proof browser — all generated by the product when the site was built, and the build fails if their digests drift.
- The repo: evarness-ai/evarness.
Same rule as always, now enforced by a build instead of my discipline: reproducible, or it didn’t happen. Open the blocked run, watch the model node stay dark, and tell me where the shape bends.