Module 4 · Planning, Context & Multi-agent Systems · scripted
The Scientist and the Designer
Overview
The Explorer finds what exists. But some questions — why is this happening? what should we build? — have answers that sit in no file: they must be proposed, then tested. One loop serves both: judgment proposes a hypothesis or a design, code runs the test exactly, judgment reads what the evidence changed. The mind guesses; the machine grades. And notice where the science happens: the hypotheses, the predictions, the interpretation are all words in the conversation — thinking made visible on the wall, disciplined by results that cannot be argued with. The conversation becomes a lab notebook that acts.
One loop, two spaces
Hypotheses and designs share one engine, and it's worth seeing its shape before either case:
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.
think(thought = "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.")OK.query_readings(sensor = "array-2/*", range = "Sep–Dec",
resolution = "daily")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.think(thought = "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.")OK.query_logs(system = "installation", range = "array-2")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.
Notice what choosing a test really is: choosing which information to acquire next. A good action buys the most uncertainty reduction for its cost, and the discriminating test is that idea made into an architecture.
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.
think(thought = "Starting hypothesis: the standard survey frame.
Quad frame QF-4, four M-220 motors, 6S 8Ah battery, gimbal +
camera at 780 g.")OK.check_assembly(config = "QF-4 / 4×M-220 / 6S-8Ah / cam-780")Valid assembly. Total mass 3.4 kg.simulate(config = "…", mission = "cliff-survey-profile")Endurance 31 min (FAIL ≥40) · payload OK · wind: marginal at
12 m/s (FAIL) — gusts induce 15° attitude excursions.think(thought = "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.")OK.simulate(config = "QF-4 / 4×M-260 / 6S-8Ah-HD / cam-780",
mission = "cliff-survey-profile")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?