KB-70F9

dot-iu-cutter v0.1 — G-2 Backlog Custodian Closure

21 min read Revision 1
dot-iu-cutterclosureg-2backlog-custodiandieu37rev5d

dot-iu-cutter v0.1 — G-2 Backlog Custodian Closure

Date: 2026-05-15 Status: CLOSURE RESULT — G-2 step of Governance Closure Execution Trigger: GPT PASS on closure records; execute Step #1 (G-2) only Baseline: Governance Closure Execution Checklist §5 + User Decision Confirmation §4.4 (Decision 4 cutter-only) + Governance Closure Package §5.2 + D5 design Scope: CLOSURE RECORD ONLY. No code, no DDL, no migration, no PG mutation, no implementation planning. Only G-2 is being executed; G-1, G-3, G-4, G-5 remain pending.


1. Purpose

Đóng governance gap G-2 — Decision Backlog Custodian cho dot-iu-cutter v0.1, theo Đ37 governance organization law, để mọi closure tiếp theo (G-1, G-5, G-3, G-4) cùng các P0 schema gaps, governance gaps, User decisions có owner chính thức chịu trách nhiệm tracking, sweep, anti-forgetting, và mirror generation.

G-2 là gap đầu tiên trong dependency graph (G-2 → G-1 ∥ G-5 → G-3 → G-4). Không có G-2, không gap nào khác có thể track tới resolution.

2. Hard Boundaries Honored

no_code: true
no_ddl: true
no_sql: true
no_migration: true
no_pg_mutation: true
no_qdrant_mutation: true
no_ui_build: true
no_implementation_planning: true
no_design_deliverable_modified: true
no_planning_file_modified: true
no_existing_closure_file_modified: true
no_new_governance_role_outside_dieu37: true
no_parallel_notification_system_created: true
no_silent_vocabulary_invention: true
only_g2_executed: true
g1_g3_g4_g5_still_pending: true

3. G-2 Scope

3.1 Custodian Responsibility Boundary (cutter-only v0.1)

The Backlog Custodian is responsible for the Decision Backlog Registry of dot-iu-cutter v0.1 — and only that scope.

scope: cutter_only
scope_basis: Decision 4 (User Decision Confirmation §4.4)
federation_scope: out_of_scope_for_v0.1
federation_path: future_d4_capability_intake_when_needed

The custodian:

  • DOES own backlog entries emitted by D1–D11 producers of dot-iu-cutter.
  • DOES sweep, route, close, and mirror those entries.
  • DOES NOT own backlog entries of other DOT pairs (e.g., dot-hc-executor, dot-nrm-enact, future DOT pairs).
  • DOES NOT operate a cross-DOT consolidated registry in v0.1.

If cross-DOT federation becomes required, it enters via a D4 capability intake (Đ32 risk review at that point) and is OUT OF SCOPE for this G-2 closure.

3.2 Authoritative Storage and Mirror

  • SSOT: PG table in directus, Lớp KHO (D5 §4.1, §4.4).
  • Mirror: KB markdown at knowledge/dev/laws/dieu44-trien-khai/registry/ (D5 §4.8).
  • Authority rule: PG > markdown. If markdown diverges, mirror is regenerated.

The custodian owns mirror regeneration cadence and integrity.

3.3 Anti-Forgetting Guarantee (D5 §4.11)

The custodian enforces:

  1. No decision lost — every governance-relevant signal becomes an entry.
  2. No deferral forgottennext_review_date re-surfaces it.
  3. No silent dismissalresolved requires explicit closure rationale.
  4. No parallel governance — all routing through Đ37 channels (criterion 38).

3.4 What G-2 Does NOT Cover

G-2 does NOT:

  • Approve or reject the content of backlog entries (that is per-gap reviewer/owner authority).
  • Decide threading thresholds (Decision 1 / G-1).
  • Decide audience filter policy (Decisions 3, 6 / G-5).
  • Sign DOT-pair revisions (G-4).
  • Approve capability intakes (G-3).

The custodian's authority is process discipline, not domain decision-making.


4. Proposed Owner Role (per Đ37)

4.1 Primary Role — Registry Custodian

