How It Works · Six Design Commitments
How it works: six design commitments
Six mechanisms were presented at the final. This section explains, one by one, how each is actually done in code: the foot of every card names the script that implements it and the run evidence on this page you can open to check it.
Models propose, code decidesModels only nominate candidates, raise objections and write prose. Arithmetic, gate decisions and hash checks are all done by deterministic scripts; the model never touches the result. When something goes wrong, it can be traced back to a specific line of code rather than to a conversation.
01A complete iteration loop
The main line is nine steps and three gates: can a source come in, do units and coordinates pass QC, and does every item pass acceptance. Whatever fails goes into the repair loop; the bar is never lowered to let it through.
The repair loop has five steps, shown below. Every repair is a new run, and earlier evidence files are never rewritten. Problems that genuinely cannot be fixed are flagged needs_human_review and handed to a person instead of being patched with a made-up number. The whole chain can be driven by autopilot.py in one command, which ends in one of four machine-readable states: DONE / CONTINUE_REQUIRED / NEEDS_HUMAN_REVIEW / FAILED.
list the problems→log to backlog→fix by registered method→re-run & re-accept→write to cross-run memory
02Three-layer adversarial mechanism
Adversaries sit at two points: where data comes in, and where results go out. The third layer is a graded verdict that decides whether a problem sends the work back, narrows its scope, or lets it through.
At the entrance there is a three-party duel: one model acts as the scout and nominates new data sources; a second model acts as the skeptic and may only raise problems, never score; the scoring is done by code against a fixed scoreboard — 7 points or more proceeds to onboarding, 4 to 6 is sent back for revision, below 4 is out. At the exit there is an output audit: the audit script first copies the outputs into a shadow copy, plants 10 known defect types in it (altered values, flipped units, fabricated sources, corrupted hashes and so on) and sits the exam itself. Only if it catches all 10 does its verdict on the real outputs count; miss one and the verdict is void. The verdict has three grades, pass / pass_scope_narrowed / fail: a warning does not kill the draft, but the affected numbers may only be quoted together with their scope.
03Each evaluation round stays independent
A round must be reviewed without being influenced by the previous round’s conclusions. This is written into a machine-readable reviewer contract, not left to convention.
The contract requires the skeptic to come from a different model family than the executor, to work in a brand-new thread, to see none of the executor’s explanations, and to read only the output files themselves; if a path or SHA-256 in the briefing does not match, it must refuse to review. As for cross-run memory (memory.json), it records only how often each source has succeeded or failed before, and its sole effect is the order in which round 1 tries sources: it cannot add a source and takes part in no decision. Evidence gathered in the current run always outranks memory from earlier ones.
04SHA-256 fingerprints, one per result
Hashes are taken in four places: the task request itself, every downloaded source file, the 18 output files, and every number in the final answer.
The request is hashed before work starts, so a goal that drifts midway shows up; source files must pass a registered hash check before ingestion; run_summary.json records the hash of each of the 18 outputs. The last layer is the claim ledger: claim_ledger.py lists every number in the outputs that could be quoted in an answer and binds each one to a file, a JSON pointer and a hash, recomputing all of it on every call so the executor cannot edit it. Once the answer is drafted, --check-answer compares it against the ledger; a number that does not match is treated as a phantom and may not be published. Inside the atlas, any point can likewise be followed down to its DOI, the row of the original table and the hash.
05Temporal evolution lives inside the atlas
Temporal evolution is not a separate deliverable. It is a view inside the atlas: switch to it and it is there, running on the same standardized database.
For sources with reliable sampling dates, the atlas can play year by year from 1986 to 2024, which helps tell whether a high value has always been the geological background or appeared later as an external input. Because it uses the same data, the evidence chain and the scientific boundaries of the main view hold in the temporal view too; there is no second set of accounting to maintain.
06Auto-research genuinely wired in
Once the atlas is built and has passed validation, you can choose to take one more step into research mode. The step is optional, and it is really connected — not a sentence in the documentation.
build_research_products.py collects no new data and changes no core output. It only reorganizes the existing evidence into three things a researcher can use directly: which records may be compared with one another (analysis cohorts), the lithology, depositional setting and other context of every sample (research context), and where to sample next (sampling priorities), with a receipt stating the input hashes and parameters. Research mode then continues on top of these three with statistical tests, writing and typesetting. The five papers further down this page were produced exactly this way.
