D1 ยท Adaptation: return build
Prepare to give the model back to each community
D1 prepares a fair return to the cases. Each community coder will see the population model and its own evidence, then say what the model captures and what needs to change locally.
Where this stage starts
C5 has frozen one version of the model and recorded its expectations. D1 has the prose account, the model's identifiers, the coding structure and the community documents. No return has been examined yet, and the returns themselves are written in D2.
What the aggregator does
Before preparing the tasks, the aggregator records the rules for two later judgments: how similarity between adaptations will be measured, and when evidence is too thin for a verdict. Fixing these now keeps the rules from being chosen after the answers are seen.
The aggregator also writes, for each community, which model elements it expects to appear or be absent. These predictions are sealed away from the agents doing the return. An element that a community had no chance to show is marked as not testable there, which keeps it apart from a predicted absence.
Each return task contains the model in prose, a vocabulary of its identifiers, the levels of coding that link evidence to the model's ideas, and that community's own coded documents. It leaves out the aggregator's private notes, other communities' private material and canvas outcomes. The handler is told to resume the community's own community coder, with its history and files.
A second set of packets prepares two independent readers to judge how well the model accounts for each community. They receive the evidence without the community coder's prose account. The two tasks differ: the readers judge fit, and the community coder writes an adapted local account.
The stage checks coverage, identifiers, versions and task sizes. Material that cannot be served as required is recorded as a problem, and every community stays in the return, difficult ones included.
What the next stage receives
D2 receives fixed tasks ready for dispatch. Every community coder answers the same model version, and the later audit can compare their answers with the expectations written beforehand. The return goes to the same cases that built the model; no new sample was collected for it.
What the output files contain
Markdown files hold prose; JSONL files hold one structured record per line.
The model the community coders will readhandoff-D/MODEL.md, VOCABULARY.json, LADDER.md, VERSION, RETURN-D.md
handoff-D/MODEL.md explains the model.
VOCABULARY.json lists valid identifiers;
LADDER.md links them to evidence. VERSION
names the frozen model. RETURN-D.md specifies the local
account and adaptation record to return.
Each community's task and the handler's briefhandoff-D/tasks/<sub>/TASK.md, tasks/index.tsv, HANDLER.md
handoff-D/tasks/<sub>/TASK.md gives the task
beside that community's documents. tasks/index.tsv lists
tasks and sizes. HANDLER.md defines dispatch, checks and
how to report a missing return.
The independent verdict tasksverdict-D/, RETURN-D2v.md
verdict-D/ contains the separate packets for judging
fit. RETURN-D2v.md specifies the verdicts and supporting
evidence readers must provide.
Predictions, rules and preparation notesprior.md, MODEL-D1.md, EXPECTATIONS-D1.jsonl, out/sealed/EXPECTATIONS.jsonl, notes-D1.md, handback-D1.md
Sections 7 and 8 of prior.md record the distance and
evidence rules. MODEL-D1.md supplies the prose model used
in the handoff. EXPECTATIONS-D1.jsonl supplies the
predictions, sealed as out/sealed/EXPECTATIONS.jsonl.
notes-D1.md records checks and limits;
handback-D1.md records the handoff.
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 1 legs
D1a: build. Repeats: no. Interview point: -.
Source versions and hashes identify the exact technical documents reproduced here.