Role name (Đ37 SOP): Registry Custodian — dot-iu-cutter v0.1

role: Registry Custodian
scope: dot-iu-cutter v0.1 backlog only
parent_dieu37_sop_class: governance_ops (existing or formally created)
seat: TBD by Đ37 council (named occupant required for ratification)

This role is proposed as an existing Đ37 governance-ops function (analogous to S178 admin_fallback_log custodian pattern). If no existing Đ37 SOP entry covers it, the council formally creates the SOP entry — but without inventing a new governance organization (criterion 38).

Authority (D5 §4.4 sweep + §4.10 closure criteria):

  • Schedule and execute sweeps at the defined cadence (§5.3).
  • Close low-risk entries with explicit closure rationale.
  • Co-sign with reviewer for standard-risk closure (per Đ32).
  • Route high-risk closures to Đ32 full escalation (custodian does NOT close high-risk alone).
  • Regenerate markdown mirror after each sweep (or on-demand).
  • Audit sweep outcomes; emit health signal sweep_overdue if sweep is missed.

4.2 Backup Reviewer

If the primary custodian is unavailable (vacation, role transition, illness), a backup must exist to preserve continuity.

Role name (Đ37 SOP): Registry Custodian Deputy — dot-iu-cutter v0.1

role: Registry Custodian Deputy
authority_scope: identical to primary while acting
activation_rule: primary unavailable > 2 sweep cycles, or formal handover
seat: TBD by Đ37 council

Backup activation is recorded in the backlog (entry kind=escalation, summary="Deputy activated for custodian absence") so that resumption is auditable.

4.3 Escalation Path (when custodian fails to act)

If the custodian (and deputy) fail to execute sweeps within the cadence, OR fail to close stale entries, the following Đ37 escalation path applies:

Sweep missed (>1 cycle late, e.g., > 14 days past schedule)
    ↓
[1] Health signal `sweep_overdue` emitted automatically by sweep audit
    ↓
[2] Routed to Đ37 escalation queue (no parallel channel)
    ↓
[3] Council notified via Đ37 standard channel
    ↓
[4] If still no action after [Council policy interval]:
        Đ32 escalation — risk class elevated to Standard
        Council assumes interim custodianship
        Custodian role re-evaluated per Đ37 SOP

This escalation path is itself an entry kind in the backlog (kind=escalation), making the custodian's own performance subject to anti-forgetting.

4.4 No Parallel Role

The Registry Custodian role MUST exist within Đ37 SOP, not as a parallel governance organization. If Đ37 SOP currently lacks a precise match:

  • The Council may classify it under an existing Đ37 governance-ops category and add a sub-entry naming dot-iu-cutter v0.1 scope.
  • The Council MUST NOT create a new top-level governance org.

This honors criterion 38 (no parallel notification or governance system).


5. Responsibility (Operational Detail)

5.1 Backlog Entry Lifecycle (D5 §4.3)

Custodian executes for every entry:

proposed → open → in_review → {resolved | deferred | superseded}
                                          ↓
                                   re-opened (if new evidence)

Custodian responsibilities at each transition:

Transition Custodian action
proposed → open Validate envelope completeness (D5 §4.2 minimum fields)
open → in_review Route per risk class (D5 §4.5: low → AI; standard → human; high → Đ32)
in_review → resolved Verify closure rationale exists; check producer acknowledgement
in_review → deferred Confirm deferral reason recorded; set next_review_date
any → superseded Record supersession reference (FK to replacing entry)
deferred → open Triggered by next_review_date expiry; re-surfaces automatically

5.2 Sweep Execution (D5 §4.4)

Sweep produces a backlog-state delta. Custodian executes sweeps:

Triggers:

  • Every governance review cycle (Đ37 cadence).
  • Every Segmentation Health Report (D3).
  • Every Cutter Self-Review (D4).
  • Ad-hoc on user request.

Sweep tasks:

  • List all open entries past next_review_date.
  • List all deferred entries whose deferral reason has resolved.
  • List all entries blocked on closed dependencies.
  • Emit sweep_overdue signal if any sweep is more than 1 cadence late.
  • Regenerate markdown mirror.

Sweep cadence (proposed):

