Kind of page: explanation.
The aggregator builds one model across all coded communities. It holds every coder's sealed work, reads every room, builds the third-order themes, fourth-order themes and aggregate dimensions, draws a model with arrows, and returns the model to every room to learn what it must change to explain that room. The forms of organizing are read off those changes. The agent that does this is called the analyst. This page describes the aggregator instrument (v38) from the top down. How it was built tells why each level exists, and the file index lists every page.
One idea runs through all of it. The analyst has a huge but limited working memory. Knowledge is stored in writing, and only decisions are made in context.
Three documents hold at every stage, each for a different kind of rule. The contract is the brief: the two questions, the tiers, the rules, the stages, the frame. The standing instructions say what the analyst holds, which tools it has, and how its memory and a leg work. METHOD.md says what Gioia, Corley and Hamilton, Grodal, Anteby and Holm, Eisenhardt and Langley require, and which shelf of literature arrives when. AGENT.md is the analyst's first page, and CLAUDE.md is loaded into every session.
The work itself is cut into stage files, handed over one at a time: five sections (reading, coding, model, adaptation and forming, formalizing), eighteen stages from A1 to E2. Stages exist so the analyst cannot read a later stage while answering an earlier one. Each stage is a series of steps, listed in steps.tsv and parsed by steps.py, and each step is one or more legs. A leg is one fresh launch that starts from the files and ends at done.sh. Legs exist because a long session costs far more and compacts unseen. Fleet stages add FLEET.md, the return adds the adaptation schema, and the analyst writes its expectations first from the prior template. The source files start at ../aggregator/instrument/CONTRACT-aggregator.md.
Everything is built by script before the analyst arrives, so its first leg starts with reading.
The analyst never opens a large file whole. It asks through verbs, and every call is logged, so what it says it read can be checked against the log. mem.py serves the store and the analyst's own files one page at a time and is the only writer to the diary. cite.py is the only way a quote enters an output. validate.py opens and closes every leg, with one check per stage in tools/checks/. saturation.py holds the stopping rule: the random order at A1, when B1 may stop reading, and the report the PI decides on. snap.py records what existed when, and probe.py scores the recall probe. For the fleets and the return, packets.py builds what a reader is served, handoff.py and ingest.py send the model back to the rooms and take in the answers, and rebuild.py and distance.py work over what came back. NEW-VERBS.md lists what the v38 pass added.
out/ is the only place the analyst writes, and it is the analyst's memory on disk. The head is the narrative of the argument, read first at every leg. The diary is the running log under it. The read logs show what was read, the snaps what existed when, and the probe what the analyst could still recall at each close. Scripts regenerate views and wiki pages from what the analyst wrote, and room notes keep its first reading of each room. This is the virtual memory: the analyst pages in what a decision needs and writes back what it decided. How the aggregator remembers tells how the pieces work together.
The analyst does not start or stop itself. The handler runs it through a harness. build.sh lays out a run once. step.sh opens a leg and launch.sh starts the session under its settings. close.sh closes the leg, runs the probe and publishes a checkpoint. dispatch.sh and the handler's fleet.py send fleet work to readers named in arm.json. pause.sh and interview.sh stop the analyst or talk with a fork of it. The protocol guard, the pre-tool guard and the compaction hook hold the rules the analyst might forget. The run's READ-ME-FIRST is the person's first page, and the handlers page tells how the handler works.