04 — GOV-DOT Status for Grouping DOT Lifecycle (Q4)

Verdict: GOV_DOT_READY — active, owns Đ35, and the scan/propose/apply/audit (A/B-tier + paired) model is fully present and directly reusable in live PG. The only gap is additive and non-structural: the specific grouping/pivot DOTs are not yet authored, and dot_coverage_required has no row for the classification/pivot domains — both fixed via new_dot APR + an approval-gated coverage INSERT.

Live evidence

1–2. Exists / active. governance_registry: code = GOV-DOT, name = "Quản trị DOT", gov_type = system, status = active, domain = monitoring.dot, created_by_law = NRM-LAW-35 (Đ35), capability = NULL.

• governance_relations: id 8 GOV-DOT --owner--> NRM-LAW-35 (Đ35 DOT Governance), id 9 GOV-DOT --owner--> NRM-LAW-36 (Đ36 Collection Protocol).

3. Does it govern scan / propose / apply / audit? Yes — the live substrate encodes exactly this:

• dot_operations (20 codes) include the full grouping vocabulary: classify, audit, health, verify, report, update, register, refresh, create, delete, execute (+ backfill/import/restore/seed/snapshot/sync/ensure + CONTEXT_PACK_*). Nothing new needs inventing.
• dot_coverage_required (11 rows) shows the A/B tiering live, and the scan/propose/apply/audit shape already exists in adjacent domains:
  • governance.approval: propose = tier A, execute = tier B; health = A.
  • birth.orphan: scan = tier A.
  • monitoring.dot: health = A, report = A, register = B.
  • collection: health = A; create/refresh = B.

4. Does Đ35 support the proposed pattern? Confirmed against enacted Đ35 v5.2 (audit doc 08, re-verified):

• scan = automatic / read-only → tier A (auto-approve). ✅
• propose = automatic / proposal → tier A that raises an approval_requests (the APR it raises is the gate). ✅
• apply = approval-gated → tier B (read+write), pending Đ32 approval; PG trigger trg_dot_enforce_paired requires every B-tier writer to have an A-tier paired_dot of the same scope. ✅
• audit = read-only / scheduled → tier A (auto). ✅
• law_dot_enforcement.enforcement_role live vocabulary = executor / auditor (B/A roles).

5. Tables/fields recording DOT capability / test / paired status.

Table	Rows	Records
dot_tools	288	DOT SSOT (per Đ35, 11 NOT-NULL fields incl. tier, paired_dot, owner free-field)
law_dot_enforcement	252	law→DOT binding; law_code, dot_code, enforcement_role (executor/auditor), status. Đ35 = 1 auditor row; Đ31 = 22 (5A/17E); Đ26 = 8 (4A/4E); Đ24 = 4 (1A/3E); Đ37 = 9 (2A/7E)
dot_operations	20	operation vocabulary (above)
dot_coverage_required	11	domain × operation × tier coverage matrix
dot_iu_command_catalog	47	commands tagged mutating/reversible (per prior audit)

Paired-test / regression: Đ35 §6.6 (NT12) mandates a dot-XXX-test smoke test per canonical DOT; §6.2/§6.4 3-tier verify + rollback-from-backup.

6. Gap before grouping DOTs can be implemented.

• No grouping/pivot DOT authored yet → DOT_AUTHORITY_GAP only in the "not-built" sense; the authority model (Đ35) is complete. Authoring = new_dot APR (B-tier apply DOTs paired to A-tier scan/audit).
• dot_coverage_required lacks rows for classification / pivot / monitoring.integrity → when grouping DOTs are authored, their coverage rows (e.g. classification × classify × B, pivot × health × A) must be INSERTed (approval-gated). Today the matrix covers only monitoring.dot / collection / governance.approval / birth.*.
• The pivot domain itself is agency-orphaned (Đ26 has no agency) — execution authority for pivot DOTs should be GOV-DOT with GOV-SIV health authority (doc 01), assigned via Council §4.12(d).

Bottom line

GOV-DOT is ready. The Đ35 paired-DOT lifecycle is the single most reusable piece of the central substrate for grouping execution. No structural change is required; grouping DOTs must be authored under Đ35 (never as hand-SQL / Nuxt-side / --admin / curl … || true classifiers), gated by new_dot + Đ32 apply approval, with coverage rows registered.