KB-296C

dot-iu-cutter v0.1 — Decision Backlog Registry Design

8 min read Revision 1
dot-iu-cutterdesigndecision-backlogregistryanti-forgettingrev5d

dot-iu-cutter v0.1 — Decision Backlog Registry Design (D5)

Date: 2026-05-15 Status: DESIGN DRAFT Baseline: rev5d §7.I, §13.3 Scope: DESIGN ONLY.


1. Purpose

Define the Decision Backlog Registry — the anti-forgetting infrastructure for the cutter. Every governance-relevant decision, deferred question, schema gap, vocabulary gap, policy threshold to tune, and high-risk flag lives here. PG SSOT; KB markdown is mirror only.

2. Scope

  • Registry envelope and fields
  • Lifecycle of a backlog entry
  • Sweep cadence
  • Governance routing
  • PG storage (target DB: directus; layer: Lớp KHO)

Out of scope: implementation triggers (no DDL), specific dashboard build, notification fan-out.

3. Dependencies

  • rev5d §7.I, §13.3
  • D1–D11 as producers of backlog entries
  • Đ37 (escalation), Đ32 (risk), Đ33/Đ43 (PG placement), Đ38 (manifest as code)

4. Key Decisions

4.1 SSOT Position (Q29; criterion 15, 22, 27)

  • SSOT: PG table in directus, Lớp KHO.
  • Mirror: KB markdown report (for human reading / governance handoff).
  • Authority: PG. If markdown disagrees with PG, PG wins; markdown is regenerated.

Rationale: P14, rev5d §13.3, criterion 27.

4.2 Entry Envelope (Q29)

Minimum fields (logical contract; no DDL):

Field Purpose
decision_id Deterministic ID
date_discussed When the issue was raised
summary One-line description
status open / in_review / resolved / superseded / deferred
dependencies Other entries / decisions / laws
next_review_date When this MUST be re-evaluated
owner Đ37 role
source_discussion Reference to manifest / report / signal that surfaced it
related_law_or_design Law refs, deliverable refs
risk Đ32 class
kind gap / decision / threshold_tune / vocabulary_request / escalation / open_question

4.3 Entry Lifecycle

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

Each transition is logged with timestamp + actor + rationale. Entries never disappear; superseded is a status, not a deletion.

4.4 Sweep Cadence (Q30; criterion 22)

Every governance review, every Segmentation Health Report (D3), every Cutter Self-Review (D4) MUST sweep the registry:

  • List all open entries past next_review_date.
  • List all deferred entries whose deferral reason has resolved.
  • List all entries blocked on closed dependencies.

The sweep produces a backlog-state delta that is included in the report.

4.5 Routing on Entry (Q43)

When a producer emits a backlog entry, routing is:

Risk Route
Low AI queue (auto-process where policy allows)
Standard Council / human reviewer (Đ37)
High Đ32 full escalation; legal/governance involved

No new notification system (criterion 38). Routing uses Đ37 channels.

4.6 Producer Catalog

Producers writing to the registry:

Producer Entry kinds
F1 (D1, D2) vocabulary_request, gap, escalation, open_question
F2 (D3) decision (Split/Merge/Edge/Thread/Context-Pack/NoAction), threshold_tune, gap
F3 (D4) decision (intake), threshold_tune, gap
D9 threading gap (esp. universal_edges fit), escalation (user_ai_disagreement), threshold_tune
D11 retrieval gap (instrumentation), threshold_tune (metric targets), escalation (wrong_audience_result security)
D7 UOSL compat gap (schema)
D10 legal alignment escalation (law conflict), open_question

4.7 Diffability and Versioning (Đ38)

Entries are versioned and diffable. Updates produce new versions; the entry retains its history. Diff is governance evidence.

4.8 Markdown Mirror

The KB markdown mirror is a generated report. It is:

  • Regenerated on every sweep.
  • Stored at a stable path under knowledge/dev/laws/dieu44-trien-khai/registry/.
  • Marked clearly as mirror (frontmatter authority: mirror).

The mirror is for governance handoff and human readability; it is NEVER the authority.

4.9 Vocabulary Discipline (Đ24)

Entries carrying kind = 'vocabulary_request' route specifically to Đ24 governance — they do NOT silently mint new terms in the cutter.

4.10 Closure Criteria

An entry transitions to resolved only when:

  • The underlying decision/gap is fully addressed (decision recorded with rationale, or the gap closed by schema/policy change).
  • Affected producers acknowledge the resolution.
  • Health signals or retrieval metrics confirm the change has effect (where measurable).

deferred is used when resolution is intentionally postponed; superseded when a newer entry replaces this one.

4.11 Anti-Forgetting Guarantees

The registry provides:

  • No decision lost: every governance-relevant signal becomes an entry.
  • No deferral forgotten: next_review_date re-surfaces it.
  • No silent dismissal: resolution requires explicit closure.
  • No parallel governance: all routing uses Đ37 channels.

5. PG Storage per Object (Design Intent — No DDL)

Object Target DB Layer Notes
decision_backlog_entry directus Lớp KHO SSOT
decision_backlog_history directus Lớp KHO Version history
decision_backlog_dependency directus Não Edge between entries
decision_backlog_sweep_log directus Não Sweep events

6. Schema Gaps

  1. decision_backlog_entry table — no current generic governance backlog table; placement Lớp KHO must be confirmed in D7/D10.
  2. decision_backlog_history — version trail.
  3. decision_backlog_dependency — entry-to-entry graph.
  4. decision_backlog_sweep_log — sweep audit.
  5. Backlog routing config — owner mapping per Đ37.
  6. Markdown mirror generator — KB output renderer.

7. Law References

Surface Law
Roles, escalation channels Đ37
Risk routing Đ32
Manifest-as-code Đ38
PG placement Đ33 / Đ43
Vocabulary discipline Đ24

8. Open Questions

  1. Default next_review_date policy — per risk class, per entry kind?
  2. Should low-risk entries auto-resolve if no producer re-emits the signal within a window? Recommendation: no auto-resolve; always explicit closure.
  3. Should the registry track cross-cutter scope (other DOT pairs) or be cutter-scoped? Recommendation: cutter-scoped in v0.1, federated later via D4 capability intake.

9. Coverage

Questions covered (primary): Q29, Q30. Questions covered (secondary): Q43.

Acceptance criteria covered:

  • 15 (Decision Backlog Registry)
  • 22 (no decision lost)
  • 27 (PG-driven registry storage)
  • 38 (no parallel notification — supporting)

Schema gaps: 6 named (see §6).

Law dependencies: Đ24, Đ32, Đ33/Đ43, Đ37, Đ38.

Open questions: 3 (see §8).

Law conflicts encountered: none.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/design/dot-iu-cutter-v0.1-decision-backlog-registry-design-2026-05-15.md