KB-7AB7

RS-TKT-0A-PATCH2 · 02 P6 profile_id Schema Repair

6 min read Revision 1

tool-kiem-thulegolaws-newrs-tkt-0a-patch2p6profile-idscope-classrs5ars5bnon-authorizing2026-06-21

RS-TKT-0A-PATCH2 · 02 — P6 profile_id Schema Repair

Lane: RS-TKT-0A-PATCH2 · Date: 2026-06-21 Gate: REGISTRATION_HOLD · REGISTRATION_CAN_PROCEED = NO · 0 runtime mutations (KB writes only) Authority: NON_AUTHORITY · may_gate=false · decision_effect=NONE · design-doc-only

Supersedes: PATCH1 06 §3 profile_id enum and §4 table rows that assigned profile_id = structural to Groups A, B, and G; and the validation_status token EXTERNALLY_CODEX_VALIDATED. The provenance split itself (CODEX_CAUGHT_RS5A vs SELF_REPORTED_RS5B_DRAFT, which Codex accepted) is kept; only the schema contradiction is repaired.

1. The defect (Codex P6)

PATCH1 declared:

profile_id : CODEX_CAUGHT_RS5A | SELF_REPORTED_RS5B_DRAFT   (§3)

but then assigned, in the §4 group table:

profile_id = structural   (Groups A, B, G)

structural is outside the declared enum — the metadata is not machine-consistent. The two ideas were conflated:

provenance track   (where the rule came from / how it was validated)
applicability class (which packets the rule legitimately governs)

structural/common is an applicability statement, not a provenance value. It must not live in profile_id.

2. Repaired schema

Every 06 rule carries:

{
  "rule_id": "...",
  "profile_id": "CODEX_CAUGHT_RS5A | SELF_REPORTED_RS5B_DRAFT",
  "scope_class": "STRUCTURAL_COMMON | RS5A_SPECIFIC | RS5B_SPECIFIC",
  "provenance": "...",
  "source_review": "...",
  "validation_status": "EXTERNALLY_CODEX_REVIEWED | SELF_REPORTED_DRAFT | PROMOTED_AFTER_REVIEW",
  "applies_to": ["..."],
  "does_not_apply_to": ["..."]
}

profile_id may take only the two provenance values. profile_id = structural is deleted and never valid.

3. Repaired semantics (two orthogonal axes)

profile_id   = provenance track   — how the rule was sourced/validated
scope_class  = applicability class — which packets the rule governs

Therefore, explicitly:

STRUCTURAL_COMMON is NOT a profile_id.
RS5A_SPECIFIC     is NOT a profile_id.
RS5B_SPECIFIC     is NOT a profile_id.

A rule with broad applicability is still sourced from a specific provenance track. A structural rule that was hardened through the RS5A Codex chain is profile_id = CODEX_CAUGHT_RS5A and scope_class = STRUCTURAL_COMMON. The two fields are independent.

4. Repaired group assignment (PATCH1 `06` §4, corrected)

Group / rule	profile_id	scope_class	provenance	validation_status	applies_to	does_not_apply_to
A Package (PKG-001..004)	`CODEX_CAUGHT_RS5A`	`STRUCTURAL_COMMON`	codex_caught (RS5A chain)	`EXTERNALLY_CODEX_REVIEWED`	any RS packet	—
B Gate (GATE-001..004)	`CODEX_CAUGHT_RS5A`	`STRUCTURAL_COMMON`	codex_caught	`EXTERNALLY_CODEX_REVIEWED`	any RS packet	—
C Lifecycle (LIFE-001..004)	`CODEX_CAUGHT_RS5A`	`RS5A_SPECIFIC`	codex_caught (PATCH3)	`EXTERNALLY_CODEX_REVIEWED`	RS5A lifecycle packets	non-RS5A unless promoted
D Quorum (QUORUM-001..006)	`CODEX_CAUGHT_RS5A`	`RS5A_SPECIFIC`	codex_caught (PATCH3→PATCH4)	`EXTERNALLY_CODEX_REVIEWED`	RS5A quorum	generic RS-series
E Replay (REPLAY-001..005)	`CODEX_CAUGHT_RS5A`	`RS5A_SPECIFIC`	codex_caught (PATCH4)	`EXTERNALLY_CODEX_REVIEWED`	RS5A replay	generic RS-series
F Count (COUNT-001..004)	`CODEX_CAUGHT_RS5A`	`RS5A_SPECIFIC`	codex_caught (PATCH4)	`EXTERNALLY_CODEX_REVIEWED`	RS5A suites	generic RS-series
G Codex-packet (CODEX-001..004)	`CODEX_CAUGHT_RS5A`	`STRUCTURAL_COMMON`	codex_caught	`EXTERNALLY_CODEX_REVIEWED`	any RS packet	—
RS5B BI01–BI10	`SELF_REPORTED_RS5B_DRAFT`	`RS5B_SPECIFIC`	self_reported	`SELF_REPORTED_DRAFT`	RS5B	all non-RS5B; not a gate

Groups A/B/G keep their broad applicability via scope_class = STRUCTURAL_COMMON; their provenance track is the RS5A Codex chain that hardened them. No row uses profile_id = structural.

5. RS5A and RS5B applicability constraints

84 parent IDs / 86 executable scenarios = scope_class RS5A_SPECIFIC  (unless explicitly promoted later)
Q-code order Q00<…<Q50                  = scope_class RS5A_SPECIFIC  (unless explicitly promoted later)
G02a/G02b/G02c effect→envelope tree      = scope_class RS5A_SPECIFIC  (unless explicitly promoted later)
RS5B BI01–BI10                          = profile_id SELF_REPORTED_RS5B_DRAFT until Codex reviews RS5B

Applying an RS5A-specific rule to a non-RS5A packet is a configuration error, not a finding. RS5B rows must never be described as externally validated (MCB-1 carry-forward).

6. Promotion rule (no automatic promotion)

A rule may be promoted from RS-specific to common (or from self-reported to reviewed) only by a later explicit review:

validation_status = PROMOTED_AFTER_REVIEW
source_review     = <path to the Codex/User acceptance that authorized the promotion>

There is no automatic promotion. Until such a review exists:

RS5A_SPECIFIC stays RS5A_SPECIFIC.
SELF_REPORTED_RS5B_DRAFT stays SELF_REPORTED_DRAFT.

7. Status effect

CODEX_CAUGHT_RS5A rules remain engineering-grounded only — still NON_AUTHORITY, still may_gate=false, never a registration gate.
SELF_REPORTED_RS5B_DRAFT rules remain DRAFT / NOT_EXTERNALLY_CODEX_VALIDATED; they may guide surveying and Phase-1 design but must not be called validated and must not be used as a gate.
The repair is metadata-consistency only; it grants no authority and moves no registration.