The specification: what each move is fixed to do, whatever the study

Where and how flows form — the machine's own contract for each of the nine moves, general to any programme on the shelf.

Source: programmes/intent.yaml, programmes/blueprints-reader.yaml, spec/ADR-004-playground-demo-stand.md (d27), lib/API.md.

§Move 1–2 — the door, fixed regardless of what the study is

Every session, whatever it will become, begins from the identical two-record figure: one listener waiting for the person's opening words, one doer that asks the world to choose, from an enumerated list, the shelf entry closest to what was written — never a free-form choice, always constrained to a declared schema naming every option by name. Whichever programme wins, the same loader sows it the same way, stamping every record it adds with the choosing intention's own id. Nothing about moves 1 and 2 knows or cares what programme is on the shelf; they are, deliberately, the one part of the whole arc that is identical across every study this system could ever run.

§Move 3 — decomposition, declared once, at authoring time

A study's own decomposition into questions is nothing more than however many vector-shaped listeners its programme declares — each one waiting for a person's question (discriminated so it cannot be confused with any other question) and, from birth, a declared return socket (2.3) naming exactly where a delegated answer must land. This is fixed at the moment the programme is written, not chosen live — a study's shape is visible in full the instant its records are sown, before a single question has actually been typed.

§Move 4 — delegation, the same two-ingest act every time

Opening a reader for any one of a study's questions is, without exception, the same act: an admission ceremony first, a return figure sown only once that ceremony's own receipt confirms success. No study on the shelf has its own separate version of this — every delegated question in every programme goes through this identical two-step act.

§Move 5 — the reader's fixed brief

A reader seat's brief — what 7.3 called the Charter — is declared once, on the shelf, and reused unchanged for every question a study asks through it. The press-reader seat's own instruction and schema, quoted in full because it is the exact vocabulary behind every "declared / happened / unclear" tag anywhere in this book:

"You are an analyst reading a company press release. The material is the release (and any attached text); the question names the vector of interest. Extract findings for that vector only. For each finding mark status declared (the company says it will, plans, positions) or happened (a completed, dated, quantified or signed event) or unclear, and quote the sentence that is the evidence. Do not add facts the material does not contain. Summarise what is established versus what is declared."

{ "findings": [ { "claim": "string", "status": "declared | happened | unclear", "evidence": "string" } ], "summary": "string" }

Every reader seat on the shelf carries its own instruction and its own schema in exactly this shape — the content of the brief changes from seat to seat; the fact that a brief exists, fixed, and a structured schema constrains the answer does not.

§Move 6 — the fixed lifecycle, covered in full elsewhere

A Cell's confirmation or refusal follows the identical lifecycle whatever the reader's brief was: running → awaiting_assessment → ready_for_review → sealed | archived, with the human's own cell.reviewed decision the only door into either terminal — set out completely in 7.3, and not repeated here because nothing about it varies by study.

§Move 7 — return and release, fixed by two rails at once

An accepted finding's journey back into the study is rails 5 and 4 acting together, exactly as described in Part 2: the declared socket receives it, and the study's own vector bind — a plain local action, release@1 — writes it out as one ledger entry, {question, findings}, the instant both halves of its own condition are present.

§Move 8 — the barrier, sized to the study's own decomposition

A study's synthesis step demands exactly as many things as the study declared questions in move 3 — four, for the worked example in 4.5; however many a different programme's own decomposition calls for, in general. The barrier mechanism itself (2.1) does not know or care about the number; it simply will not fire until every one of its declared demands has been satisfied at least once.

§Move 9 — the document, built from facts the person chose to place

The final arrangement is the companion technical reference's own subject in full detail; the fixed contract behind it is short: placing anything onto the study's working document is one committed fact (sheet.pinned, naming what to place and nothing else), removing something is the same fact's opposite, and the document itself is never anything but a fold of exactly those facts, replayed from the log — never a separate, editable page living only in a browser.