sweep_cadence:
  default: every 7 days (calendar week)
  triggered_in_addition: governance reviews, D3 reports, D4 Self-Review
  ad_hoc: user/council request
  cadence_status: proposed_pending_council_ratification

Cadence default is conservative (weekly) to honor anti-forgetting; council may relax to bi-weekly after evidence accumulates (cross-link Decision 8 / G-3 Self-Review cadence — currently held).

5.3 Schema Gap Tracking

Custodian tracks the full set of schema gaps recorded across design + planning + closure phases:

Gap pool Count Status
Total schema gaps (D8 §6) 56 tracked, not solved
P0 schema gaps (Schema Planning Package) 6 tracked, ready for future migration design phase
P1 schema gaps 15 tracked, waiting on P0
P2 schema gaps (semantic threading) 14 tracked, waiting on P0 + G-1
P3 schema gaps (retrieval/instrumentation) 21 tracked, waiting on P0 + G-5

Each gap exists as a backlog entry (kind=gap) with: priority (P0/P1/P2/P3), source_deliverable, related_law_or_design, next_review_date per priority.

Custodian does NOT design schema, write DDL, or propose migration plans. Those are FUTURE separate phases.

5.4 Governance Gap Tracking

Custodian tracks the 5 governance gaps:

Gap Status as of 2026-05-15
G-1 Threading roles pending Đ37 closure
G-2 Backlog custodian THIS CLOSURE (proposed_closed_pending_council_ratification)
G-3 Capability-intake reviewer pending Đ37 closure (dependent on G-1, G-2, G-5)
G-4 DOT-pair signing authority pending Đ37 closure (dependent on G-3)
G-5 Access-Control Authority pending Đ37 closure (HIGH risk; ratifies Decisions 3+6)

Each governance gap is a backlog entry (kind=escalation). Custodian re-surfaces them per next_review_date.

5.5 User Decision Tracking

Custodian tracks the 7 User decisions (User Decision Confirmation §5):

# Decision Effective status Custodian tracking
1 Auto-accept thresholds (Balanced) recorded; effective post-G-1 ratify track ratification milestone
2 Retrieval targets (Standard) recorded; effective post-instrumentation track instrumentation phase
3 Audience definitions (Conservative) HIGH risk; held pending G-5 + Đ32 + Council + Đ24 track all 4 sub-ratifications
4 Backlog scope (Cutter-only) effective (this G-2 closure consumes it) mark consumed by G-2
5 Per-unit block shape (Child rows + JSONB) recorded; effective post-Đ44 Family + Đ24 vocab track sub-ratifications
6 wrong_audience_result handling (Block+Log+Escalate) HIGH risk; held pending G-5 + Đ32 + Đ37 + Council track all 4 sub-ratifications
7 Context Pack caching (Always fresh) effective (no further ratification needed) mark effective

Decisions 3 and 6 are explicitly held; custodian re-surfaces them at every sweep until G-5 ratification completes.

5.6 Decision Backlog Review Cadence

Sweep cadence (§5.2) IS the review cadence. Custodian additionally:

  • Reports outstanding overdue items at each governance review (Đ37 cadence).
  • Reports stale deferred entries needing re-evaluation.
  • Reports superseded chains for audit.
  • Surfaces user_ai_disagreement, sweep_overdue, wrong_audience_result events to Council immediately (no batch delay).

5.7 Health / Closure Report Generation

Custodian generates periodic reports:

Backlog Health Report (per sweep cycle):

- total_entries (by status)
- new_entries_this_cycle
- closed_entries_this_cycle
- overdue_entries
- escalations_routed
- next_review_horizon
- high_risk_held_items
- gap_summary (P0/P1/P2/P3 counts)

Report is PG-persisted (D5 §4.1) and mirrored to:

knowledge/dev/laws/dieu44-trien-khai/registry/backlog-health-report-YYYY-MM-DD.md

Custodian Closure Report (on G-2 closure milestone):

This document itself serves as the G-2 closure report. Future closures (G-1, G-3, G-4, G-5 closure reports) follow the same template.


6. Acceptance Criteria for G-2 Closure

Mapping to Governance Closure Execution Checklist §5 — 8 criteria:

