Evidence process notes — why not to trust your own screenshots

Preface

Working alone, the easiest person to fool is yourself: no colleagues, no code review, no QA, and the only person who will ever say "this isn't finished" is you — who happens to be the one least keen to say it. Requesting, building and accepting are three hats on one head, and the last one falls off first.

So on this project "done" is not a feeling; it is a state that has to arrive with evidence. This entry records what that evidence process looks like and what it has actually stopped.

Append, never rewrite

Rule one: accepted evidence cannot be changed. Every formal capture produces a directory — screenshots, logs, performance samples, a file manifest — and once it is sealed the scripts refuse to write into it; new work goes into a new directory, and failed attempts are disclosed rather than deleted.

In practice the rule brings some uncomfortable moments. On 15 July the town-to-town run held for the first time; the acceptance note after the playtest says, roughly, "played it, found nothing wrong" — and the sealed sixteen-item checklist had not one box filled in, so it reads 0/16 to this day. Embarrassing, but rules are rules: the approval is a separate record added later; nobody goes back to turn 0/16 into 16/16 or invents sixteen "observations at the time". It felt excessively strict at first; now it feels like the most valuable rule in the whole process — it records what was actually on the table, not what one later wishes had been reviewed.

Screenshots are not evidence

2026-07-16·Depth of field

The next day brought a proper crash: a post-decision audit found that in an already-approved set of frames, the static captures had a depth-of-field refresh defect — that is, the screenshots used to make the approval were themselves wrong. The set was already approved; the fix was not to edit it but to add a corrected set with its own manifest, leaving the old one untouched byte for byte. That day the attitude to screenshots changed for good: a screenshot is for looking at, not for proving. Proof is the OK line a validator prints, the manifest of hashes, whatever can be recomputed.

Two more failures went into the record the same day. One was an online test under degraded network conditions that ran its full ten minutes while both clients received zero events; the finaliser rejected and scrubbed the run without inventing a cause, because at the time none could be inferred. The other was stranger: a formal test in which both clients exited cleanly, and closure then rejected the whole run over one release acknowledgement file that could not be read. Strong suspicion: macOS had attached an extended attribute to the file late and shifted its timestamp — but strong suspicion is not proof, so only those two files were hardened, minimally (read twice, a little apart, compare every field), and all related tests were re-run. The record keeps "I think this is the cause, so I fixed it this way" and "I proved this is the cause" apart.

Metrics are the pass mark

Rule two: machine metrics are necessary, not sufficient. Every new candidate arrives the same way — a new file, a runtime switch, its own validator, its own evidence directory — and after all the metrics are green, a named human gate still has to be passed before a default may change.

So the repository lives with states like this for long stretches: a lighting scheme with all six metrics in band, performance in budget, evidence complete — and the runtime default still the old one, the new one an opt-in. Passing the metrics and passing the eye are two different things, and the first should not become the second automatically. The guardian statue made that clearest: several thousand checks passed, and the frame read as a length of shrine. The machine checks what it was taught to check.

Rollback ≠ restore

2026-08-10·Tokyo

On 10 August an attempt to restore the Tokyo server to its previous stable version failed — the certificate chain would not verify; the automatic rollback succeeded and the service stayed online. The record has two sentences: "The restore did not succeed. The rollback succeeded." No "therefore" between them. Turning "rollback succeeded" into "the old version was restored" is the laziest self-deception available — it does not even require a lie, only writing two things as one sentence.

The images on this site

By the same logic, a note on this site. Most of the images are labelled re-rendered gameplay captures: they start from in-development in-engine frames and were re-rendered for mood and composition — not raw screenshots, not final quality. A few are labelled in-engine capture, in-development build: straight out of the engine, only downscaled, untouched, like the one below. It is rough in all sorts of ways, and precisely because it was not re-rendered it can prove a few things: this arena exists, these characters exist, the warlord stands behind the gate.

IN-ENGINE CAPTURE · IN-DEVELOPMENT BUILD

Afterword

This way of working is slow: writing validators often takes longer than writing the feature, and every "done" has to run through the chain again before it gets said out loud. But it has genuinely stopped things — a misoriented candidate chain caught by a probe before the expensive formal capture; an online run with zero events rejected rather than explained away; a flawed set of screenshots corrected by addition rather than rewritten; a Tokyo restore recorded as the failure it was. In a process that only records successes, every one of those would have vanished.

What it buys is the scarcest thing for one person working alone: a conclusion written down five weeks ago can still be trusted. The game is still being made; this entry is not about what it has achieved, but about how one knows how far it has got.