KB-102B

10 — Repoint Decision

2 min read Revision 1

10 — Repoint Decision

Decision: DO NOT APPLY the production repoint; keep it action-ready as a single staged statement.

The non-circular candidate is now full-column parity PASS, so the repoint is technically safe and reversible. But it is not applied because:

  1. Zero functional upside. _current is a pass-through alias of _current_v2, and the candidate's decoration IS _current_v2. The repoint produces byte-identical output (87/87 proven). It swaps the membership/backbone derivation to the generator but changes no rendered value.

  2. It does not advance no-hardcode. The decoration layer stays hand-built (sourced from _current_v2 either way). TRUE no-hardcode (registry-driven decoration, the 58 view-edits) remains authority-gated.

  3. It is an operator-authority decision. Swapping the live contract backbone derivation is consistently framed across checkpoints and the runbook as an operator step; the final acceptance dashboard reports DECORATED_GENERATED_REPOINT_READY_OPERATOR.

Consequently the repoint is reduced to a single CREATE OR REPLACE of v_rp_universal_node_ui_contract_current selecting the 34 contract columns from v_rp_decorated_generated_candidate_noncircular, with a one-line rollback that restores the pass-through alias. Both are written verbatim in RUNBOOK_v3 section 3.

Back to Knowledge Hub knowledge/dev/reports/architecture/rp-post-deploy-final-acceptance-or-operator-standby-2026-06-05/10-repoint-decision.md