# Criterion Status (this closure)
1 Registry custodian role recorded in Đ37 SOP proposed (this document); requires Council ratification to mark recorded
2 Named occupant recorded pending Đ37 council assignment
3 Authority scope ratified by Council proposed (this document §4.1, §5); requires Council ratification
4 First sweep scheduled proposed (every 7 days; first sweep at council ratification + 7 days); requires Council ratification of cadence
5 Markdown mirror path confirmed and accessible confirmed: knowledge/dev/laws/dieu44-trien-khai/registry/
6 D5 backlog entry for G-2 transitions status = resolved with rationale pending PG backlog table existence (P0-5 schema gap; cannot transition entry status without table)
7 No parallel governance-ops role created honored (this document explicitly forbids parallel role)
8 No new notification system created honored (all escalation reuses Đ37 channels)

Net status: 3 of 8 criteria fully met by this document alone (5, 7, 8). The other 5 require either Đ37 council action (1, 2, 3, 4) or P0-5 schema realization (6).


7. Blockers if G-2 Stays Unresolved

If G-2 does NOT close, the following degradations occur immediately:

  1. G-1 Threading roles cannot be tracked to closure — no custodian to sweep status changes; threading reviewer authority drift goes undetected.
  2. G-5 Access-Control Authority cannot be tracked — HIGH-risk Decisions 3+6 remain in limbo with no anti-forgetting guarantee.
  3. G-3 Capability-intake reviewer cannot be tracked — even if appointed, capability intake records pile up unreviewed.
  4. G-4 DOT-pair signing authority cannot be tracked — DOT registration drift undetected.
  5. P0 schema gaps (6) cannot be tracked beyond planning — migration design phase has no anti-forgetting layer to ensure all P0 items reach migration spec.
  6. P1/P2/P3 schema gaps (50) silently accumulate.
  7. D5 §4.11 anti-forgetting guarantee fails — the very point of the registry is moot without an owner.
  8. 9 missing-instrumentation items (D8 §8) are not re-surfaced; instrumentation backlog drops on the floor.
  9. 26 open questions (D8 §9) remain unrouted to owners.
  10. Health signals from D3, D9, D11 have no sink for governance routing; they may be emitted but never acted upon.
  11. sweep_overdue self-detection never fires (no entity to detect the overdue).
  12. Markdown mirror at knowledge/dev/laws/dieu44-trien-khai/registry/ is never generated; governance handoff impossible.
  13. Implementation planning gate remains BLOCKED indefinitely — gate requires all 5 governance gaps closed.

In short: without G-2, the entire closure chain stalls.


8. Conclusion

8.1 G-2 Status

g2_status: proposed_closed_pending_council_ratification

Why not proposed_closed?

Of the 8 acceptance criteria in the Governance Closure Execution Checklist §5:

  • 3 criteria are fully satisfiable by this document alone (5, 7, 8 — mirror path, no parallel role, no notification system).
  • 4 criteria explicitly require Đ37 Council action (1, 2, 3, 4 — SOP record, named occupant, authority ratification, first sweep schedule).
  • 1 criterion requires P0-5 schema realization (6 — PG decision_backlog_entry row transition to resolved); this is FUTURE migration design phase.

Therefore G-2 is proposed by this closure record, but ratification is required from Đ37 Council before the gap can be marked formally resolved. Without that ratification, the proposed custodian has no Đ37-recorded authority to execute sweeps or close entries.

8.2 What Ratification Looks Like

To move G-2 from proposed_closed_pending_council_ratification to resolved:

  1. Đ37 Council action to:
    • Confirm Registry Custodian role exists in Đ37 SOP (or formally add SOP sub-entry under existing governance-ops class — no new top-level org).
    • Name the human/role seat occupying the primary custodian position.
    • Name the deputy seat.
    • Ratify the authority scope per §4.1.
    • Ratify the sweep cadence (default 7 days proposed; council may adjust).
    • Confirm escalation path per §4.3.
  2. Đ24 cross-law check that no vocabulary used in this closure (e.g. sweep_overdue, kind=escalation) violates Đ24 — none introduced here outside D5 design which is itself ratified at design phase.
  3. D5 backlog entry recorded as ratified — note this presumes P0-5 schema realization; until then, the closure entry lives in this markdown closure file as the SSOT, and PG SSOT begins at P0-5 migration.

