Specification: classification, populations and references

Planning specification (prefix CPR; tracker brief row T-CP-00, workstream CP). This page turns lane C1 ("Populations and explicit classification") of the integrated plan and contract C13 of the contracts into a buildable design, and adds custom reference questions: designer-defined questions whose answer points at another record, which generalise today's fixed lookups. Owner decisions recorded here are planning approval only. Brief approval and implementation authorisation are separate per-gate decisions (D1-04) and remain on hold (Chris, 5 October 2026). No work has started, no gate has passed and nothing is enabled anywhere. Nothing here authorises implementation, migration, activation or sending the design pack. Names are PROPOSALs for the F1a naming ADR, and storage is PROPOSAL for the F1a and F-C storage ADRs.

Sources. The main source is the unified annotation and classification research (Chris and Codex, 24 September to 3 October 2026): named records, definition types, the reference graph and custom reference picker, classification capability, cohort coverage, double counting (§3.3), exports, the farm, diabetes and outcome examples (§4), phases (§7) and the feasibility verdict (§8). Later owner direction recorded in the v10 design comparison ("COMPARISON" in C13) wins over the research where they differ: it established the whole-population cohort and the one-population-per-record boundary after the research had described a scope reference without a root cohort. The extensibility architecture section "Future direction (deliberately unspecified): reference responses and customisable relationships" is the starting point for reference questions. The owner-session consolidation §5 and the register (Q-18, Q-19, S5) win over older package text.

