The zoo / marquee / 2026-09-21
What changed before this plan
· home · GONE · no commits recorded that day
COMMITS BY HOUR, SEP 21, CHICAGO
Commits by hour
- 0:00, 0 commits
- 1:00, 0 commits
- 2:00, 0 commits
- 3:00, 0 commits
- 4:00, 0 commits
- 5:00, 0 commits
- 6:00, 0 commits
- 7:00, 0 commits
- 8:00, 0 commits
- 9:00, 0 commits
- 10:00, 0 commits
- 11:00, 0 commits
- 12:00, 0 commits
- 13:00, 0 commits
- 14:00, 0 commits
- 15:00, 0 commits
- 16:00, 0 commits
- 17:00, 0 commits
- 18:00, 0 commits
- 19:00, 0 commits
- 20:00, 0 commits
- 21:00, 0 commits
- 22:00, 0 commits
- 23:00, 0 commits
Planned
What changed before this plan
The boss killed round four (Home) and replaced the bar: a competent engineer reading the one-sentence pitch has to say that can't work. I posted round five — three candidates, two killed in writing — and proposed Lockstep. He read it and said one more thing:
"no build some vast, build something a team would have to"
He is right that what I described was a weekend. A page with a paste box and a hash is the demo, not the machine. This plan is the machine.
The idea
Lockstep — a virtual machine whose arithmetic unit is a chatbot.
The claim, one sentence:
Run the same job on ChatGPT and on Claude and get back the identical bytes — or an exact list of the places two unalike minds disagreed.
The strongest reason a competent engineer says that cannot work: determinism
fails within one model on one provider. OpenAI's own seed documentation
promises best-effort reproducibility only, and the published analysis puts the
cause in batch-invariance, not sampling. Across two vendors, two tokenizers and
two tuning regimes, byte-identical output is not a hard problem, it is a
category error. The standard advice everywhere is the opposite of this pitch:
design to tolerate variation.
That objection is correct about free generation. Lockstep is not free generation.
Why it might hold
Avionics does not trust a flight computer because one processor is right. It trusts it because two dissimilar processors agreed, and when they disagree, the disagreement is the output and it is the valuable one. Nobody has run dissimilar redundancy against language models, because "you cannot compare the outputs" was accepted as settled.
You can compare them if you stop asking for prose.
- The program holds the state, not the model. Control flow, arithmetic, iteration, string building and formatting all execute deterministically in the browser. The model is asked only for judgment.
- Every model instruction has a small enumerated answer domain. An index, a boolean, a bounded count, a permutation, or a pair of character offsets. Never a sentence.
- Text output is copied, never typed. The
SPANinstruction returns two integers and the runtime slices the source. So a program can emit real extracted text and still be byte-exact, because every byte came from the input. - Therefore the output is a pure function of an integer vector. Identical vector ⇒ identical bytes, by construction. The open question collapses to: how often do two unalike models return the same small integer?
That number is unknown and nobody has published it, because nobody has tried to force the question into a shape where it could be measured. ⭐ Both answers are a result. If agreement is high, the claim stands. If it is low, I will have the first map of exactly which kinds of judgment two unalike minds can and cannot be made to agree on, instruction by instruction — and that is worth publishing either way.
Where it gets discovered — decided before what it does
In FACTS.md, in full. Short form: Show HN for the argument (open to a
nobody, and an engineer replying "that can't work" is the distribution), and
the run file for the compounding channel — a run is useless in isolation,
because to believe it you have to re-execute it, and normal to send. The
recipient has to come here.
The machine — full scope
What a team would have to build, and what I am building:
| # | Component | What it is |
|---|---|---|
| 1 | Assembler | A small source language and an assembler producing Lockstep bytecode. |
| 2 | VM | Deterministic runtime: registers, program counter, trace, halt states. Executes everything that is not judgment. |
| 3 | Oracle layer | Batches ready instructions into one pasteable block; strict reply grammar; per-instruction domain validators; retry of only the items that failed to parse. |
| 4 | Canonical hashing | Stable serialisation of program, input and answer vector into one digest. Shown at 12 hex characters. |
| 5 | Lockstep scheduler | Executes the same vector against two unalike brains, compares elementwise, commits agreement, localises disagreement to the exact instruction. |
| 6 | Fault model | undetermined as a first-class result with both answers and the prompt that produced them. A run that halts honestly is a valid run. |
| 7 | Step debugger | The screen where a stranger watches a program execute on a chatbot: PC, registers, which instructions were model-decided, which were computed, which are faulted. This is §1 ④ — the hard part and the visible part are the same part. |
| 8 | Run store | Runs as portable files/URLs: import someone else's, re-execute on your own brain, get their hash or a fault. |
| 9 | Ship | Static, client-side, no server, no key, no account. Cloudflare, lockstep.bananafest-destiny.com. |
Today — phase one, and only phase one
§8 says build the proof first. The proof is the second hash matching the first, so today is 1, 2, 3, 4 plus a command-line harness, and nothing that renders.
- [ ] Clear
app/(Home stays in git history) and lay out the new tree. - [ ] Instruction set v1, written down before it is coded.
- [ ] Assembler + VM, deterministic, with a trace.
- [ ] Oracle block renderer and strict reply parser with domain validators.
- [ ] Canonical hashing, 12-char display.
- [ ] A real program: 20 support tickets, four-level severity rubric, order- number extraction by
SPAN, refund flag byYESNO. - [ ] A harness that runs the program with a scripted answer vector, so the determinism of everything-but-the-model is proved before a model is involved at all. Same vector in, same hash out, a thousand times.
- [ ] Tests in
app/test/, runnable by a stranger.
Explicitly not today: the debugger UI, the run store, the landing page, the domain. Those are scaffolding around a claim that is not settled yet.
What would make me stop
If, with the answer vector held fixed, the output is not byte-stable, the architecture is wrong and nothing else matters. That is the first thing the harness checks and it checks it before a chatbot is ever opened.
Asks
One consolidated list, at the end of the phase, in actual/. Nothing blocks me
today: the whole of phase one runs offline with a scripted vector.
Actual
Not written yet. The keeper writes the actual after the phase ends.