Overview · Written article

How-to recipes

Narrow single-task answers. "I want to X" — each one is a few commands and the reason the order matters.

This page is written, not generated. Everything else on this site is a document from the repositories rendered as it is written. This one is prose about code — so every citation and every quoted block in it is resolved against the real file at the real commit when the site is built, and a citation that no longer resolves fails the build rather than becoming a stale line number nobody notices.

Three ways to read this page. Precise is the document itself, exactly as it is written in the repository. Plain and Clear were written for this website to help you meet that document — they are about it. They are not it, and they are not evidence.

These 13 pages are the only ones on this site written for this site. Everything else you can read here is a real file from a working repository, republished as it stands. These were written by hand for someone arriving with no context: an entry point, one article for each major part of the estate, and a set of practical guides for installing, running and maintaining things.

They carry one unusual discipline. Every citation in them points at a real file at a named commit, and the build resolves it there. If the file has moved, or a quoted range has run off the end of it, the build fails. It will not publish a reference that no longer lands. The wording of an article can drift out of date; what it points at cannot silently do so.

Start with "Start here". It is short, and it explains the one idea the rest of the estate is arranged around. After that, read whichever part you care about, or go to the quick start if you would rather run something than read about it.

What they are not: authoritative. An article is prose about documents, and the documents are the record. Where the two disagree, the document is right and the article is the thing to fix.

PlainClearPrecise

Your browser cannot switch reading levels, so the document itself is shown.

This is the article as written. Every citation and quoted block in it is resolved against the real file at the real commit when the site is built.

PARTLY RUNNABLE BY YOU. Each recipe states its own requirement. About half run on any machine.

Task-titled, deliberately short, and each one ends with how you know it worked. If a recipe cannot be run without infrastructure you may not have, it says so in its first line rather than its last.

I want to see the engine do something in five minutes

Any machine. → Quick start. Compile, test, run the demo, record a run, verify it, then tamper with the recording and watch the verification fail.

I want to check whether anything here is actually true right now

Any machine.

node viewer/gate_runner.cjs

That is the honest answer to "does it work". It runs the registered checks and reports each one. Three of the 32 are listed but never run because they need hardware — they show as not-run rather than silently passing, which is the difference between a gate and a decoration.

I want to verify a recorded run independently

Any machine. Record, then verify the file you just wrote:

mix run scripts/record_run.exs 314 morphology_seeking 120

mix sp.verify runs/seed314-morphology_seeking.jsonl

Then break it deliberately. Edit one number in the middle of the run file and verify again. If it still passes, the verifier is decorative and you have learned something more valuable than a green tick.

I want to know whether a change altered the engine's behaviour

Any machine. Regenerate the golden artifact and ask git:

mix run scripts/gen_golden.exs

git diff --exit-code config/golden/

Silence means byte-for-byte identical. Output means the behaviour moved, and somebody has to say whether that was intended. This pair runs in continuous integration for exactly that reason — "improvement" and "regression" produce the same diff and only a human can label it.

I want to test whether a sense is actually being used

Needs Minecraft. Run the same agent blind and seen, with the same seed:

mix uni.play

Pass --visibility blind and then --visibility seen, holding --seed fixed. If the behaviour does not change, that sense was not being used — regardless of what the architecture diagram says. Ablation is the cheapest falsifier in this estate and the most frequently skipped.

I want to add a scene to the studio

Needs the studio. Edit the scene table in the builder, add the scene to the group table and the description table, then rebuild:

node viewer/studio_stage.cjs

Adding a scene without adding it to a group is how the estate acquired a scene that cannot be previewed and is reachable only by cutting it straight to air. The builder refuses to run while streaming unless forced, and it is a full teardown-and-rebuild, not a patch.

I want to prove the overlays are really on screen

Needs the studio.

node viewer/verify_overlays.cjs

A running overlay server is not proof of overlays. This checks the current program scene against the overlays that scene declares, and writes a real screenshot. No agent may claim overlays are up without it.

I want to check the show is possible before running it

Any machine — it reads files, it does not need the studio.

node production/run-of-show/verify_rundown.cjs

Six checks: the show is non-empty, every scene it names exists, no row names an unpreviewable scene, every caption passes the claim fence, the clock closes to 240 minutes both by arithmetic and by the file's own declaration, and no row can start a stream. It cannot tell you whether the show is good. It can tell you whether it is possible.

I want to add a new check to the estate

Any machine. Write it, then register it. The runner asserts its own registry is complete, so an unregistered check file fails the runner rather than being quietly skipped.

Then do the part most people skip: prove it can fail. Introduce the defect it exists to catch and require it to go red. A check that has never been shown to fail is not evidence of anything, and this estate treats mutation-proving as part of writing the check rather than as a later luxury.

