Work / Colophon

How this site was made

Every screenshot is a real capture of the software running. No mockups, no redraws, and no caption the build cannot prove.

The problem with screenshots

A portfolio screenshot is a claim, and claims drift. You capture a screen, write a caption about it, then recapture later and the caption quietly stops matching. I did exactly this: a caption here once read “the answer arrives as a card” against a frame containing no card. It had been true when written.

So the captures are produced by a pipeline, and the pipeline treats a caption as a claim that has to be backed.

What each frame carries

Each step declares in advance the literal thing that must be on screen for its caption to hold. The driver waits for it, records what it actually matched, and only then takes the picture. A step whose expectation never appears fails the capture instead of producing a screenshot.

{
  "shot":     "pointing",
  "evidence": "Confident (Google baseline)",
  "attempts": 1
}

attempts matters. Some of these projects drive a language model, and models vary. Where a step had to be retried the count is recorded rather than hidden, so the artifact says how reliably the behaviour actually showed up. Of 33 frames on this site, 1 needed more than one attempt.

What the build refuses

• A step with no evidence that its caption holds.
• Two frames that are byte-identical — an interaction that did nothing.
• A caption that is empty, or a step whose image is missing.
• A capture started against a port already in use, or a server that does not identify itself as the intended project. Both would screenshot the wrong application under the right name.
• Anything secret-shaped inside an embedded build, and any asset path that works on a case-insensitive filesystem but not on the server.

A separate check renders every page at four widths and fails on images that did not load, aspect ratios that drifted, or horizontal overflow — because the artifact checks all passed once while the page was visibly broken.

Two kinds of “live”

2 of these case studies run in the page rather than being photographed. One is the project’s own build, executing. The other is output the project generated ahead of time, browsed through a shell written for this site. Those are different claims, so they are labelled differently.

Where it is honest about failing

The AIPointerRemix case study shows one half of a comparison it exists to make. Capturing the other half needs a person to speak the same question twice, and three scripted attempts failed. The caption says so rather than describing an answer that is not in the frame.

How the confidence markers are decided

Every factual line that matters carries one of three states. The state is not an opinion about the work; it records how much of the claim has been observed rather than assumed, and it is read from a written verification log kept alongside the source.

• Confident Confident — observed running, or publicly shipped and captured for this site.
• Partial Partial — some of the claim observed; the rest is self-reported, or the software was not run end to end.
• Unverified Unverified — asserted only. Nothing on the site currently sits here, and the build makes any claim without a record default to it.

Hover a marker for the reason. On load, every marker starts grey and resolves to its state in under a second: the site is making the same move it argues an AI interface should make.

Built with Astro and Puppeteer. Captures are WebP; the whole site is under 3 MB. Source available on request.