B3 ยท Coding: independent readers
Read the material independently, twice
B3 applies the shared scheme across the analyzed communities. Two independent readers place every second-order theme, so differences in interpretation are visible before the aggregator settles them.
Where this stage starts
B2 has frozen the categories and tested their instructions. B3 receives that scheme and all the second-order themes, with the first-order codes and participants' words beneath them. A reader is a separate model conversation. The run calls the set of reader jobs the fleet.
What the aggregator and handler do
The aggregator prepares batches that keep each community together. A large community may need several files, but one reader receives all its parts, and its second reading goes to a different reader. The allocation links communities and readers across batches, so the analysis can test whether particular readers or batch contexts give different answers.
Each reader gets the scheme and its assigned evidence. It sees the labels of the community's other themes for context, and none of another reader's answers, the aggregator's notes or the canvas outcome. It places a theme by its first-order codes, with the community coder's label as one input. When one category cannot hold the material, each extra placement needs a reason.
The handler runs the jobs separately. The aggregator then checks what came back: whether every required item was read twice, whether replies are complete, and whether every category reference is valid. A missing or truncated reply is a delivery problem and is handled apart from disagreements between readers.
Reference items measure how closely readers follow the author's intended distinctions. Further checks examine changes across a batch and variation among readers. These results show how consistently the instrument works; whether the categories explain organizing well is a question for later stages.
What the next stage receives
B4 receives both readings, their reasons, and a record of coverage and uncertainty. B3 keeps each disagreement open, with no majority vote, and B4 returns to the evidence to decide what it means.
What the output files contain
Markdown files hold prose; JSONL files hold one structured record per line.
Who read whatbatches-B3.jsonl, RETURN-B3.md
batches-B3.jsonl records the allocation of communities,
items and reference examples. The packet files built from it hold the
material each reader was served. RETURN-B3.md specifies the
reply format, so the served task can be compared with the answer.
The first placements and reconsiderationsassign_raw.jsonl, assign_pass2.jsonl
assign_raw.jsonl keeps the first placements that B4 will
adjudicate. assign_pass2.jsonl records each reader's
reconsiderations after it finished its batch. The second pass measures
changes within that reading context and is stored beside the first.
Material placed in several categoriesmultiplacement_log.jsonl, multiplacement_register-B3.md
multiplacement_log.jsonl records why an item needs more
than one placement. multiplacement_register-B3.md
summarizes recurring combinations, which later stages inspect as
possible overlaps or defects in the scheme.
Consistency, context and remaining problemsfidelity-B3.md, position-B3.md, agent_report-B3.md, notes-B3.md, run_manifest.json
fidelity-B3.md reports matching against reference
answers. position-B3.md examines changes with position in a
batch. agent_report-B3.md examines variation by reader and
context. notes-B3.md explains choices, reissues and limits;
the run_manifest.json entry records models and
settings.
Full stage description
Read the complete technical card for exact tasks, reading boundaries, checks and closing rules. The explanation above is a guide; the card holds the instructions.
Show how the stage is divided into its 2 legs
B3a: build. Repeats: no. Interview point: -.B3b: check. Repeats: no. Interview point: -.
Source versions and hashes identify the exact technical documents reproduced here.