09 — Safe Live Artifacts Report (Workstream H)

Applied this run (1 object)

v_information_piece_topic_process_map — LIVE

• Kind: additive, read-only VIEW. Rows: 11. Role: directus.
• Definition: joins topic candidates (axis_assignment) × process clusters (v_axis_process_inventory, approval_requests) with an editorial relation_class from a VALUES catalog and live-computed member_count/iu_count (no hardcoded counts).
• Proof of safety:
  • Rehearsed BEGIN … CREATE VIEW … ROLLBACK: birth_registry 1,158,098 == 1,158,098 (net-zero); view absent after rollback (confirmed view_gone_after_rollback = t).
  • Committed: birth_registry still 1,158,098 post-commit.
  • Independent RO MCP read-back (query_pg): 11 rows, correct topics/clusters/counts.
• Rollback: DROP VIEW v_information_piece_topic_process_map; (one statement, no dependents).
• SQL: /tmp/ip_topic_process_map.sql (definition), /tmp/ip_map_rehearsal.sql (rehearsal wrapper).

Consciously NOT applied (3 candidate views) — and why

candidate view	decision	reason
v_information_piece_content_backlog	not applied	The content backlog (doc 03) is editorial judgement (confidence, next-action, root/child/fold). Baking it into a VALUES view adds maintenance surface for data that belongs in a KB doc and changes as the editor works. Kept as doc 03.
v_information_piece_document_building_backlog	not applied	Same — doc 05 (D1..D10) is a planning artifact, not queryable substrate. A view would freeze priorities that will churn.
v_information_piece_automation_pilot_candidates	not applied	The pilot scoring (doc 07) is a one-time decision (primary=KG, backup=cut_pipeline). No value as a live view; doc 07 is the record. The routing candidates are already live in v_axis_topic_automation_candidates (49 rows).

Rationale: Apply live only what is genuinely queryable substrate (the relational join map). Keep editorial/planning artifacts as documents so they stay editable without DDL churn. This matches the owner's "stop infra drift" guidance while still making the surfaces usable.

DRAFT / CANDIDATE planning records — not inserted

• The 2 KG routing rows (axis_assignment document_template selects / workflow routes_to) were not inserted — their targets don't exist yet and axis_assignment has NOT NULL/UNIQUE target_code → inserting now = dangling refs + births. They remain expressed in the live v_axis_topic_automation_candidates view and queued under AXR-TOPIC-13/14. Correct per the topic-axis bridge plan (doc 05 of the topic pkg).

system_issues rows — not inserted (conscious)

• One genuine operational issue exists (cut_pipeline: 7 jobs queued/stuck since 2026-05-26, worker disabled). Not logged as a system_issues/approval row this run because (a) inserting approval_requests births, and (b) it is an infra/operator concern, not a content blocker. Recorded here and in doc 04/06 (MOIT input) instead. If the operator wants it tracked, it should be a process_improvement action='review' row (never add).

Forbidden-action compliance (Workstream H rules)

✅ No IU body edited · ✅ no final doc created (backlog only) · ✅ no workflow executed · ✅ no topic/process promoted · ✅ no taxonomy node created · ✅ no active process registered · ✅ no source tag deleted/rewritten · ✅ no approval approved · ✅ no count math pushed to Nuxt · ✅ no hardcoded levels (clusters live-derived) · ✅ DAG kept many-to-many.

Net

1 additive reversible live object; 0 births; 3 candidate views consciously deferred to KB docs. Live read-only support exists exactly where it is genuinely useful (the join map).