RS3B-07 — Pair / Guard Representation Decision v0.1 — 2026-06-21

Macro: RS3B-REGISTRAR-HARDENING-DESIGN (read-only / KB-design) Deliverable: 07 of 10 · Pair / guard representation (Mục tiêu G) Date: 2026-06-21 · 0 mutations · NO_CODEX_LIVE_READ Deliverable status: PAIR_GUARD_REPRESENTATION_DERIVED — derived from the governed contract + live registry; not assumed as "five rows."

---

1. Rule: do not assume five rows

Codex RS3-PATCH2 / gate deliverable #10: derive pair cardinality from the runtime contract, never fixed five rows. Two different "cardinalities" are conflated in casual prose and must be separated:

• Registry pair cardinality = how many dot_tools rows constitute the registrar pair → governed by the paired_dot column (1:1).
• Guard set cardinality = how many guard components live inside the single governed artifact → a content property of the contract, not registry rows.

2. Evidence

• Live registry: dot_tools.paired_dot is a 1:1 link. DOT-REGISTER ↔ DOT-HEALTH-DOT; the register + verify reuse precedent pairs each registrar with exactly one verifier (dot-apr-types-register/-audit; DOT-TAC-COLLECTION-REGISTER/-VERIFY). So registry pair = 2 rows (primary + paired verifier), not five.
• Governed contract (dot-r2-b2-staging-schema-shell.contract.md rev2, Option B): 1 primary DOT identity + 4 separable guard components (DOT_SCHEMA_WRITE_ALLOWLIST_GUARD, DOT_SCHEMA_WRITE_AUDIT_PROOF, DOT_PRODUCTION_UNTOUCHED_VERIFY, DOT_STAGING_SCHEMA_DELETE_FAST) joined only by an explicit dict contract; Guards 1 & 4 share a stateless _validate_target helper; no guard imports/calls another; each is "separately generated, inspectable, testable, replaceable, rollbackable." The primary also defines 7 shell tables and 6 modes — i.e. cardinality is content-derived, with no "exactly five rows" assertion anywhere.

3. Decision

Component	Representation	Binding	Independently testable?	Registry footprint
Primary runtime identity	one DOT	one dot_tools row (closed-at-registration)	yes (validator/verifier)	1 row
Paired verifier	one DOT	paired_dot 1:1 link	yes	1 row
Guard 1..4	contract components inside the single artifact (functions/clauses), not registry rows	content/hash-bound (carried by the admitted artifact; verified via interface F hash, RS3B-04)	yes — each separately testable; no cross-guard import	0 rows (travel inside the primary artifact)

So: registry pair = 1 primary + 1 verifier (2 rows); guards = 4 content-bound components (0 rows). Total registry rows for the unit = 2, not 5. The "1 primary + 4 guards = 5 components" is a contract-content count, not a registry-row count.

4. The five questions (Mục tiêu G)

1. Are guards registry rows, contract components, metadata, extra_metadata, or separate artifacts? → contract components inside the single admitted artifact (content/hash-bound), not registry rows and not extra_metadata.
2. How does catalog-sync see them? → as part of one dot_tools row (the primary). It does not see four extra rows. If catalog-sync ever materialized guards as separate rows, that is drift → GUARD_MATERIALIZED_AS_ROW reject (RS3B-02 boundary).
3. How does the registrar register them? → it registers the one primary artifact; guards are bound by the artifact's content hash (interface F), not registered separately. No mass/guard registration.
4. How does the validator/verifier prove reachability only via the primary? → router-only dispatch through the primary's validate_request entrypoint; no guard is importable/callable except through that router; the post-commit verifier proves each guard is reachable only via the primary.
5. Reject conditions: PAIR_GUARD_STANDALONE_REACHABLE (a guard executable on its own when not allowed); GUARD_DRIFT_UNDETECTED (guard content diverges from the admitted artifact hash and is not caught); GUARD_MATERIALIZED_AS_ROW (guard registered as a separate dot_tools row); PAIR_CARDINALITY_ASSUMED_FIXED (any logic that hardcodes "5 rows").

5. Status block

• Deliverable status: PAIR_GUARD_REPRESENTATION_DERIVED
• Registry pair = 2 rows (primary + paired_dot verifier); guards = 4 content-bound components (0 rows); not fixed five
• Final confirmation of source-level guard binding awaits RS3B-01 (registrar source) + interface F hash (RS3B-04)
• Registration gate: REGISTRATION_HOLD · REGISTRATION_CAN_PROCEED = NO · 0 mutations