Special note on the PG-SSOT vs markdown-mirror principle (D5 §4.1):

D5 declares PG as SSOT. P0-5 (decision_backlog_entry table) does not yet exist. Until P0-5 is migrated:

  • This markdown closure file IS effectively the temporary SSOT for the G-2 entry.
  • After P0-5 is migrated, the G-2 entry is backfilled into the PG table (kind=escalation, decision_id=G-2, status=resolved if council ratified by then, else in_review).
  • Markdown closure file becomes the documentation mirror after backfill.

This is the standard "Lớp KHO" pattern (D5 §4.1) executed in the v0.1 bootstrap phase where the table itself is part of P0.

8.3 Authority Required for Ratification

ratification_authority:
  primary: Đ37 Council
  cross_law: Đ24 (vocabulary check); Đ33/Đ43 (PG layer = Lớp KHO confirmed)
  risk_class: Standard (governance role assignment)
  dieu32_required: NO (Standard risk; not High)
  user_required: NO (custodian role is Đ37 council scope; User PASS on design phase already covers strategic direction)

User confirmation is NOT required for G-2 itself (governance role assignment is Đ37 council scope). User decision interfaces (Decisions 1–7) are tracked BY the custodian but not approved BY the custodian.

Per Governance Closure Execution Checklist §3 dependency graph:

G-2 (this closure)
   ↓
G-1 ∥ G-5  ← NEXT (parallel)
   ↓
G-3
   ↓
G-4
   ↓
[Implementation planning gate; still requires Đ44 + Đ24 + P0 migration]

After G-2 is ratified by Đ37 Council:

  1. Run G-1 (Threading roles) and G-5 (Access-Control Authority) in parallel:
    • G-1 unblocks D9 governance.
    • G-5 unblocks Decisions 3 + 6 HIGH-risk ratification.
  2. Đ44 governance and Đ24 governance run in parallel to G-1/G-5 for Family Registry + vocabulary closures.
  3. G-3 (Capability-intake reviewer) starts after G-1 + G-2 + G-5.
  4. G-4 (DOT-pair signing) starts after G-3.
  5. Only when all 5 governance gaps resolved + Đ44 + Đ24 + Đ32 ratifications for Decisions 3+6 → Migration Design Package phase opens for P0 items.
  6. Migration Design phase + Đ32 risk approval → Implementation Planning Package phase.
  7. Implementation Planning + final risk review → Implementation execution (FIRST time code/DDL is allowed).

G-2 closure does NOT unblock implementation planning by itself. It only enables the next governance closures (G-1, G-5) to be tracked.


9. Status Block

closure_artifact: G-2_backlog_custodian_closure
g2_status: proposed_closed_pending_council_ratification
ratification_authority: Đ37 Council
acceptance_criteria_satisfied_by_this_document: 3 of 8 (criteria 5, 7, 8)
acceptance_criteria_pending_dieu37_council: 4 of 8 (criteria 1, 2, 3, 4)
acceptance_criteria_pending_p0_5_schema: 1 of 8 (criterion 6)
implementation_planning_allowed: false
implementation_execution_allowed: false
next_recommended_step: run G-1 and G-5 in parallel after Đ37 Council ratification of G-2
g1_g3_g4_g5_status: pending
no_code: true
no_ddl: true
no_migration: true
no_pg_mutation: true
no_design_or_planning_or_prior_closure_file_modified: true

10. Coverage of Mandatory Sections (Task Requirement)

Mandatory section Where addressed
1. G-2 scope (custodian, cutter-only v0.1) §3 (full)
2. Owner role per Đ37 (custodian, backup, escalation) §4 (full)
3. Responsibility (sweep, gaps, decisions, cadence, reports) §5 (full)
4. Acceptance criteria for G-2 closed §6
5. Blockers if G-2 unresolved §7
6. Conclusion (g2_status; ratification; next step) §8
Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/closures/dot-iu-cutter-v0.1-g2-backlog-custodian-closure-2026-05-15.md