Adjudicate: do target profiles and measurement bindings belong in Chronicle? The boundary records disagree #166

PR #164 (the uk_national profile, #133's closing deliverable) is complete, review-hardened, and verified — and is now held in draft pending a ruling on this question, because review discussion surfaced that the two generations of boundary documentation contradict each other and the US and UK implement opposite patterns. This is a repo-responsibility question, not an implementation detail, so it deserves an explicit ruling rather than being settled by whichever PR merges next.

The question

Where does the selection contract over calibration-target facts live — the value-free declaration of which facts a build may target, what they measure, and how they bind to model variables?

• Pattern A (US, operative today): Chronicle stores facts only; the consumer owns everything — microcosm/build/us/fiscal_target_references.json (value-free references, allowed_value_operations: ["identity"]) resolves against a hash-pinned Chronicle consumer artifact. No US profile exists in Chronicle.
• Pattern B (UK, operative today): Chronicle also carries value-free target profiles (uk_local_geography, uk_firms, in-flight uk_national with 186 targets) under a governed authoring lane; the consumer keeps activation, the active subset, values, and metric computation (populace#622/#623).

The documentary record

Founding charter and first-generation docs assign the contract to the consumer:

• PR Establish Arch data foundation #1 (2026-04-27): the facts repo owns "target inputs"; the consumer owns "source selection, reconciliation, aging, activation profiles" and "calibration profiles".
• docs/target-construction-harness-plan.md (PR Add Arch source package core harness #7, 2026-05-27, still on main): "Chronicle should not own active target specs"; "Active target specs should start in Microcosm"; recommendation places "target contracts, active target profiles" in Microcosm; "Microcosm may … bind source-derived target values to model-side measures through explicit target contracts."
• docs/pe-calibration-targets.md (PR Add US poverty target coverage contract #53, 2026-06-14, still on main): "Microcosm owns the active calibration profile."
• docs/architecture.md (still on main): "Chronicle variables should describe source-backed facts, not downstream simulator variables… the alias belongs in the downstream adapter."
• docs/us-fact-to-target.md (microcosm, 2026-07-20): "Everything operative — which variable a fact binds, in what mode, over which universe, whether it binds at all — is a consumer decision and lives here."

The second-generation system assigns the contract (not activation) to Chronicle:

• PR Add Ledger target profile contracts #60 (2026-06-21) created target_profiles/ and rewrote the README boundary to "Ledger owns target profiles and measurement contracts" in the same commit — merged in 2m36s with no reviews or comments; no recorded debate before or since.
• It was then consistently built out: Publish Ledger target profile artifacts for Populace builds #61 ("Publish Ledger target profile artifacts for Populace builds") paired with microcosm#160 ("Consume Ledger target profiles instead of carrying target values in Populace"), the ledger-target-profile-author lane + ledger-target-profile judge (PR Add Ledger governance and raw fact boundary checks #68), the consumer artifact embedding profiles (PR Facts-only store: assertion-typed facts, period contracts, consumer artifacts #73 + the facts-only ADR), Belgian profiles planned here (Define Belgian target profiles for populace-be #70: "changing a target value requires a Ledger change, not a populace change"), and the UK waves (UK source packages, wave 1: the production 149-target national surface (ONS SNPP, SLC, OBR) #132/UK source packages, wave 2: national fiscal/benefit families + uk_national target profile #133) scoping uk_national to the profile lane.

Neither generation was ever reconciled. The pre-#60 doctrine remains on main verbatim alongside the post-#60 governance surface. No issue or PR proposes a US Chronicle profile, and none explains the US/UK asymmetry. (The README's load_target_profile("us_fiscal") example is a rename-diff artifact from PR #68 — no such file has ever existed.)

The sharpest specific conflict

Profiles' bindings.policyengine payloads store PolicyEngine variable names in Chronicle (since #60; at scale in #164), while docs/architecture.md says simulator variable names belong in the downstream adapter, and the US doctrine doc calls binding "a consumer decision". The selectors + measurement half of profiles has clear support in #61/#70; the bindings half conflicts with live doctrine. Note the activation boundary is not in dispute under either pattern: the judge wording forbids "target values or active calibration decisions" in profiles, and the 2026-08-05 vintages ruling ("porting a fact never activates it; Populace owns the active subset") holds either way.

What a ruling should settle

1. Is the selection contract a Chronicle artifact (Pattern B), a consumer artifact (Pattern A), or split (e.g. selectors+measurement in Chronicle, bindings.* consumer-side)?
2. Whichever way: which documents get amended — the harness plan/architecture/pe-calibration-targets trio, or the README/AGENTS/governance lane — so exactly one doctrine survives on main?
3. Should the US converge onto the ruled pattern (and Belgium's Define Belgian target profiles for populace-be #70), or do the two patterns intentionally coexist with stated criteria for which applies?

What is blocked or affected

• PR Declare the uk_national target profile over the ported UK facts (#133) #164 (uk_national, closes UK source packages, wave 2: national fiscal/benefit families + uk_national target profile #133): held in draft pending the ruling. Verified state: 186 value-free targets, 651/651 uk-data registry rows accounted, selector-level dimension pins with resolution tests, full suite green. If the ruling moves the contract (or just bindings) consumer-side, the profile is machine-generated and migrates cheaply.
• populace#622 (UK consumption): its work items assume uk_national exists Chronicle-side ("load uk_national … through the existing profile loader"). Its uk_target_references.json active-subset artifact is needed under every pattern.
• Define Belgian target profiles for populace-be #70 (Belgian profiles) inherits the same question.

🤖 Generated with Claude Code