Module 3 · Planning, Context & Multi-agent Systems · scripted
The Scientist and the Designer
One loop, two spaces
The Explorer finds what exists. The next archetype answers a different kind of question — why is this happening? or what should we build? — where the answer doesn't sit in any file waiting to be found. It must be proposed, and then tested. The shape:
The propose–test loop
The division of labor
The MIND guesses. The MACHINE grades. Proposing takes judgment — imagination constrained by knowledge. Testing must be exact — a simulator, a query, a measurement, run by code with no opinions. This is the verification asymmetry, made into an architecture: generation needs a mind; checking needs a rule.
Classification first: this is a single-conversation archetype. The proposing and interpreting accumulate on one wall — the hypotheses, the evidence, the shrinking space are one trajectory — while the tests themselves run outside it, as tools.
One loop — but it comes in two faces, depending on what space the mind is searching. The Scientist searches explanation space: which story about the world is true? The Designer searches configuration space: which buildable thing meets the constraints? Same skeleton, different destination — and the differences are exactly where the design decisions live.
The Scientist: searching explanations
You have the following tools available for use:
- query_readings( sensor, range )
- query_logs( system, range )
- get_weather( station, range )
Task: Sensor array 2 shows calibration drift starting sometime in October — way beyond aging curves. Figure out why.
Three hypotheses fit what I know: (H1) accelerated aging — drift should be gradual and affect the oldest sensors most; (H2) storm damage — the October 19 storm; drift should begin abruptly at that date on exposed sensors; (H3) the November firmware update — drift should begin at deployment, all sensors equally. Cheapest discriminating test: the onset date, one query, and the three hypotheses predict three different shapes.
⟨tool_use⟩
query_readings(sensor = "array-2/*", range = "Sep–Dec",
resolution = "daily")⟨tool_result⟩
Drift onset: abrupt, Oct 19–20, sensors S-3, S-4, S-7 only.
S-1, S-2, S-5, S-6 nominal through December.One query, two hypotheses dead: gradual aging doesn't start overnight, and the firmware update was three weeks later. H2 survives — and it made a further prediction I can check: S-3, S-4, S-7 should be the exposed, seaward-facing mounts.
⟨tool_use⟩
query_logs(system = "installation", range = "array-2")⟨tool_result⟩
Mounting: S-3, S-4, S-7 — south quay, unsheltered. Others:
instrument shed.Confirmed on an independent line of evidence: the drift is storm damage to the three unsheltered mounts, onset matching the Oct 19 storm. Recommend physical inspection of the south-quay mounts; aging and firmware are cleared.
The discriminating test
Three candidate tests, unequal value
The two rules of testing
1. A test every hypothesis passes teaches nothing. Choose tests whose OUTCOMES DIFFER across your hypotheses. 2. Cheapest decisive test first. Spend queries before simulations, simulations before lab days, lab days before rebuilds.
The Designer: searching configurations
Now the same loop pointed at artifact space. The question isn't "which story is true?" but "which configuration works?" — and the experiment isn't a query against the world but a simulation of the candidate:
You have the following tools available for use:
- catalog_search( type, constraints )
- check_assembly( config )
- simulate( config, mission )
Task: Configure a drone for the fjord bird-cliff survey: ≥ 40 min endurance, ≥ 800 g camera payload, wind-rated 12 m/s, parts from our approved catalog only.
Starting hypothesis: the standard survey frame. Quad frame QF-4, four M-220 motors, 6S 8Ah battery, gimbal + camera at 780 g.
⟨tool_use⟩
check_assembly(config = "QF-4 / 4×M-220 / 6S-8Ah / cam-780")⟨tool_result⟩
Valid assembly. Total mass 3.4 kg.⟨tool_use⟩
simulate(config = "…", mission = "cliff-survey-profile")⟨tool_result⟩
Endurance 31 min (FAIL ≥40) · payload OK · wind: marginal at
12 m/s (FAIL) — gusts induce 15° attitude excursions.Two failures, and they pull in opposite directions: endurance wants a bigger battery, wind stability wants less mass and more motor authority. The intuitive move: don't grow the battery — switch to the higher-density HD-6 cells (same mass, +22% capacity) and step up to M-260 motors for gust authority, accepting their higher draw.
⟨tool_use⟩
simulate(config = "QF-4 / 4×M-260 / 6S-8Ah-HD / cam-780",
mission = "cliff-survey-profile")⟨tool_result⟩
Endurance 43 min · payload OK · wind: stable at 12 m/s, 6°
excursions. ALL CONSTRAINTS MET. Margin: endurance +7%.Truth versus artifact
One skeleton, two faces
That last row is not a footnote. In both faces, termination is a contract, written before the loop starts — a confidence to reach, constraints to satisfy, a budget of tests to spend. The propose–test loop has no natural end: there is always another hypothesis, always a configuration with 2% more margin. An unterminated Scientist is a conspiracy theorist; an unterminated Designer never ships. The stopping rule is a design artifact, exactly like the label set and the tool language.
- Take a "why" question from your research. Write three hypotheses and the single cheapest test that discriminates among them. If you can't find one — what pair does your best test split, and what's the sequence?
- In Example 2, the simulator is trusted completely. What is the Designer's failure mode when the simulator is slightly wrong — and which archetype from the checking lessons does the finished design deserve before it flies?
Build one of each on paper, from your domain. Scientist: an anomaly you've actually met — hypotheses, each one's predictions, the discriminating-test table with costs, the termination contract. Designer: an artifact with real constraints — the bounded space (catalog, rules), three propose–simulate–interpret rounds written out, and the stopping rule. Then compare your two loops line by line: what did the failed test mean in each?