Labels. OWNER (a decision ID), PROPOSAL (this specification's recommendation for the brief), OPEN (an owner question not yet answered), BRIEF (an engineering or validation item that the workstream brief settles). "Recorded owner direction (COMPARISON)", or "Recorded direction (COMPARISON)" where the comparison does not attribute it to Chris, marks direction recorded in the v10 design comparison (2 and 3 October 2026) that has no decision-register ID. It wins over the research where they differ (Sources), but it is not an OWNER decision: the brief confirms it, and any shape or mechanics this page adds to it are PROPOSAL. Code facts are CODE-MAIN, read on main at 286c73b37 on 6 October 2026.

Companion specifications. Training and inference (TI) owns the inference beta (lane C2): rule evaluation, inferred groups, proofs and count statements, and, since DQ-09 was decided on 6 October 2026, rule authoring and publication. This page links to it and never repeats it. Review domain and versioning (RD) owns question identity, versions, compatibility and publication. Reconciliation and screening (RS) owns accepted results and hints. Baseline conversion (BC) owns faithful conversion. Reporting, imports and AI screening (RI) owns exports, including the overlap markers this page asks for (RI-R59 to RI-R63). UX, devices and work discovery (UX) owns the reviewer workspace. Access, communications and deletion (ACD) owns the catalogue and question import.

1. Summary in plain English

What C1 is for. Many papers report several groups of animals and say how they relate: "120 cattle on two farms, 70 on Farm A and 50 on Farm B; 70 females, of which 20 were pregnant". C1 lets reviewers record those groups and relationships as explicit answers that can be checked, reconciled and exported. SyRF records, reconciles and exports this evidence. It does not analyse it, pool groups or calculate effects. C1 itself infers nothing: suggestions such as "the pregnant animals must be inside the female group" come only from the opt-in inference beta that TI describes.

Entity types instead of fixed tabs. Today a project's questions sit under fixed categories (Study, Disease Model Induction, Treatment, Outcome Assessment, Cohort, Experiment, plus a hidden one), shown as tabs. C1 turns each category into an entity type: a kind of record a reviewer can create in a paper. A project can add its own types, for example "Location" or "Diet", and switch on what a type can do: describe which animals belong to a group, or be nested inside another record.

Named records. A reviewer records each thing the paper names once, for example "Farm A" or "Treatment X, 10 mg/kg", and then refers to it from other records. "Farm A" in one paper is never assumed to be "Farm A" in another, and two records with the same name are never assumed to be the same.

Populations. Every Study starts with one population: all the animals the paper studies. A paper that reports two unrelated sets of animals, for example a mouse experiment and a separate rat experiment, can have two populations, so that groups are only ever related to groups in their own population. Each population has a whole-population group that stands for "all animals in this population". It has no number unless the paper reports one.

Relationships with evidence. "North and South are inside Farm A", "Farm A and Farm B share no animals" and "Farm A and Farm B together cover all 120 cattle" are three separate statements. Each is recorded with its evidence, for example a quotation and page, and with whether the paper reported it or the reviewer interpreted it.

Shared concepts and project rules. A project designer defines concepts such as "Pregnant" and "Female" once, and rules such as "Pregnant is contained in Female". In each paper the reviewer confirms which local terms mean which concept and, where the project uses the beta, whether a rule applies. Disagreements are reconciled like any other answer. Writing, publishing and evaluating rules all need the project's inference beta (Chris, 6 October 2026, DQ-09 option (a)); recording groups and classifications, defining shared concepts and mapping local terms to them do not (§3.7, §12 item 4).

Custom reference questions. Today five questions point at other records, and all five are fixed in code: a cohort's disease models, treatments and outcomes, an experiment's cohorts, and an outcome's PDF graphs. C1 lets a designer create such questions, for example "Housing location" on a cohort, pointing at Location records. The answer stores the record's identity, never its name, so renaming a record never breaks the answer.

Three examples from the research (§4).

• Farm, age and reproductive state. A paper reports 120 cattle: Farm A 70 and Farm B 50, disjoint and together complete; two age groups that also cover all 120. A Female group covers all females (70) and a Pregnant group has 20. The reviewer records each fact once. No export ever adds the farm and age groups to make 240 animals.
• Diabetes sub-study. A Diabetes classification describes animals in a group; it is not a Study-level Include. A missing Diabetes answer means "unknown", never "not diabetic".
• Outcome counts and a shared control. A group of 20 animals has 18 measured at week 3. Two comparisons use the same control group. The export flags the shared control and never counts its animals twice.

2. Decisions covered

ID	Decision in one line	Status	Section
Q-18	The first reasoner supports conjunction, containment, disjointness and exhaustiveness only	Decided (S5); owned by TI	§3.7; CPR-R30
Q-19	The Design capability publishes project rules; reviewers confirm per-paper applicability through mapping answers; normal reconciliation resolves disagreements	Decided (S5)	§3.6, §3.7; CPR-R29, CPR-R30
S5 approved interpretation behaviour	Candidate inference from the reviewer's own snapshot, collective inference from a pinned accepted result; reported answers preserved; no invented counts	Decided; owned by TI	§6; CPR-R26
S5 beta opt-in amendment (OS-A19)	Inference is a beta, off by default, and does not switch on explicit classification recording, which keeps its own enablement	Decided; owned by TI	§10; CPR-R26, CPR-R39
TC1	Templates default to the existing legacy entity types; cohort, outcome-measure and experiment types attach only when a form uses extraction or export	Decided	§3.1; CPR-R03
MG1	SyRF suggests entity and cohort matches from labels and answers; the reconciler adjusts and confirms	Decided	§3.4.6; CPR-R32
Populations (later owner direction, recorded in COMPARISON "Study populations")	A whole-population cohort in each independent data boundary; each recorded instance in exactly one population; counts unknown unless supported	Recorded owner direction (COMPARISON, 2 and 3 October 2026); shape PROPOSAL	§3.3; CPR-R11, CPR-R12
ODIR1	One outcome-measure direction across cohorts in a paper or population	Decided; owned by C14 and O1	§3.3
OD12	Follow-up breadth after C2: rule chaining, set algebra, ontology authoring, population merging and cross-type count solving	Follow-up with no release	§10.5
DD-12, DD-24, VB-09	EntityTypeId minted at F1a; the default population derived and needing no document; instance identity is the label head	Adopted package findings (not owner decisions)	§3.1 to §3.3
D2-03, D2-06	A data-type or multiplicity change is incompatible; system questions are versioned data	Engineering contracts (RD-R30, RD-R32)	§3.4.4, §3.4.8
RC8, DQ-13	Where the population context sits in the reviewer form	Open layout choice (validation U3)	§3.8
DQ-09	What the inference beta covers: rule authoring and publication, rule evaluation and inferred results need explicit project beta opt-in; ordinary annotation and explicit group or classification recording follow their own availability. Option ©, this page's earlier PROPOSAL of rule authoring in C1, is not adopted	Decided, option (a) (Chris, 6 October 2026; decision register §1.18); owned by TI (TI-R38)	§3.7, §10, §12
Custom reference questions (owner discussion, 6 October 2026)	Generalise the fixed lookups into designer-defined reference questions; whether they are needed at GA or come with C1, and which target types they cover, are not decided	OPEN	§3.4, §10.2, §12
Export overlap markers	Stable IDs, explicit relationships by default, flagged overlaps, no sums over overlapping groups	PROPOSAL (RI-R59 to RI-R63)	§3.9, §12

Every rule and acceptance item below is PROPOSAL unless its source names an owner decision. The rules decided under Q-18, Q-19 and S5 are restated, not re-decided.

3. Concepts, entities and storage

Each entity says what it is, how it is identified, which versions and pointers it has, what may change, where it is proposed to live and what it is not. Two storage rules from RD §3 apply: immutable records live where an append-only repository can enforce insert-only writes, and a new collection is proposed only when that rule or a measured need requires it.

Three graphs, kept apart (research §2.2).

1. Ownership tree. A parent owns child answers: a record owns its property answers, and a decision owns its reasons. Ownership forbids cycles (DD-26).
2. Reference graph. An answer points at a record defined elsewhere, for example a cohort's treatments. A reference never moves, copies or deletes its target, and never makes the target a child.
3. Relationship graph. Typed statements about membership: subset, disjoint, exhaustive, same members, composition. Their meaning comes from their type, scope and evidence, never from screen nesting or ownership.

3.1 Entity types and capabilities

• What it is. A kind of record a reviewer can create in a paper: the legacy types (disease model induction, treatment, outcome assessment), the system cohort, outcome-measure and experiment types, and project-defined types such as "Location", "Diet" or "Housing". A type defines its label question, its numbered child questions, its presentation and the capabilities it may use.
• Identity. EntityTypeId. System identities for the seven legacy categories plus cohort, outcome measure and experiment are minted at F1a as a shared-kernel value object (DD-12); R2a forms already pin them. C1 adds the aggregate, capabilities and project-defined types without re-identifying anything. Project-defined types get (projectId, entityTypeId) at creation. C1 also mints one new system identity, the population type (§3.3).
• Versions (PROPOSAL). An immutable EntityTypeVersion (entityTypeId, seq): name, plural, description, label question reference, permitted parent types, capabilities, guidance (the category-keyed guidance that BC-R48 carries over) and presentation (tab label, order hint). Form versions pin the entity-type versions they use; C4 already lists "entity types present" in a form version. Changing presentation, guidance or adding a capability is compatible. Removing a capability or changing the label question or permitted parents is incompatible. A project may relabel a system type in its own forms (presentation only) and never changes its capabilities.
• Capabilities. A closed set implemented by SyRF (research §2.1), listed in the table below. Designers configure known capabilities; they cannot invent behaviour through metadata. An ordinary link, for example a cohort's treatment, implies no set relationship. Only ClassifiesAnimals and StructuredSubsets give records a membership meaning (research §1.2 item 2).
• Templates (TC1, OWNER). Templates default to the existing legacy types. Cohort, outcome-measure and experiment types attach only when a form uses extraction or export. Their names and aliases are checked against the existing legacy identities at F-C (E14).
• Label question. Every type rendered on a canonical form has exactly one label question, because AF2 renders one label question per mutable-unit category (versioning model §4.3). For system types it is the existing system label question; for a project type it is created with the type.
• Mutability. A published type is retired, never deleted (the QD1 rule for questions): no new records of a retired type, and every existing record stays readable.
• Proposed storage (PROPOSAL). pmEntityType head (already in the domain model) plus an append-only pmEntityTypeVersion.
• What it is not. Not a tab: a tab is presentation. Not a cross-paper concept. Not permission to run code.

Capability	What it allows	Available on
ClassifiesAnimals	The type's records or options describe which animals belong to a group; they may appear in cohort criteria, shared-concept mappings and project rules	Project-defined and legacy types
StructuredSubsets	Records may be nested (North and South under Farm A) and carry set annotations (§3.5)	Project-defined and legacy types
Cohort	A reported group with criteria, scope, coverage and the cohort-size role	System cohort type only
OutcomeMeasure	Measure definition with direction and the O1 series behaviour (C14)	System outcome-measure type only
Experiment	The legacy comparison grouping that outcome data and exports depend on	System experiment type only

3.2 Named records and label heads

• What it is. A Study-local instance of an entity type that a reviewer creates: "Farm A", "Treatment X, 10 mg/kg", "Female cohort". Records of the cohort type are cohorts; records of other types are definitions.
• Identity. The label head's ID in the author's scope, minted once from a client-proposed, server-validated ID (VB-09). Rename is a new label revision; delete is a set of withdrawal revisions on the label head and its descendants in one commit; duplicate mints new IDs with copiedFrom provenance. In the answer context key a record appears as instance(labelHeadId) in entityPath (C2).
• Content. Property answers are ordinary answers keyed under the record. A cohort also records:
• criteria: which classification options or records its members satisfy, compiled at Save to a typed expression under a versioned grammar (§3.5);
• scope: its population and, optionally, an enclosing cohort;
• coverage: Complete (every animal in scope that meets the criteria is in the group), Partial (a sample) or Unknown, which is the default;
• cohort size: the answer to the existing system integer question with the semantic role CohortSize (research §2.3). There is no second editable count. Analysed N is O1's separate role on a series or observation (C14).
• Three different things. Coverage of a cohort, exhaustiveness of a set of options and completion of a form mean different things. A missing classification is unknown, never a negative fact (research §1.2 item 5). A free-text "Total" label does not establish complete coverage.
• Reconciliation. Two reviewers may give one reported group different IDs, or give two different groups the same label. The reconciler confirms a correspondence map (§3.4.6).
• Proposed storage. Evidence heads and revisions (C1, C2); no new collection.
• What it is not. Not equivalent to a same-named record elsewhere. Not an individual-level membership list. Not evidence of full coverage, independence or a count.

3.3 Populations and the whole-population cohort

• What it is. A population is an independent data boundary inside a Study: the set of animals whose groups can be related to one another. Most Studies have one. A paper reporting two unrelated sets of animals may have two. This is SyRF's chosen boundary, not a universal scientific definition (COMPARISON).
• The default population. Its ID is derived deterministically from the Study ID, every answer carries it from its first canonical write, and it needs no document (DD-24, C2). Enabling C1 re-keys no answer.
• Additional populations (PROPOSAL). Recorded by a reviewer as named records of a new system population type, so they live in the author's scope like any other record and are matched by the reconciler. The default population needs no matching because every scope derives the same ID. This deviates from the domain model's single Study-level AnimalPopulation aggregate: a Study-level document would show one reviewer's populations to another and break independence. A dedicated collection is kept only if the F-C storage ADR finds a measured need (§12, item 5). A new population type also departs from COMPARISON's "Study populations" row ("Define as a system role on the cohort structure") and from research §1.2 item 6 ("Do not add a second Population entity duplicating Cohort"). §12 item 5 flags the departure and offers the alternative: the whole-population cohort as the population record.
• The whole-population cohort. Each population has a system cohort with the role WholePopulation. Its ID is derived from the population ID, so it too needs no document until something is recorded about it. Guards (COMPARISON: "a system-established cohort is not evidence that its size is reported or that classifications exhaust it"):
• its coverage of its own population is complete by definition, which says nothing about any other cohort's coverage;
• it has a size only when a reviewer records the paper's number as its CohortSize answer;
• it is never counted as a reported group in exports or counts (RI-R62);
• it is the default scope of a cohort that has no enclosing cohort.
• One population per record. Every record belongs to exactly one population, fixed when it is created: populationId is part of C2's AnswerContextKey, so changing it would re-key the record's answers, and VB-09 rule 5 makes membership an attribute of the instance. Relationships, set annotations, reference answers and rule applications never cross populations. A record created in the wrong population is duplicated into the right one (new IDs with copiedFrom) and the original withdrawn, so no answer is re-keyed. Combining two whole populations is the population-merging follow-up (OD12).
• Outcome direction. ODIR1's "one direction across cohorts in a paper or population" uses this boundary.
• What it is not. Not a PRISMA unit: populations and cohorts change neither the Study count nor metaAnalysisIncluded (FX-PRISMA-06a). Not a fabricated reported group. Not evidence of a count or of exhaustiveness.

3.4 Custom reference questions

3.4.1 Today's lookups (CODE-MAIN)

• Five system questions have AnnotationLookup = true, all fixed in code (AnnotationQuestion.cs:122, :445-451, :483-690):
• cohort → disease models (target: the disease model induction label);
• cohort → treatments (target: the treatment label);
• cohort → outcomes (target: the outcome assessment label);
• experiment → cohorts (target: the cohort label);
• outcome → PDF graphs (hidden; target: answers to the hidden system PDF reference question).
• The server checks the first four against a fixed source-to-target map, LookupTargetQuestionIds (AnnotationRelationshipValidator.cs:221-227). It checks outcome data's experiment, cohort and outcome IDs against the matching label questions (:79-120).
• A lookup answer is a string array of target annotation IDs.
• Project questions cannot be lookups: the custom-question constructor never sets AnnotationLookup (AnnotationQuestion.cs:49-66; UpsertCustomAnnotationQuestionDto has no such field).
• R1a's question import refuses lookup rows with a named reason until a remap exists (ACD-R41; AC-R1a-01 as amended on 5 October 2026).
• The quantitative export emits experiment, cohort and outcome IDs and the Disease Model and Treatment control answers (research §1.3). These are compatibility dependencies.

The extensibility architecture records the generalisation as a deliberately unspecified future direction: a reference is an ordinary answer whose value happens to be a reference, not a response mode, and a reference question can still offer "Not applicable". This section specifies it.

3.4.2 What a reference question is

• An ordinary question whose value is a reference to one or more records of declared target types. The value stores target IDs, never labels. Labels are display data resolved from the target's current label revision.
• It can offer reasons no value is provided and metadata like any other question, under the 6 October 2026 directions on required-by-default questions and configurable answer metadata, in the terms Chris decided that day (DQ-46; RD §3.16 and the versioning model carry them). For example, "Housing location" may allow Not reported, and require an evidence quote with its source location. An empty selection is never stored as an answer; "none" is said with a reason no value is provided. A reference answer's answer status is "answered with a value" (a reference is a value).
• Target contract (question-version content, PROPOSAL). referenceTarget, with the fields in the table after this list.
• Value (PROPOSAL). A list of {targetId, targetKind}; for a configuration record also the exact targetVersionId. The session version records, for each named-record target, the label revision current at commit, so history shows what the target was called then.
• Candidate target types. Which of these the first release offers is OPEN (§12, item 2): definitions of any type, cohorts, outcome measures, experiments, populations, and configuration records such as shared-concept versions. C14's outcome-schema selection question already references a configuration record (the schema version); it keeps its dedicated system question (research §4.5) and uses the same contract shape.

referenceTarget field	Meaning
targetKind	NamedRecord (a record in the same Study) or ConfigurationRecord (a project-level definition)
targetEntityTypeIds[]	For named records: the allowed entity types, by EntityTypeId
configurationKind	For configuration records: the allowed kind, for example SharedConceptVersion (§3.6)
scope	The scope rules of §3.4.3, including an optional same-parent rule
cardinality	Single or multiple, with optional minimum and maximum
emptyStateText	Text shown when no target exists yet ("Add a Location first"), replacing today's EmptyLookupText

3.4.3 Scope rules

• Named-record targets must be in the same Study, the same author scope and the same population as the answer, plus any same-parent rule the version declares (for example "a cohort's treatments must be recorded under the same experiment"). A candidate's answer can reference only that candidate's records; a reconciled answer only reconciled records.
• Configuration targets must be project-owned (or system-owned) and among the versions the pinned form version allows; a reference to another project's record or to an unavailable version is refused (research §7, "Schema reference targets another project").
• Validation. The server validates scope on every Save and Complete. Cross-Study, cross-project, cross-population or cross-scope references are structural errors that block the commit (research §3.2). An autosaved draft may hold an invalid reference; Save names it.

3.4.4 Version pinning and compatibility

The target contract is version content, so a form version pins it through the question version. The compatibility suggestion follows the D2-03 pattern for data type and multiplicity (RD-R30):

Change	Classification
Add a target type; widen scope; raise a maximum	Compatible
Remove a target type; narrow scope; lower a maximum; change single to multiple or back; change target kind	Incompatible
Change emptyStateText, wording or help	Compatible (presentation)

A configuration-record answer pins the exact version, so editing the project catalogue never changes a submitted answer (research §4.5). A named-record answer pins the target head; the target's later renames change the display, never the stored reference.

3.4.5 Deleting and retiring targets

• A reviewer deletes a referenced record. The deletion dialog first lists every answer that references it, in the reviewer's sessions on that Study. After deletion the referencing answers keep the ID and show "Refers to a deleted record"; Complete refuses them with a typed error naming the question until the reviewer changes them. Nothing is removed silently. The reviewer's other sessions that pin the record are flagged as outdated, as for any withdrawn instance (VB-09 rule 3).
• A designer retires a configuration record or an entity type. It cannot be newly selected. Existing answers stay valid and readable, pinned to what they referenced.
• Hard deletion of referenced history is never allowed (research §2.2).

3.4.6 Reconciliation and the blinded view

• Correspondence first. Before comparing any answer that depends on records, the reconciler confirms a correspondence map: match, split or distinguish each candidate's records, starting from MG1's suggestions. The map is immutable once committed; a change writes a new map version and re-evaluates only dependent answers (C9 matching row).
• Then compare. Reference answers are compared as sets of corresponding reconciled targets. An unmatched target shows "Not matched yet". Nothing is compared by label, count or array position.
• Reconciled answers reference reconciled-scope records. The original candidate graphs and the map stay as provenance (research §2.5).
• Blinding. Under the form's identity blinding (RS), candidates appear as Reviewer 1, Reviewer 2 and so on. Record labels from the paper are shown, because the reconciler needs them; reviewer identities are not. The reconciled answer's picker offers only reconciled records. No picker search, count, label or realtime event shows a candidate's records to anyone without access to that task.
• Hints. Reference answers get no click-to-fill hints until RS's correspondence rule for entity instances exists (RS-R37).

3.4.7 Import by two-pass stable-ID resolution

• Question import (definitions). A question template may contain reference questions. Target types resolve by EntityTypeId for system types, or by a stable type key for a project type defined in the same file or already in the project. An unresolved type refuses the row with a named reason, and nothing is created while any row is refused (ACD-R40). Until C1, lookup rows stay refused (ACD-R41).
• Answer import (lane XA1, and baseline conversion). Pass 1 creates or resolves the named records by their stable source IDs and records the mapping (the LegacyIdAlias pattern). Pass 2 writes the references and relationships, translating every source target ID through the pass-1 map. An unresolved target refuses or quarantines its row explicitly. Labels are never used to resolve a target. The preview shows collisions and mappings, preview equals apply, and each Study's change set commits atomically (research §5, Import and API rows).

3.4.8 Today's lookups as system reference questions

• The five lookups become system question versions (D2-06, RD-R32) whose target contracts are system-owned and not editable by projects. Their GUIDs are unchanged, and the global seed equals main's definitions (RD-R43). The PDF-graph lookup uses a system-only target kind for source regions that designers cannot choose.
• Until C1: legacy projects keep the lookups unchanged. Canonical forms admit the four cohort and experiment lookups when O1 admits extraction (R2a refuses quantitative extraction on canonical forms until then). The server check, re-keyed from the fixed GUID map to the system target contracts and label head identities, gives the same accept and refuse results as today on shared fixtures. Designers cannot create reference questions before C1 (§10.2).

3.5 Relationship and set annotations

• What it is. A typed, scoped assertion about membership, recorded as an answer owned by the parent record or the set it describes, with a backlink shown on each child (C13; COMPARISON "Classification sets and subsets").
• Kinds (PROPOSAL names).

Kind	Example	Notes
Subset	North ⊆ Farm A	"Strict" subset needs evidence beyond subset
Disjoint	Farm A and Farm B share no animals	Separate from exhaustiveness
Exhaustive	Farm A and Farm B together cover the population	Separate from disjointness
SameMembers	Treatment A period and Treatment B period involve the same animals	Recorded only; temporal reasoning is deferred (research §4.4)
Composition	Selected cohorts together make up a reported total	Attributed evidence even when classifications are incomplete (research §3.2)

• Each assertion carries its scope (one population, optionally an enclosing cohort), an evidence kind (Reported or ReviewerInterpreted), evidence metadata (a quotation with source location, page), its author and its revision provenance.
• Typed, not textual. At Save it compiles to a validated assertion. A free-text note saying "subset of" remains a note (research §2.2).
• Criteria grammar. A cohort's criteria compile to an expression under a versioned grammar. C1's recording grammar is a conjunction of option and record selections ("Female and Farm A"). An expression outside the grammar is preserved through a reader and writer contract and marked Unsupported; it is never replaced by a weaker one. Q-18 governs what the beta reasons over.
• Errors and contradictions. Structural errors block Save: a dangling or cross-population target, an invalid expression, a strict-subset cycle or an ownership cycle. Scientific contradictions, such as a subset recorded as larger than its superset, are saved and flagged and never block Save or Complete: "complete review" means the reviewer finished, not that the paper is consistent (research §3.2).
• Distinct absences. No classification (unknown), Other (a locally named concept) and none-of (an explicit complement within the scope) stay distinct in storage, validation and export.
• What it is not. Not an ownership edge, not a screen nesting and not an inferred truth.

3.6 Shared concepts and per-paper mappings

• Shared concept. A project-level definition, such as "Pregnant", "Female" or "Juvenile", defined once by Design holders. Identity (projectId, conceptId); immutable versions (conceptId, seq) with name, description, the entity type or classification question it applies to and its membership meaning. It is recorded for the review's scientific context, never inferred from a label, and never assumes, for example, that sex and gender are the same (research §3.1).
• Concept mapping answer. An ordinary answer in which the reviewer says that, in this paper, a local option or record corresponds to a shared concept version. It is a reference answer to a configuration record (§3.4.2) on a system question that C1 adds to each ClassifiesAnimals type.
• Rule-applicability answer. Per population and published rule version, the reviewer answers whether the rule applies here (proposed values: Applies, Does not apply, Not evaluated; the brief fixes them). This is Q-19's "mapping answer". It arises only in a project with the inference beta on, because rules exist only there (DQ-09, §3.7).
• Pinning. Mapping answers reference exact concept and rule versions. Publishing a new version leaves earlier mappings pinned to the earlier one and shows "A newer version exists" (AC-C1-04).
• Reconciliation. Disagreements go through normal reconciliation (Q-19).
• Proposed storage. pmSharedConcept (already in the domain model) with append-only versions; mapping answers are ordinary evidence.

3.7 Project rules (linked to TI)

• Project rules are ClassificationRuleVersions as TI §3.8 defines them: the four kinds of Q-18 only, published by the Design capability (Q-19), stored in pmProjectRule with append-only versions.
• Rules connect specific concepts, not whole entity types, and apply only within one population and a compatible membership and time context (COMPARISON F6).
• Rules sit inside the beta (OWNER DQ-09, option (a), Chris, 6 October 2026). Rule authoring and publication, rule evaluation and inferred results require the project's explicit beta opt-in (TI-R38). So the rule pages, the rule versions and the rule-applicability answers on them exist only in a project with the beta on, and every evaluation (inferred groups, simplification, proofs, count statements, contradictions found by reasoning) is the beta's, under TI §3.7 to §3.9 and TI-R24 to TI-R38. Lane C1 keeps explicit recording, entity types, populations, relationships, shared concepts and per-paper concept mappings, under its own setting (CPR-R39). This does not accelerate classification delivery or introduce a separate review workflow.
• Superseded 6 October 2026: this page had proposed option ©, rule authoring, publication and rule-applicability answers in C1 outside the beta. Chris chose option (a), so option © is not adopted.

3.8 Compact cohort selection and the population chip

• Compact selection (U3). Per-cohort questions are answered for the cohort selected in a compact selector (a chip row or a searchable menu) showing the population, the cohort label, its size and its coverage. It never pushes the form down (AC-C1-05's U3 pass bar), and works by keyboard, touch and screen reader on phones, tablets and desktops.
• Selection is navigation. The selected cohort lives in the per-session presentation record (VB-09 rule 6). It is never an answer and never changes a session version.
• Population chip. Where the reviewer sees which population they are in is RC8 and DQ-13 (recommendation: a header chip, validated in user testing).

3.9 From category tabs to entity types

• Today. AnnotationQuestion.Category is one of seven fixed strings; tabs and category-keyed guidance follow it (research §1.3; C4 baseline).
• The move. The category string becomes a display alias of EntityTypeId with no identity change (DD-12, VA-25). Tabs become presentation of entity types in a form. Every question, answer, guidance item and legacy export column stays reachable and unchanged (AC-C1-08). Disease Model and Treatment become compatibility-mapped definition types; their question GUIDs, control flags and export columns are kept, and no classification meaning is backfilled (research §6, U5).
• No data migration. R2a forms already pin entity-type IDs, so C1 adds capabilities and presentation without rewriting anything.
• Exports. Exports gain stable population, cohort, record and reference IDs, explicit relationships and overlap markers (RI-R59 to RI-R63) while keeping today's columns.
• Overlapping forms. Two forms still cannot use the same entity type until R2d (A-19).

4. What loads and writes when

Writes follow the C18 commit protocol; after-commit work uses C19 durable effects; history uses the C20 HistoryEvent envelope.

4.1 A designer creates or changes an entity type

Step	Detail
Reads	Design access; the design draft; existing types and their label questions
Writes	DesignDraftChange appends (RD §3.7); on commit, an immutable EntityTypeVersion
Transaction	The design draft, then the version commit, as for question versions
Derived after	No reviewer sees it until a form version that pins it is published (RD §4.8)

4.2 A designer adds a reference question and publishes the form

Step	Detail
Reads	The target contract; that every target type exists and is pinned or pinnable; renderability
Writes	The question version with referenceTarget; at publication the form version pins it
Transaction	Ordinary question commit and two-phase form publication (C4)
Derived after	The publication preview treats a new question as RD does (required by default, with the admin's treatment of earlier completed sessions); an incompatible contract change shows affected sessions

4.3 A reviewer records a named record

Autosave writes the draft. Save or Complete writes the label head, its revisions and property answers in the reviewer's session version, in one study-scoped transaction (RD §4.3, §4.4). The record's population is fixed at creation; a new population is itself a record.

4.4 A reviewer answers a reference question

Step	Detail
Reads	For the picker: the reviewer's own records of the target types, in scope, across their sessions on this Study; for configuration targets, the versions the form allows
Writes	On Save or Complete, a revision whose value lists target IDs; the session version records each target's label revision
Transaction	The study-scoped session commit; scope validated inside it
Derived after	Backlinks on the target ("Referenced by Pregnant · Housing location")

4.5 A reviewer records a relationship or set annotation

Save compiles it to a typed assertion, validates structure and records contradictions as flags. Nothing is inferred. On an opted-in project, the reviewer's own inference panel recomputes as TI §4.12 says.

4.6 A reviewer deletes a referenced record

The dialog lists the referencing answers (read from the reviewer's sessions on the Study). On confirm, one commit writes the withdrawal revisions of the record and its descendants. Referencing answers are unchanged and show the deleted marker; Complete refuses them until changed.

4.7 A designer publishes a shared concept or rule version

Writes the immutable version under the Design capability (Q-19). Earlier mapping answers stay pinned. A rule version can be published only where the project's inference beta is on (DQ-09, TI-R38; TI §4.11 recomputes dependent results); a shared-concept version needs only C1.

4.8 A reconciler matches records and reconciles references

Step	Detail
Reads	The task's pinned candidate session versions; MG1 suggestions; the form's blinding policy
Writes	The correspondence map version; at final submission, reconciled-scope records, references and relationships with provenance (RS)
Transaction	Map edits under the reconciliation task's compare-and-set; final submission as RS §4.4
Derived after	Dependent comparisons re-evaluated when the map changes; nothing is written to candidate scopes

4.9 An import with references

Preview runs both passes read-only and shows mappings, collisions and refused rows. Apply runs pass 1 and pass 2 per Study in one transaction, records aliases and is idempotent on replay (§3.4.7).

4.10 An export

Reads a causally closed cut at the export watermark (RI W13). Writes the export files with stable IDs, explicit relationships, requested inferred relationships with proof, overlap markers and codebook entries (RI-R59 to RI-R63).

4.11 A designer enables C1 for a project

Records an audited project setting with actor and time. Creates no per-Study document and changes no answer. Disabling stops new C1 writes and keeps every record readable.

5. Rules

5.1 Entity types

ID	Rule	Source
CPR-R01	Entity types carry capabilities and numbered child questions. The system EntityTypeIds minted at F1a are reused; C1 adds the aggregate, capabilities and project-defined types without re-identifying anything.	PROPOSAL (C13; DD-12)
CPR-R02	The capability set is closed and implemented by SyRF: ClassifiesAnimals, StructuredSubsets, and the system Cohort, OutcomeMeasure and Experiment capabilities. Designers configure known capabilities and never create new behaviour.	PROPOSAL (research §2.1)
CPR-R03	Templates default to the existing legacy entity types; cohort, outcome-measure and experiment types attach only when a form uses extraction or export.	OWNER TC1
CPR-R04	Entity types have immutable versions pinned by form versions. Presentation, guidance and an added capability are compatible; a removed capability, a changed label question or changed permitted parents are incompatible. A published type is retired, never deleted.	PROPOSAL
CPR-R05	Every entity type on a canonical form has exactly one label question; publication refuses a form that breaks this with FormVersionNotRenderable.	PROPOSAL (versioning model §4.3)

5.2 Named records and cohorts

ID	Rule	Source
CPR-R06	A named record's identity is its label head ID in the author's scope; rename, delete as withdrawal and duplicate with provenance follow VB-09.	PROPOSAL (VB-09)
CPR-R07	Equal labels, equal counts or equal positions never make two records the same, within or across Studies. Cross-paper meaning comes only from shared-concept mappings.	PROPOSAL (research §2.5, §8)
CPR-R08	A cohort records criteria, scope and coverage (Complete, Partial or Unknown, default Unknown). Coverage, exhaustiveness and form completion are distinct; a missing classification is unknown, never negative; a "Total" label never sets coverage.	PROPOSAL (research §1.2, §3.1)
CPR-R09	Cohort size is the answer to the system question with role CohortSize; no second editable count exists; analysed N is O1's separate role. Zero is a reported number.	PROPOSAL (research §2.3; C14)

5.3 Populations

ID	Rule	Source
CPR-R10	Every answer carries a population from its first canonical write. The default population's ID is derived from the Study ID; enabling C1 re-keys no answer.	PROPOSAL (C2; DD-24)
CPR-R11	Each population has a system whole-population cohort, complete for its own population by definition. It has a size only when one is recorded, is never counted as a reported group, and proves nothing about any other cohort's coverage.	Recorded owner direction (COMPARISON); guards PROPOSAL
CPR-R12	Every record belongs to exactly one population, fixed at creation. Relationships, set annotations, reference answers and rule applications never cross populations. A misplaced record is duplicated into the right population and the original withdrawn; combining populations waits for OD12.	Recorded owner direction (COMPARISON); mechanics PROPOSAL
CPR-R13	Additional populations are author-scoped records of the system population type and are matched in reconciliation; the default population needs no matching.	PROPOSAL (deviation, §12 item 5)
CPR-R14	Populations and cohorts change neither the Study count nor metaAnalysisIncluded.	PROPOSAL (C12; FX-PRISMA-06a)

5.4 Reference questions

ID	Rule	Source
CPR-R15	A reference question's value lists target IDs of declared target types and never labels. It is an ordinary answer with a value, not a reason no value is provided, and may offer the question version's reasons no value is provided and metadata fields (terms per DQ-46). An empty selection is unanswered, never "none".	PROPOSAL (extensibility architecture, future direction)
CPR-R16	The target contract (kind, types, scope, cardinality) is question-version content. Adding a type, widening scope or raising a maximum is compatible; removing a type, narrowing scope, lowering a maximum, changing single or multiple, or changing the kind is incompatible.	PROPOSAL (D2-03 pattern)
CPR-R17	Named-record targets are in the same Study, author scope and population, plus any same-parent rule; configuration targets are project-owned or system-owned and allowed by the pinned form version. The server checks on Save and Complete; any other reference is a structural error that blocks the commit.	PROPOSAL (research §2.2, §3.2)
CPR-R18	A picker offers only records the actor may see: a candidate's own records, or reconciled records for a reconciled answer. No search, count, label or event reveals another reviewer's records.	PROPOSAL (research §5, Permissions)
CPR-R19	A configuration-record answer pins the exact version; catalogue and project edits never change a submitted answer. A named-record answer records the target's label revision at commit.	PROPOSAL (research §4.5)
CPR-R20	A deleted target is never removed silently from referencing answers: deletion lists them first, they keep the ID and show a marker, and Complete refuses them, naming the question, until changed. A retired type or configuration record cannot be newly selected; existing answers stay valid and readable.	PROPOSAL (research §2.2)
CPR-R21	Today's five lookups become system question versions with system-owned target contracts and unchanged GUIDs. Until C1, legacy projects keep them, canonical forms admit the four cohort and experiment lookups when O1 admits extraction, and the server check gives today's results on shared fixtures.	PROPOSAL (D2-06; RD-R43)
CPR-R22	Designers create reference questions only from C1, under C1's project enablement; until then R1a's import keeps refusing lookup rows (ACD-R41).	OPEN timing (§10.2); rule PROPOSAL

5.5 Relationships, criteria and inference boundary

ID	Rule	Source
CPR-R23	Relationship and set annotations live on the parent or set with evidence, with backlinks on children. Disjointness and exhaustiveness are separate claims; answering one never implies the other.	Recorded direction (COMPARISON); PROPOSAL (C13; AC-C1-03)
CPR-R24	Each assertion is typed (Subset, Disjoint, Exhaustive, SameMembers, Composition) with scope, evidence kind, evidence metadata and author. A free-text note is never read as an assertion; strict subset needs evidence beyond subset.	PROPOSAL (research §2.2, §3.2)
CPR-R25	Structural errors (dangling or cross-population targets, invalid expressions, strict-subset or ownership cycles) block Save. Scientific contradictions are saved and flagged and never block Save or Complete.	PROPOSAL (research §3.2)
CPR-R26	C1 evaluates nothing: no inferred relationship, simplification, inferred group, proof or count. Every such result belongs to the opt-in inference beta (TI-R24 to TI-R36).	OWNER S5 beta opt-in (OS-A19); C1 row "No inference"
CPR-R27	Cohort criteria compile to an expression under a versioned grammar; C1 records conjunctions of option and record selections; an unsupported expression is preserved and marked Unsupported, never weakened.	PROPOSAL (research §3.1)
CPR-R28	No classification, Other and none-of stay distinct: unknown, a locally named concept, and an explicit complement within the scope.	PROPOSAL (research §7 gates)

5.6 Shared concepts and rules

ID	Rule	Source
CPR-R29	Design holders define shared concepts once per project, in immutable versions. Reviewers map local options or records to exact concept versions through mapping answers; a new version leaves earlier mappings pinned.	OWNER Q-19 (publication and mapping answers); versions and pinning PROPOSAL (AC-C1-04)
CPR-R30	Project rules are ClassificationRuleVersions of the four kinds only. Design publishes them, only in a project with the inference beta on; reviewers confirm per-paper applicability through rule-applicability answers; disagreements go through normal reconciliation.	OWNER Q-18, Q-19 (TI-R29, TI-R30); beta scope OWNER DQ-09, option (a) (6 October 2026; TI-R38)
CPR-R31	Rules connect specific concepts, not whole entity types, and apply within one population and a compatible membership and time context.	Recorded direction (COMPARISON F6); PROPOSAL

5.7 Reconciliation

ID	Rule	Source
CPR-R32	Before comparing answers that depend on records, the reconciler confirms an immutable correspondence map (match, split, distinguish) starting from SyRF's suggestions; reference answers are then compared through the map, never by label, count or position.	OWNER MG1 (suggest and confirm); map PROPOSAL (research §2.5)
CPR-R33	Reconciled answers reference reconciled records; candidate graphs and the map are kept as provenance; reference answers get no click-to-fill hints until RS-R37's correspondence rule exists.	PROPOSAL
CPR-R34	Under identity blinding the reconciliation view shows candidates' records and relationships under candidate labels only; nothing reveals identities or a candidate's records to anyone without access to the task.	PROPOSAL (RS blinding; research §2.5)

5.8 Import, export and adoption

ID	Rule	Source
CPR-R35	Answer imports resolve in two passes: records by stable source ID first, then references and relationships through that map. Unresolved targets refuse or quarantine the row with a named reason; labels are never used; preview equals apply; each Study commits atomically.	PROPOSAL (research §5, Import)
CPR-R36	Question imports resolve reference target types by EntityTypeId or a stable type key in the file or project; otherwise the row is refused with a named reason and nothing is created.	PROPOSAL (ACD-R40)
CPR-R37	Exports carry stable population, cohort, record and reference IDs beside labels, explicit relationships by default, inferred relationships only on request with proof, and the overlap markers of RI-R59 to RI-R63.	PROPOSAL (research §5, Export)
CPR-R38	The legacy category string becomes a display alias of EntityTypeId; every question, answer, guidance item and export column stays reachable; no classification meaning is backfilled.	PROPOSAL (VA-25; AC-C1-08)
CPR-R39	C1 has its own per-project enablement, separate from the inference beta. Enabling creates no per-Study document and changes no answer; disabling stops new C1 writes and keeps everything readable.	OWNER S5 beta opt-in (the beta does not switch on C1); setting PROPOSAL
CPR-R40	Baseline conversion maps labels and lookups faithfully: label annotations become records with their original IDs in the default population, lookup answers become reference answers with the same targets, and outcome-data keys are unchanged. Nothing about coverage, relationships, populations or concepts is inferred.	PROPOSAL (research §6; BC)
CPR-R41	Nothing on this page authorises implementation, migration, activation, notification delivery or sending the design pack.	OWNER hold, 5 October 2026

6. Authorisation, blinding and provenance

Action	Capability (NEW = proposed)	Further checks	Provenance recorded
Create or change entity types, reference questions and shared concepts in a draft	Design on the project	Base revision checks (RD-R26)	Design draft changes
Publish forms that pin them	NEW Publish review definitions (the approved Q-03 matrix)	Publication impact (C4)	Form version, actor, time
Publish concept versions	Design on the project (Q-19)	None	Version, actor, time
Author and publish rule versions	Design on the project (Q-19)	The project's inference beta is on (DQ-09, TI-R38)	Version, actor, time
Enable or disable C1	Design on the project	None	Setting history
Record records, relationships, references and mapping answers	Review on a stage that binds the form	Scope (CPR-R17)	Revision provenance (C3)
Reconcile records and references	Reconcile on the form's task	Blinding (RS)	Map version; reconciled revisions with derivedFrom
Import answers	XA1's import capability (later lane)	Two-pass resolution	Import job, aliases
Export	The C10 export disclosure contract	Disclosure matrix	Export manifest (C11)

• Server authority. Every read and command checks scope, permission and blinding. A request naming another reviewer's record gets the same response as a missing record, so it reveals nothing.
• Inference visibility follows TI-R31 and TI-R32: a candidate's inference is private to that reviewer; collective inference follows accepted-answer access.
• History events (C20 envelope; names PROPOSAL): EntityTypeVersionCommitted, SharedConceptPublished, ClassificationEnabledChanged, RecordCorrespondenceConfirmed. TI already names ClassificationRulePublished.

7. Active-work impacts

Change	Warned before commit	Recheck at commit	Notified after (capture only; delivery not authorised)	Apply anyway
Publish a form version that changes a reference contract incompatibly	Affected sessions by category (RD §4.8)	Usage and the preview digest	Affected reviewers, one notice each (Q-20)	Not applicable
Retire an entity type or configuration record	Forms pinning it; drafts using it	Head pointer	Designers	Not applicable
Publish a new concept or rule version	Mapping answers pinned to the old version	Head pointer	None needed	Not applicable
A reviewer deletes a referenced record	Referencing answers in their own sessions (in-form warning, Q-20)	Session base	None	The reviewer confirms
A reconciler changes the correspondence map	Dependent comparisons that will change	Task compare-and-set	None	The reconciler confirms
Enable or disable C1	What reviewers will see; that nothing is deleted	Setting history	Designers	Not applicable

8. Failure and recovery

Failure	Behaviour	Recovery
A target is deleted in another tab before Save	Save returns a typed conflict naming the question; the draft is kept	The reviewer reloads and chooses another target
A crafted request references another scope, Study or project	Refused with the same typed 400 as a missing target, so nothing is revealed; nothing written	None needed
An import row has an unresolved target	That row is refused or quarantined; nothing is written for its Study	Fix the file or map the target; replay is idempotent
The map changes while a reconciled answer depends on it	Expected-revision conflict; dependent answers re-evaluated only	The reconciler reviews the flagged answers
An expression outside the grammar arrives (import or newer client)	Preserved and marked Unsupported	A later grammar version reads it
A Study has very many cohorts	Pairwise views are paged; validation stays per change set (research §3.4)	Budgets measured on the largest pilot (CPR-AE29)
A legacy export consumer reads a C1 project	Legacy columns unchanged; new tables are additional	None needed

9. User flows and examples

Example project. "Livestock TB evidence review (example)", as in the v10 prototype. People: designer Aisha Rahman, reviewers Priya Shah and Omar Haddad, reconciler Ewan Fraser, owner Daniel Okafor. All Studies and numbers are synthetic.

9.1 Setting up types and a reference question

Aisha starts from the template. Disease model and Treatment appear with their legacy names (TC1). She adds a project type "Location" with ClassifiesAnimals and StructuredSubsets, and on the cohort type a reference question "Housing location" that targets Location records, multiple, same population, with Not reported allowed. She publishes form version 2; the preview lists completed sessions and asks how the new required question should treat them (RD §4.8).

9.2 The farm paper (research §4.2), beta off

On S-0730 Priya records, in the default population "Enrolled cattle":

• the whole-population cohort's size, 120, quoting page 3;
• Location records Farm A and Farm B, with a set annotation on the population: disjoint (reported) and exhaustive (reported);
• cohorts "Farm A animals" (Location = Farm A, complete, 70) and "Farm B animals" (complete, 50);
• an age set, Young and Adult, also disjoint and exhaustive (a second, independent set annotation);
• cohort "Female" (complete, 70) and cohort "Pregnant" (criteria Pregnant, size 20), with the concept mapping answer "Pregnant means shared concept Pregnant v1" (no rule exists, because rules need the beta, DQ-09);
• a cohort "Farm A juveniles" beneath "Farm A animals"; no Farm A and sex intersection count is invented.

Nothing is inferred. The export lists both partitions with their recorded sizes, flagged as two partitions of the same population; it never adds groups up, so 240 never appears (RI-R61, RI-R62). If the project opts into the beta, Aisha can publish the rule "Pregnant ⊆ Female", Priya answers "Rule Pregnant ⊆ Female v2: Applies", and TI §9.6 shows "Pregnant is contained in Female; animals across both: 70". Changing Female's coverage to Partial changes nothing in C1; the beta supersedes its own result (TI §9.7).

9.3 Deleting a referenced record

Priya starts to delete Farm A. The dialog says "Referenced by: Pregnant · Housing location; Farm A animals · criteria; the population's Location set". She cancels. On another Study, Omar deletes a Location that a cohort references; the cohort's answer shows "Refers to a deleted record" and Complete names the question until he picks another location or records Not reported.

9.4 Blinded reconciliation

Ewan reconciles S-0730. Reviewer 1 recorded Farm A and Farm B; Reviewer 2 recorded "Farm 1", "Farm 2" and "Pasture". SyRF suggests Farm A with Farm 1 and Farm B with Farm 2 (sizes 70 and 50 match; labels differ). Ewan confirms both and marks Pasture as distinct (one reviewer only). Reviewer 1's Pregnant references Farm A and Reviewer 2's references Farm 1: after the map they agree. Ewan's accepted answer references the reconciled record "Farm A". Neither reviewer's name appears.

9.5 The diabetes sub-study (research §4.3)

The parent project and the diabetes sub-study use different screening profiles. On S-0815 Omar records a Diabetes classification on two of three cohorts and leaves the third unanswered, because the form pins that classification question as optional. The export shows the third as "unknown", not "not diabetic". Classification never changes a screening decision, and which cohorts enter an analysis is a separate selection made downstream.

9.6 Outcome counts and a shared control (research §4.4)

On S-0902 cohort C has size 20; its week-3 series has analysed N 18 (O1). Two comparisons use the same control series. The analysis-ready export carries one observation ID on both comparison rows, flags it sharedControl, and never adds the control's animals twice (RI-R61; AC-X1-01).

9.7 Imports

Daniel imports a question template whose reference question targets "Location", defined in the same file: it resolves. A second row targets "Housing", which is neither in the file nor the project: "Row 22: reference target type 'Housing' is not in this file or project", and nothing is created. In the later XA1 lane an answer file's records are created first, then its references; a row naming an unknown record ID is quarantined with its reason.

9.8 Screen states for the reference picker and record pages

State	What the reviewer sees
Loading	"Loading records"
Empty	The question's empty-state text, for example "Add a Location first", with an add action
Pending	"Draft auto-saved" beside an unsaved selection (wording per UX)
Incomplete	"2 of 5 cohorts answered"
Completed	Selected records as chips with labels and population
Unavailable	"No records of this type can be referenced here" (wrong population or no access)
Historical	The label each target had when the version was saved
Conflict	"This record was deleted in another tab. Choose again."
Failure	"Refers to a deleted record" on the answer; Complete names it

10. Rollout and adoption

10.1 C1 increments and their gates

Increment	Release or lane	Entry dependencies	Flag decision (PROPOSAL)
C1a: entity-type aggregate, capabilities and project types; tabs to entity types; populations and the whole-population cohort; cohort criteria, scope and coverage	C1	F-C (C13); R2a; E14 catalogue checks; U3 passed	A per-project C1 setting and an environment kill switch: C1 spans services, changes stored meaning and needs per-project rollout
C1b: custom reference questions (authoring, picker, scope checks, pinning, deletion and retirement, question import)	C1	C1a; R2c for contract changes on used forms	The same setting
C1c: relationship and set annotations; shared concepts and concept mapping answers as records (6 October 2026: rule versions and rule-applicability answers are not in C1c; they belong to the beta, lane C2, under DQ-09 option (a), TI-R38)	C1	C1a; Q-19 (decided)	The same setting; rule pages behind the beta's opt-in
C1d: reconciliation of records, references and relationships (correspondence map, blinded view)	C1, after R4a	R4a; F4 (C9 matching); MG1	The same setting
C1e: exports with stable IDs, explicit relationships and overlap markers; codebook entries	C1 export slice; analysis-ready rows in X1	F1b (C11); RI-R59 to RI-R63	The export flags of each release
System lookups as system reference contracts	O1 (canonical extraction)	D2-06; RD-R43; X-PDFTOOLS for the PDF-graph lookup	O1's flag

Gates: brief approval for T-CP-00, G0 (T-G0), the hold lift (T-HOLD) and the F-C freeze (entry: the sitting-7 decisions answered; Q-19; E14; U3 passed). None has happened. Disabling the C1 setting stops new writes and admission and never hides saved work (research §7, Feature flags).

10.2 The GA question (OPEN)

Recommendation: reference questions arrive with C1 and are not a GA prerequisite, unless a GA form needs one.

• Legacy SyRF has no custom reference questions (§3.4.1, verified), so new canonical projects lose nothing before C1.
• Today's five fixed lookups keep working throughout (CPR-R21): unchanged on legacy projects, and as system reference contracts on canonical forms once O1 admits extraction.
• The rollout plan's Phase 6 lanes, C1 among them, do not hold GA.
• If a GA pilot form does need a custom reference, C1b moves before GA. Its entry needs only C1a, not the relationship, rule or reconciliation increments; reconciling such answers before C1d would need RS's correspondence rule early.

10.3 Baseline conversion of today's labels and lookups

Legacy thing	Baseline target	Never inferred
Label annotations (disease model induction, treatment, outcome assessment, cohort, experiment)	Named records in the default population, identity from the original annotation ID through LegacyIdAlias, typed by the category's system EntityTypeId	Coverage (stays Unknown), populations other than the default, concept mappings
The four label lookups (cohort → disease models, treatments, outcomes; experiment → cohorts)	Reference answers on the system reference question versions with the same target IDs, translated through the alias table	Any set relationship: a lookup link means "uses", never "subset of"
The PDF-graph lookup	A reference answer on its system question, same target IDs	Graph meaning
A lookup ID that resolves to nothing	A conversion finding (proposed code UnresolvedLegacyReference); the ID is preserved and labelled, never dropped	A guessed target
Disease Model and Treatment control flags; outcome-data triples	Unchanged (export dependencies; O1's legacy-compatible schema)	New comparison semantics

Conversion enables neither C1's new authoring nor the inference beta (TI-R24). The redesign wizard (RW1) can enable C1 later through ordinary publication.

10.4 Baseline, MVP and opt-in

• Delivery-scope lane. C1 is planned and in scope, scheduled after its dependencies, and not a GA prerequisite. No date is implied.
• Opt-in. C1's project setting is off by default; the inference beta is a separate opt-in (TI).
• Pilots. Seeded projects in preview and staging only (the "Classification and outcomes" seed). Production pilots need their own approval.

10.5 Deferred

Inference (C2 beta, TI); OD12's breadth (rule chaining, set algebra, ontology authoring, population merging, cross-type count solving); temporal membership reasoning (research U7); observation and comparison identity beyond today's Experiment key (research U6b); click-to-fill hints for references (RS-R37); cross-Study references.

11. Acceptance evidence

ID	Evidence	Method	Amends
CPR-AE01	The default population ID is derived from the Study ID; enabling C1 changes no answer key; each population has a whole-population cohort; each record belongs to exactly one population	Conformance; integration	AC-C1-01, AC-C1-02
CPR-AE02	A relationship, set annotation or reference across populations, Studies, projects or author scopes is refused at Save with a typed error and nothing is written	Integration	New
CPR-AE03	A whole-population cohort with no recorded size shows "size not reported"; no export counts it as a group; its existence changes no other cohort's coverage	Conformance	New
CPR-AE04	Farm fixture with the beta off: the farm and age partitions, Female (complete, 70) and Pregnant (20) are stored as separate typed assertions; no inferred relationship or total is stored or shown; no figure of 240 appears anywhere	Conformance	AC-C1-03
CPR-AE05	Disjoint without exhaustive, and exhaustive without disjoint, are stored independently; strict subset needs evidence; a free-text "subset of" stays a note	Conformance	AC-C1-03
CPR-AE06	A subset recorded larger than its superset saves, is flagged and does not block Complete; a cycle or a dangling target is refused at Save	Integration	New
CPR-AE07	Equal labels in two Studies, two same-labelled records in one Study and equal counts never establish identity; reconciliation requires an explicit map	Conformance	New
CPR-AE08	Coverage defaults to Unknown; no reader treats Partial or Unknown as Complete; a "Total" label sets no coverage	Conformance	New
CPR-AE09	No classification, Other and none-of stay distinct in storage, validation and export	Conformance	New
CPR-AE10	Round trip: a designer creates "Housing location" targeting Location; a reviewer selects two records; the answer stores IDs; renaming a target changes the display only; history shows the label at commit	Integration; end-to-end	New
CPR-AE11	Target-contract compatibility fixtures: an added type is compatible; a removed type, narrowed scope, lowered maximum, single-to-multiple change or kind change is incompatible	Conformance	New (C4 fixtures)
CPR-AE12	A candidate's picker lists only their own records; API probes with another reviewer's record IDs get the same response as a missing record	Integration; API permission test	New
CPR-AE13	Deleting a referenced record lists its references first; afterwards the answer keeps the ID and shows the marker; Complete refuses it, naming the question; nothing is removed silently	Integration; end-to-end	New
CPR-AE14	A configuration-record answer pins its version; editing the catalogue changes no submitted answer; another project's record or an unavailable version is refused	Integration	New
CPR-AE15	On shared fixtures the five system lookups give the same accept and refuse results under the system target contracts as under today's fixed map and outcome-data checks; their GUIDs are unchanged	Conformance	New (with RD-AE34)
CPR-AE16	Before C1 is enabled no designer can create a reference question, and R1a's import refuses lookup rows with a named reason	Integration	ACD-AE34
CPR-AE17	Question import resolves reference target types by EntityTypeId or a stable key; an unknown type refuses its row, naming row and column; preview equals apply	Integration	AC-R1a-01, AC-R1a-02
CPR-AE18	Two-pass answer import creates records then references; an unresolved target is quarantined; no label matching occurs; replay is idempotent	Integration	New
CPR-AE19	Reconciliation requires a confirmed map before dependent comparisons; references compare through it; a split or match keeps both input histories; a map change re-evaluates only dependent answers	Integration; conformance	AC-R4a-02
CPR-AE20	Under identity blinding no reviewer identity appears in the reconciliation view; no user without task access receives a candidate's records through pickers, search or realtime events	Integration; API permission test	New
CPR-AE21	A new concept or rule version leaves earlier mappings pinned; only Design holders publish; mapping disagreements go through ordinary reconciliation. DQ-09: a rule version is publishable only with the project's beta on, while concept versions and concept mapping answers work with the beta off (TI-AE27)	Integration	AC-C1-04, AC-C1-09
CPR-AE22	After the move to entity types every question, answer, guidance item and legacy export column is reachable and unchanged; the category string is a display alias	Integration; end-to-end	AC-C1-08
CPR-AE23	Templates use the legacy types by default; system cohort, outcome-measure and experiment types appear only when a form uses extraction	Integration	AC-C1-07
CPR-AE24	FX-PRISMA-06a passes; compact cohort selection meets the U3 pass bar	User test; conformance	AC-C1-05
CPR-AE25	With C1 off the annotation suites pass and no C1 screen appears; enabling writes only setting history; disabling keeps everything readable	Integration; regression suite	New
CPR-AE26	Conversion fixture: labels become records with their original IDs, lookup answers become reference answers with the same targets, a dangling legacy ID becomes a preserved finding, nothing is inferred, and the legacy export is identical	Conformance; integration	New (BC parity)
CPR-AE27	Exports carry stable IDs and explicit relationships by default, inferred ones only on request with proof, and the RI-R59 to RI-R63 markers (RI-AE41 to RI-AE45)	Conformance	AC-C1-10
CPR-AE28	An unsupported expression round-trips unchanged, is marked Unsupported and is never weakened	Conformance	New
CPR-AE29	Picker load, reference validation and paged pairwise views are measured on the largest pilot Study before wider enablement (budgets set in the brief, not approved)	Benchmark	New
CPR-AE30	The picker, record pages and cohort selector work by keyboard, touch and screen reader on phones, tablets and desktops	End-to-end; accessibility	New
CPR-AE31	A designer from the tester panel creates an entity type and a reference question without help	User test (D3-08 panel)	New

12. Brief items, specialist inputs and unapproved proposals

Open questions, each with a recommendation.

#	Question	Options	Recommendation	Tracker
1	Are custom reference questions needed at GA, or do they come with C1?	(a) With C1, not a GA prerequisite; (b) before GA as a separate slice	(a), unless a GA form needs one (§10.2): nothing regresses, because custom lookups do not exist today and the fixed lookups keep working	T-CP-00 (owner-visible)
2	Which target types?	(a) Named records only (definitions, cohorts, outcome measures, experiments, populations); (b) (a) plus configuration records (shared-concept versions; rule versions for applicability answers, which exist only with the beta on, DQ-09); © (b) plus other Studies and source regions	(b). Cross-Study references wait for the deferred report grouping (D4-08) and cross-Study blinding rules; source regions stay system-only (the PDF-graph lookup); outcome-schema versions keep C14's dedicated system question	T-CP-00 (owner-visible)
3	Export overlap markers	(a) RI-R59 to RI-R63 as written; (b) markers only in X1's analysis-ready file	(a): every export that carries groups needs them, or a consumer can double count	T-CP-00, T-RI-00
4	What does the inference beta cover (DQ-09)? Decided 6 October 2026. The S5 amendment says the "advanced classification/rule/inference capability" starts in beta	DQ-09's options were: (a) the beta covers rule authoring, rule evaluation and inference results, while C1's explicit recording follows its own enablement; (b) the beta also gates C1's explicit classification; © rule authoring and publication sit in C1, outside the beta, and only rule evaluation and inference sit in the beta	Decided: option (a) (Chris, 6 October 2026; decision register §1.18). Rule authoring and publication, rule evaluation and inferred results require explicit project beta opt-in; explicit recording, shared concepts and per-paper concept mappings stay in C1. Option ©, this page's earlier PROPOSAL, is not adopted; §3.7, CPR-R30, §10.1 C1c and §13 now follow (a). A class B clarification that changes no delivery date	T-CP-00 with T-TI-00
5	Populations as author-scoped records of a new system population type. This departs from the domain model's Study-level AnimalPopulation, from COMPARISON's "Study populations" row ("Define as a system role on the cohort structure") and from research §1.2 item 6 ("Do not add a second Population entity duplicating Cohort")	(a) Author-scoped records of a new system population type; (b) a Study-level aggregate shared by every reviewer; © the whole-population cohort as the population record: an additional population is recorded as an author-scoped cohort with the WholePopulation system role, and that record's ID is the populationId, so no separate population type exists	(a) (PROPOSAL): (b) shows one reviewer's populations to others and breaks independence; a collection only if the F-C storage ADR measures a need. © keeps COMPARISON's cohort-role shape and the research's single entity, and the F-C storage ADR weighs it against (a)	T-CP-01
6	A deleted target in a referencing answer	(a) Keep the ID, mark it, refuse Complete; (b) remove it automatically in the same commit	(a): no silent change to an answer (Q-27's spirit)	T-CP-00
7	Direct contradiction warnings in C1	(a) Warn only on two explicit facts about the same pair (a subset recorded larger than its superset); (b) no warnings without the beta	(a), as a non-blocking validation of recorded facts; anything chained is the beta's	T-CP-00
8	Coverage value names (Complete, Partial, Unknown)	Copy deck	UX owns the wording	T-UX-00

Brief items. E14 (entity-type catalogue and alias validation at F-C); E7 (match scoring, absent features, ties, groups larger than two); U3 and RC8 (cohort selection and population placement, user validation); the criteria grammar version and its reader and writer contract; rule-applicability values; history event names; performance budgets (CPR-AE29).

Specialist and owner inputs. The first classification pilot project (research §8, item 1); a methodologist review of the coverage values and relationship kinds before the F-C freeze, recorded under T-CP-00. No new specialist row is proposed.

Proposals an owner may want to see. CPR-R13 (author-scoped populations); CPR-R20 (deleted targets); CPR-R21 (system lookups until C1); CPR-R22 (no designer references before C1); CPR-R39 (C1's own setting); RI-R62 (no sums over overlapping groups).

Naming. Decided (DQ-46, 6 October 2026): this page uses "reason no value is provided" for the earlier working term and Answer status for the overall state; "Other, please specify" is a value (RD §3.16). "No value to enter" is illustrative action wording.

13. Amendments to existing package documents

Written to be applied as listed. Planning only; implementation remains on hold.

• contracts.md → C13.
• Add after the first paragraph a line citing this page: "Specification: CPR", linked to specifications/spec-classification-populations-and-references.md.
• Entity types: the closed capability set (CPR-R02); EntityTypeVersions pinned by form versions (CPR-R04); one label question per type (CPR-R05); a new system population type minted at F-C.
• Populations: replace "Each study population has a system whole-population cohort; every instance belongs to exactly one population" with CPR-R11 to CPR-R13 (whole-population cohort guards; one population per record, fixed at creation; author-scoped additional populations).
• Relationships: add the five kinds, scope, evidence kind and the structural-versus-scientific rule (CPR-R23 to CPR-R25).
• Concepts: mapping answers reference exact concept versions; rule-applicability answers per population and rule version (CPR-R29, CPR-R30).
• New paragraph "Custom reference questions": the target contract, scope rules, pinning, deletion and retirement, correspondence-first reconciliation and two-pass import (CPR-R15 to CPR-R22, CPR-R32 to CPR-R36).
• Enablement: "C1 has its own per-project setting, separate from the inference beta" (CPR-R39).
• Conformance tests: add C13-T06 (a cross-population or cross-scope reference is refused), C13-T07 (target-contract compatibility fixtures), C13-T08 (picker and API isolation), C13-T09 (references compare only through a confirmed map) and C13-T10 (system lookup parity), all PROPOSAL.
• contracts.md → C2. Add: "A reference answer stores its target IDs in the typed payload, never in the key; a reference is not an owningParent edge. For a record in an additional population, populationId is that population record's ID in the author's scope, fixed at the record's creation." Conformance: "a reference never re-keys its target; withdrawing a target leaves referencing answers unchanged and marked".
• contracts.md → C4. Question-version content gains referenceTarget {targetKind, targetEntityTypeIds[] or configurationKind, scope, cardinality, emptyStateText}. The compatibility suggestion gains the §3.4.4 rows. The system question row adds: "the five lookup questions carry system-owned target contracts (CPR-R21)". The form-version row changes "entity types present" to "pinned entity-type versions". Add C4-T23 (PROPOSAL): the CPR-AE11 fixtures.
• contracts.md → C14. Add: "The system schema-selection question uses C4's referenceTarget shape with targetKind = ConfigurationRecord and configurationKind = OutcomeSchemaVersion; it stays system-owned, designers cannot create schema reference questions, and it does not need C1. Series key on the cohort, outcome-measure and experiment record IDs of CPR §3.2. Shared controls are flagged in exports (RI-R61)."
• domain-model.md.
• §4.6: replace the AnimalPopulation row with "Population records: author-scoped named records of the system population type (label heads in Evidence); the default population is derived and needs no document; each population has a derived whole-population cohort; pmAnimalPopulation only if the F-C storage ADR measures a need (CPR §3.3)".
• §4.5: EntityType gains pmEntityTypeVersion and the closed capability set; SharedConcept gains append-only versions.
• §4.3: add RecordCorrespondenceMap (versioned, per reconciliation task).
• §7.2: add the ReferenceTarget value object.
• §6.2 and §6.3: add the §6 events and the commands CommitEntityTypeVersion, PublishSharedConceptVersion, SetClassificationEnabled and ConfirmRecordCorrespondence.
• §8 glossary: named record, population, whole-population cohort, coverage, set annotation, mapping answer, reference question.
• §10: population IDs (default derived; additional ones author-scoped). §12 C1 row: as above.
• spec-review-domain-and-versioning.md (RD), which another writer edits in this PR. §3.4: add "Reference questions carry a target contract as version content (CPR §3.4.2)". RD-R30: add "A change of reference target kind, or between single and multiple targets, is incompatible in the same way (CPR-R16)."
• spec-training-and-inference.md (TI), which another writer edits in this PR. Companion list: add CPR. §3.7 "What it is not": cite CPR-R39 for C1's own setting. §3.8: cite CPR §3.6 and §3.7 for concept and mapping authoring in C1. Revised 6 October 2026 (DQ-09 decided as option (a)): rule authoring and publication sit inside the beta, not in C1, and option © is not adopted; §12 "Scope of the beta" records the decision (TI-R38). The earlier amendment ("this page's PROPOSAL (option ©, pending DQ-09) that rule authoring sits there too"; "list option ©") is withdrawn.
• spec-baseline-conversion.md (BC), which another writer edits in this PR. §3.4: add the §10.3 rows (label annotations, label lookups, the PDF-graph lookup, unresolved lookup IDs) and the finding code UnresolvedLegacyReference (PROPOSAL).
• integrated-plan.md → §5.8 C1 row. Add "Specification: CPR"; replace "animal populations (AnimalPopulation) with a whole-population cohort" with "populations (default derived; additional ones author-scoped records) with a whole-population cohort that carries no size unless recorded"; add "custom reference questions (CPR §3.4): designer-defined, scoped, pinned and reconciled through a correspondence map; arriving with C1 and not a GA prerequisite unless a GA form needs one (open)"; acceptance adds CPR-AE01 to CPR-AE31. X1 row: add "overlap and relationship markers (RI-R59 to RI-R63)". §5.3 R1a acceptance ("parents and lookups are remapped"): lookups are refused until C1 (ACD-R41, CPR-R22).
• specifications/design-prototype-handoff.md.
• DH-C15 (c1 Concepts & rules): concepts and concept mapping answers are records in C1 and show without the beta; 6 October 2026 (DQ-09 decided as option (a)): the rule pages, rule versions and rule-applicability answers sit behind the beta's opt-in, with no "To be decided" chip; the inference panel stays behind the beta. Option © is not adopted.
• DH-C16 (c2 entity types): capabilities, project-defined types, a label question per type.
• DH-C18 (c4 to c6, c9, c10): the default population, "Add population", the whole-population cohort with "Size not reported", coverage on every cohort, set annotations with evidence.
• New changes: the reference question type in the editor (target types, scope, single or multiple, empty-state text) with a "Later release" badge; the reviewer picker and its §9.8 states; the deletion dialog that lists references; the reconciliation correspondence step before reference comparison.
• New open items: GA timing and target types (§12, items 1 and 2).
• implementation-tracker.md. A new workstream CP with the rows in the table at the end of this section.
• acceptance-criteria.md. §4.25: amend AC-C1-01 to AC-C1-05, AC-C1-07 to AC-C1-10 per the Amends column of §11; add rows for the new CPR-AE items; extend FX-CLASS with the reference, deletion, correspondence and conversion fixtures; §7.5 adds C13-T06 to C13-T10 and C4-T23.
• question-management-plan.md. M-23, M-24 and M-30: note that the lookups convert under CPR §10.3 and become system reference contracts (CPR-R21); §6.2 R1a: lookup rows stay refused until C1.
• unified-annotation-classification-research.md → §7, U2. Note that custom references land in C1 (CPR §3.4), and answer metadata follows the 6 October 2026 directions in RD and the versioning model.

Tracker rows for workstream CP (owner Stream E (L9), with C for screens; brief and implementation "Not started" and "On hold"; the integration fills the remaining columns).

ID	Scope	Depends on	Spec sections	Acceptance evidence	Release or gate
T-CP-00	Brief: classification, populations and references	T-TI-00 (beta scope, decided by DQ-09 on 6 October 2026); T-RS-00 (correspondence); T-RI-00 (markers)	CPR §1 to §14	CPR-AE01 to CPR-AE31	F-C (brief parts)
T-CP-01	F-C: the C13 ADR (capabilities, entity-type versions, populations, relationship kinds); the C4 target contract	T-CP-00; F1a EntityTypeId	§3.1 to §3.5	CPR-AE01, CPR-AE11	F-C
T-CP-02	C1a: entity types, tabs to types, populations, cohort criteria and coverage	T-CP-01; R2a	§3.1 to §3.3, §3.8, §3.9	CPR-AE01 to CPR-AE03, CPR-AE07 to CPR-AE09, CPR-AE22 to CPR-AE25	C1
T-CP-03	C1b: custom reference questions and question import	T-CP-02; R2c	§3.4	CPR-AE10 to CPR-AE14, CPR-AE16, CPR-AE17	C1
T-CP-04	C1c: relationships, shared concepts, concept mapping answers (6 October 2026: rule versions belong to the beta under DQ-09, T-TI-00)	T-CP-02	§3.5 to §3.7	CPR-AE04 to CPR-AE06, CPR-AE21, CPR-AE28	C1
T-CP-05	C1d: reconciliation of records, references and relationships	T-CP-03; R4a	§3.4.6	CPR-AE19, CPR-AE20	C1, after R4a
T-CP-06	C1e: exports and codebook with RI's markers	T-CP-02; F1b	§3.9; RI §3.9	CPR-AE27; RI-AE41 to RI-AE45	C1; X1
T-CP-07	System lookups as system reference contracts	O1; D2-06 seed	§3.4.8	CPR-AE15	O1
T-CP-08	Baseline conversion of labels and lookups	T-BC-01	§10.3	CPR-AE26	R6 waves
T-CP-09	Two-pass answer import and performance and accessibility evidence	T-CP-03; XA1	§3.4.7; §11	CPR-AE18, CPR-AE29 to CPR-AE31	XA1; C1

Design-handoff answers, 6 October 2026 (Chris, Codex discussion; record archived at owner-session-2026-10-05/syrf-design-decisions-2026-10-06.md.txt; decision register §1.18). DQ-09 is decided as option (a): rule authoring and publication, rule evaluation and inferred results require explicit project beta opt-in; ordinary annotation and explicit group or classification recording follow their own availability. Option ©, this page's earlier PROPOSAL, is not adopted. This page now carries the change in the companion note, §1, §2, §3.7, §4.7, CPR-R30, §6, §9.2, §10.1 (C1c), CPR-AE21, §12 items 2 and 4, the "Proposals an owner may want to see" list (§3.7 removed), the TI and DH-C15 amendments above, the tracker rows and §14. Lane C1 keeps explicit recording, shared concepts and per-paper concept mappings; versioned project rules are authored only with the beta on. DQ-46's terms reach §3.4.2, CPR-R15 and the §12 naming paragraph. This is a class B clarification: it does not accelerate classification delivery, introduce a separate review workflow or authorise implementation, and the GA timing and target types of reference questions (§12 items 1 and 2) stay open. Updated in the same change: TI (TI-R38, TI-AE27), contracts C13, the domain model and the versioning model §16.5.

14. Superseded wording

Old wording	New wording	Where it appears today
"Do not invent an empty 'all animals' cohort solely to complete a hierarchy. Do not add a second Population entity duplicating Cohort"	Each population has a whole-population cohort (later owner direction); it carries no size unless recorded and proves nothing about other cohorts (CPR-R11). The new population type of CPR-R13 (PROPOSAL) departs from the second sentence; §12 item 5 offers the whole-population cohort as the population record instead	Research §1.2 item 6, §3.1
AnimalPopulation as one Study-level aggregate holding the population, its whole-population cohort and instance membership	Author-scoped population records; the default derived; a collection only on measured need (CPR-R13, PROPOSAL; the departure from COMPARISON's cohort role is flagged in §12 item 5)	domain-model §4.6, §10, §12; C13; integrated-plan C1 row
Reference responses "deliberately unspecified"; no user requirements yet	Specified here as PROPOSAL (CPR §3.4)	Extensibility architecture, "Future direction"
"Parents and lookups are remapped" in R1a acceptance	Lookup rows are refused with a named reason until C1 (ACD-R41, CPR-R22)	integrated-plan §5.3 R1a acceptance; FX-SETUP-03
"Exports include populations, cohorts and mappings"	Plus stable IDs, explicit relationships by default, inferred only on request with proof, overlap markers (CPR-R37)	AC-C1-10
U2 "metadata and custom references" as one phase	Custom references in C1 (CPR §3.4); answer metadata under the 6 October 2026 directions (RD)	Research §7
Rule authoring and publication in C1, outside the beta (this page's PROPOSAL, option © of DQ-09)	Rule authoring and publication, rule evaluation and inferred results need the inference beta; C1 keeps explicit recording, shared concepts and concept mappings (DQ-09, option (a), Chris, 6 October 2026; TI-R38)	Earlier text of this page (§1, §2, §3.7, §10.1, §12 item 4, §13); TI §3.8 and §12; handoff DH-C15; design-handoff-open-questions.md DQ-09