Branch G — Governance / UI Scale Implications

Doc 07 (2026-05-29) — design only, no UI implementation

Problem: humans must manage thousands → tens of thousands of process designs. Define the management model (not the implementation).

1. Treeview (hierarchy)

Levels: domain → company → department → specialty → workflow → task.

• Reuse workflow_categories (already has parent_id, level, sort) as the upper tree; bind workflow designs at the leaf via category_id.
• IU axis B (domain/specialty) and axis C (parent/child) already classify the IU bodies — the treeview reads these, it does not redeclare them (Đ38/39 ownership).
• Auto-discovery over manual declaration (NT11): derive the tree from workflow_categories + registry FKs + IU axes. Do not hand-author large trees where the catalog can auto-discover them.

2. Filters

• status (born/active/deprecated/retired), health (traffic-light), automation_level (automatic / human-in-loop / agent-in-loop / mixed), last_review_age, owner, domain/specialty.
• All filterable from the workflow_design header fields proposed in Doc 06.

3. Traffic-light health

Source = health_dot (Tier-A check per design) + Đ31 system_issues (CRITICAL/WARNING) + last_review_at age:

• Green: health_dot PASS, no open issues, reviewed recently.
• Amber: WARNING issue or review overdue.
• Red: CRITICAL issue or health_dot FAIL. Đ31 mandate: "every divergence is an error" — the light must reflect real divergence, with a watchdog checking the checker.

4. Proposal / Kaizen suggestions

• Reuse workflow_change_requests (dsl_diff, schema_warnings, suggested_actor_type, approved_by, applied_at) + the generic proposal table for KG-derived ideas.
• AI proposes, human approves (Đ39 golden rule; Đ32 quorum). Suggestions never auto-apply to an active blueprint.
• KG "used-together" signals (iu_usage_evidence/iu_relation) feed improvement proposals — but write only to proposal/workflow_change_requests, never directly to the design (REV2-04 §3.5 sentinel).

5. Drilldown

design → steps → bound IU body (render_iu_body) → code_ref / sql_link_ref / dot_ref / event_ref → runtime workflow_run/step_run. Every body view goes through render_iu_body and emits iu.rendered (audit, Đ31).

6. Permissions — superadmin vs staff

• Flagged future-law gap (D-1): Đ37 governs law→agency→entity, not people→data. There is no human-org-role/permission law yet (staff / trưởng phòng / super admin / chuyên môn / lĩnh vực).
• Today enforced only via Directus role/policy + field-allowlist (Layer B) + Đ32 approval. Sufficient for a read-only proof surface; insufficient for production multi-role design management.
• Required before production UI: the human-org-role law (the same blocker that gates MOW-UI and 4 Mothers G2). The MOWD/MOW.design decision (Doc 05) does not unblock this — it is a parallel prerequisite.

7. Scale guidance

• 10k–100k designs is a PG indexing problem, not an architecture problem — keep blueprints as rows, bodies as IUs (build-once/reuse-many singleton body), pin versions per run.
• Render is permission-scoped and cached (render_iu_body carries permission_scope_hash, cache_hit).
• No manual declaration of huge trees where auto-discovery applies (NT11); the registry + categories + axes are the source, the UI is a read shell (Đ28: Nuxt renders from PG-registered templates only).

8. Boundary reminders

• UI is render-only over PG (Đ28); no business logic, no direct PG from Nuxt.
• This doc defines the model; no UI is built in this campaign. First UI is a read-only proof surface (Doc 08 macro 5), gated behind the human-org-role law for anything mutating.