RS3C-08 — Rerun: Pair / Guard Cardinality Correction (Codex C2) — 2026-06-21

Macro: RS3C (Mục tiêu E, reruns RS3B-07) · Deliverable: 08 of 13 Codex C2: "Do not infer every target registration creates two rows from the registrar's existing pair." RS3B-07 conflated the registrar control pair with per-target row cardinality. Source now settles it. Date: 2026-06-21 · read-only · 0 mutations

---

1. Source proof of cardinality

The registrar creates exactly one dot_tools row per registered target (one curl POST per file, RS3C-03 B5/B10). The "pair" is expressed as a text field on that single row:

# RS3C-02 §2, L148–151, L166/L174
local PAIRED=""
if [[ "$TIER" == "B" ]]; then PAIRED="DOT-HEALTH-DOT"; fi
...
'{ code:…, name:…, file_path:…, tier:…, domain:…, status:"active" }
   + (if $paired != "" then {paired_dot: $paired} else {} end)'

• paired_dot is a reference string to the pre-existing DOT-HEALTH-DOT identity — not an instruction to create a second registry row.
• No trigger creates a second dot_tools row either (RS3C-09: birth/provenance/label triggers write to other tables or transform the same row; none inserts a paired registry row).

2. Corrected cardinality model (source-confirmed)

registrar control-plane pair  (two PRE-EXISTING registry identities):
    DOT-REGISTER  ↔  DOT-HEALTH-DOT
    (live rows: DOT-REGISTER operation=register paired_dot=DOT-HEALTH-DOT;
                DOT-HEALTH-DOT operation=health)

per-target registration mutation:
    default = ONE primary target row
    paired_dot = text field → references existing DOT-HEALTH-DOT (NOT a new row)
    target verifier row = created ONLY IF that target's own accepted contract
                          explicitly names and requires a separately registered verifier
                          (no such requirement is emitted by the registrar today)

guards:
    content-bound components, ZERO automatic registry rows

Cardinality question	RS3B-07 (conflated)	RS3C-08 (source)	Evidence
Does the registrar control pair imply 2 rows per target?	implied yes	NO	L148–151 sets a field, not a row
Rows per target registration	ambiguous (2 or 5)	1 primary row	one POST per file, L156/L131
Pair representation	row-level	field-level reference to existing DOT-HEALTH-DOT	L166/L174
Target verifier row	assumed	only if target contract requires it (none does now)	absence in source
Guards	risk of materializing as rows	content-bound, 0 auto rows	RS3B-07 rule retained

3. Why DOT-REGISTER.paired_dot does NOT prove per-target pairing

DOT-REGISTER.paired_dot = DOT-HEALTH-DOT describes the registrar's own control pairing (a tier-B tool paired to the health DOT). The registrar then propagates the same string onto every tier-B target it registers (L149–151) — but that is a field copy, creating no verifier row and registering no second identity. Codex C2 is therefore CONFIRMED by source: existing-pair ≠ per-target two-row rule.

4. Adversarial cases added (detail in RS3C-10)

• TARGET_VERIFIER_ROW_ASSUMED — assuming a verifier row is auto-created per target (it is not).
• CONTROL_PAIR_CONFUSED_WITH_TARGET_PAIR — treating DOT-REGISTER↔DOT-HEALTH-DOT control pairing as a per-target cardinality rule.

5. Status

• Deliverable: PAIR_CARDINALITY_CORRECTED_BY_SOURCE — one primary row per target; paired_dot is a field reference to an existing identity; verifier rows only on explicit target-contract demand; guards content-bound with zero automatic rows.
• Persisted representation remains contract-derived, not fixed at two or five (prior Codex rule preserved).
• Registration gate unchanged: REGISTRATION_HOLD · CAN_PROCEED = NO.