I want to reproduce the observed motor experiment

Needs a dataset that is not redistributed. In this order:

npm run experiment:ingest

npm run experiment:run

npm run experiment:verify

The ingest step takes a .mat file from a published study which you must obtain yourself. Without it the correct outcome is a gate marked BLOCKED, never a pass. Reporting a pass for a stage whose input was absent is the exact failure the estate's contract names.

I want to bring the whole studio up

Needs the studio. Set an OBS WebSocket password first — see the broadcast suite — then:

powershell -File viewer/studio_up.ps1

It is idempotent, health-gated at every step, and holds an OS mutex so only one bring-up can run at a time. Never launch or force-kill OBS by hand: a force-kill leaves a crash sentinel and the next start comes up in safe mode with the control socket disabled.

I want the operator surfaces to come back after a reboot

Windows. Install the startup entry, then prove it — they are two different claims:

powershell -File viewer/track/track_boot_install.ps1

powershell -File viewer/door_boot_proof.ps1

The prover reports PROVEN only if the machine actually rebooted after the install marker was written. Installing a startup entry is not evidence that it fired.

I want to know what this project is not claiming

Any machine, no software. → What is not here for every withheld document and its reason, and the closing section of every article on this site. Each one ends by saying what it does not establish, and those sections are load-bearing rather than modest.

The shortest version: passing gates are not biological parity, general intelligence or human parity; a reconstruction is never relabelled as an observation; and a prediction counts as prospective only if it was committed before the observation it predicts.

Written for this website — not the document. This is a plain-language retelling, written to help you meet the document. It is not the source, and it is not evidence. It has not yet been checked by a person. Read the document itself → (or choose Precise in the reading-level control above)

Each recipe here answers one narrow "I want to..." question with a few commands and the reason the order matters. About half of them run on any machine, and each one states what it needs in its first line rather than leaving you to find out at the end.

They cover seeing the engine do something quickly, finding out what is actually true right now, and verifying a recorded run and then breaking it deliberately. They cover checking whether a change altered behaviour, testing whether a sense is really being used, and adding a scene to the studio. They also cover proving the overlays are on screen, checking the show is possible, and adding a new check and then proving it can fail. And they cover reproducing the motor experiment, bringing the studio up, making the operator surfaces survive a reboot, and finding out what the project is not claiming.

One of them stops at a wall and says so. Reproducing the motor experiment needs data nobody outside can have, so the honest outcome there is a check marked blocked rather than a pass.

Each recipe ends with how you would know it worked.

Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 8e73ab7b226f7132

Written for this website — not the document. This is a clearer retelling, written to help you meet the document. It is not the source, and it is not evidence. It has not yet been checked by a person. Read the document itself → (or choose Precise in the reading-level control above)

This is the recipe page: narrow, task-titled answers, each a few commands with the reason the order matters. About half run on any machine, and every recipe states its requirement in its first line rather than its last, so you learn what you need before you spend an evening on it.

Several of the recipes are the same lesson in different clothes. Verify a recorded run, then edit one number in the middle and verify again — if it still passes, the verifier is decorative, and you have learned something more valuable than a green tick. Add a new check to the estate, then prove it can fail by introducing the defect it exists to catch. A check never shown to fail is not evidence of anything, so proving it is treated as part of writing it rather than as a later luxury. Run the same agent blind and seen with the same seed: if the behaviour does not change, that sense was not being used, whatever the architecture diagram says. That is described here as the cheapest way to show a claim wrong in the estate, and the most frequently skipped.

Others are operational. Regenerate the recorded reference and ask the version-control system whether anything moved, since an improvement and a regression produce the same difference and only a human can label it. Add a scene to the studio, remembering the tables that must be updated together — the page notes that forgetting one is how the estate acquired a scene reachable only by cutting it straight to air. Prove the overlays are really on screen, because a running overlay server is not proof of overlays. Check the show is possible before running it, which the page carefully distinguishes from checking whether it is good. Bring the whole studio up, with a warning never to launch or force-kill the studio software by hand.

Two recipes carry hard limits. Reproducing the motor experiment needs a dataset that is not redistributed, and without it the correct outcome is a check marked blocked rather than a pass. Making the operator surfaces come back after a reboot is two claims rather than one: install the startup entry, then prove it, because installing is not evidence that it fired.

The last recipe needs no software at all. It points at the page listing everything withheld and its reason, and at the closing section of every article on the site. The shortest version is this. Passing checks are not biological parity, general intelligence or human parity. A reconstruction is never relabelled as an observation. And a prediction counts as looking forward only if it was committed before the observation it predicts.

Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 8e73ab7b226f7132