02 — GOV-MOUT Status (Q2)

Verdict: GOV_MOUT_DRAFT_OR_INCOMPLETE — the row exists and is the natural render/template owner by capability, but it is draft, has zero governance edges, and is born of the Assembly law (Đ7), not the Display law (Đ28). Critically, Đ28 itself is agency-orphaned — so today no active agency owns display / API / render governance. GOV-MOUT cannot be used as the render/display owner until it is activated and the Đ28 ownership question is resolved.

Live evidence

1–3. Exists / code / name / status. governance_registry row:

• code = GOV-MOUT, name = "Mother of UI/Output Templates", gov_type = factory, gov_group = mother, status = draft, domain = assembly.output, output_target = design_templates, created_by_law = NRM-LAW-07 (Đ7 "Luật Tận dụng / Assembly First"), health_dot = NULL.
• → It is draft, not active. (All 4 mothers — MOIT/MOT/MOUT/MOW — are draft, all created_by_law = NRM-LAW-07.)

4. Capabilities. capability JSON (the only non-null capabilities in the registry belong to the mothers):

{ can_create: ["design_templates"],
  must_not_own: ["workflows","tasks","input_form_registry"],
  can_reference: ["information_unit","input_form_registry"],
  output_family: "design_templates" }

→ By capability, GOV-MOUT is the producer of design_templates (the Đ28 render-template family). That is the right scope for the Registries-Pivot render template — if the mother were activated and bound to the display law.

5. Does it currently own render/display/output/API/RP-route?

• No active ownership of any of them. governance_relations has zero edges with source_code = GOV-MOUT (the 8 edges belong to COUNCIL/KG-SYS/DOT/NRM-SYS/SIV only). GOV-MOUT owns nothing relationally.
• Its domain is assembly.output (an assembly sub-domain), and its created_by_law is Đ7 (Assembly), not Đ28 (Display). So even by birth it is a "factory that assembles output templates", not "the display-governance authority".

6. Who currently owns display / API / render governance?

• Nobody, at the agency layer. Đ28 = NRM-LAW-28 "Luật Kỹ thuật Hiển thị" (Display Technique Law) is enacted, but:
  • law_jurisdiction: Đ28 appears only as a secondary coverage on domain collection — there is no display/render/ui domain at all.
  • governance_relations: no agency owns NRM-LAW-28 (no owner edge).
  • law_dot_enforcement: zero DOTs enforce NRM-LAW-28.
• So the Registries-Pivot route (live per prior ship reports) and its API are rendered under an agency-orphaned display law. The route works; its render-governance ownership is unrecorded.

7. Usable as render/display owner today, or approval/law-patch needed? Not usable as-is. To use GOV-MOUT as render owner requires:

1. Activate the mother draft → active — approval-gated per Đ37 (DOT-GOV-ONBOARD / §4.13 equip with PG table + DOT + health check; health_dot currently NULL).
2. Resolve Đ28 ownership — decide whether GOV-MOUT (the design_templates producer) also owns the display law Đ28, or whether Đ28 is assigned to GOV-MOUT via Council §4.12(d) + a governance_relations owner edge. This needs a clear decision because GOV-MOUT's law of birth is Đ7, not Đ28.
3. Direct-PG API exception (Đ41) for the Nitro endpoints — see doc 07.

Correction to prior audit

Prior audit doc 03/12 stated "GOV-MOUT (law Đ28)". Live evidence corrects this: GOV-MOUT's created_by_law = NRM-LAW-07 (Đ7), domain assembly.output. Đ28 is enacted but has no agency owner and no enforcing DOT. The recommended "render→GOV-MOUT" assignment therefore additionally requires binding GOV-MOUT to Đ28 (or assigning Đ28 to it), not merely activating the mother.