D1 · Adaptation: return build
Prepare to give the model back to each community
D1 prepares a fair return to the cases. Each community lead will see the population model and its own evidence, then explain what the model captures and what needs to change locally.
Where this stage starts
C5 has frozen one version of the model and recorded expectations. D1 has its prose account, model identifiers, coding structure and community documents. No community return has yet been examined, and D1 does not itself write those returns.
What the aggregator does
Before preparing tasks, the aggregator records rules for two later judgments: how similarities between adaptations will be measured, and when evidence is too thin to support a verdict. Recording these now prevents choosing convenient rules after seeing the answers.
The aggregator also writes per-community expectations about which model elements should appear or be absent. Those predictions are sealed away from the people doing the return. An element a community had no opportunity to display is marked as not testable there, rather than treated as a predicted absence.
Each return task contains the model in prose, a vocabulary of its identifiers, a ladder showing how evidence supports its broader ideas, and that community’s own coded documents. It excludes the aggregator’s private notes, other communities’ private material and canvas outcomes. The handler is told to resume the matching original community lead 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 evidence without the lead’s prose account. These readers answer a different question from the lead: they assess fit, while the lead writes an adapted local account.
The stage checks coverage, identifiers, versions and task sizes. If material cannot be served as required, that is recorded as a problem; the aggregator does not silently trim away a difficult community.
What the next stage receives
D2 receives fixed tasks ready for dispatch. All leads can answer the same model version, and the later audit can compare their answers with expectations written beforehand. This is a return to cases used in building the model, not a test on a newly collected sample.
What the output files contain
Open a file group for its purpose. These are descriptions of the stage’s outputs. Markdown files hold prose; JSONL files hold one structured record per line.
The model the community leads 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 connects them to evidence. VERSION
identifies 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 fit-assessment packets.
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
prior.md sections 7 and 8 record distance and evidence
rules. MODEL-D1.md supplies the prose model used in the
handoff. EXPECTATIONS-D1.jsonl supplies 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.
How the stage is divided into legs
D1a: build. Repeats: no. Interview point: -.
Source versions and hashes identify the exact technical documents reproduced here.