07 — Automation Pilot Refinement (Workstream F)

Pick the best automation pilot from the Topic × Process map.

Scoring (1=poor, 5=excellent; risk reversed so 5=lowest risk)

candidate	data avail	process clarity	gov risk (5=safe)	automation value	UI value	deps (5=few)	total
knowledge_graph content-map	5	5	4	4	5	4	27
cut_pipeline process	5	5	2	5	3	2	22
topic-axis approval pipeline	4	3	3	3	4	4	21
RP aggregation / pivot-update	3	4	2	3	2	2	16
approval workflow	4	2	2	2	3	3	16

Primary pilot: knowledge_graph content-map

Highest score, lowest dependency on owner births, richest cross-axis evidence (10 IUs ∩ 18 dot-kg DOTs ∩ one anchor doc), strongest UI payoff. It is content work, so it proceeds now without execution risk.

Exact scope

• input: 10 KG IUs (sections of dieu39 KG-law) + 18 dot-kg process objects + the joint-map view.
• output: a curated KG knowledge cluster (D1) + dot-kg SOP (D2) + a populated documents/workflows/dots_agents_events resolver array for the KG node (after promotion).
• steps: (1) author KG cluster prose from the 10 sections [safe now]; (2) author dot-kg SOP from #7-36-dot-kg [safe now]; (3) select KG document-template [AXR-TOPIC-14]; (4) on promotion, insert 2 axis_assignment rows (document_template selects, workflow routes_to) + 1 approval_requests (review) [owner-gated]; (5) PIV-327/328 flip from DEFER_NO_SOURCE to computable.
• DOTs/processes: KG_DOT_CLUSTER (18). IU/docs: KG-law anchor → D1/D2. events: governance domain. decision queue: AXR-TOPIC-03 (decide) + AXR-TOPIC-14 (pilot route). UI display: CandidateTopicPanel(knowledge_graph) + ProcessCandidatePanel(KG_DOT_CLUSTER) + the matrix cell (relation SHARED_IU+DOMAIN).

Safely applicable next (no active execution)

• DRAFT rows: none required now (the 2 routing rows wait on real targets + AXR-TOPIC-13/14 — inserting them now would dangle; expressed instead in v_axis_topic_automation_candidates, already live).
• Read-only views: joint map already applied this run.
• KB docs: D1/D2 prose drafts can be authored now (authoring ≠ promotion).
• No taxonomy node, no active route, no approval approved.

Backup pilot: cut_pipeline process

Strongest process evidence (materialised jobs, clear start/end, isolated blast radius) but higher governance risk (UNBORN → birth on registration) and a hard dependency: the queue worker is disabled, so a live run can't complete until infra re-enables it. Good second once owner approves a Type-2 registration. Scope = doc 04 #1.

Why not the others

• topic-axis / approval pipelines: mostly human decisions; low automation yield.
• RP aggregation, queue refresh: content-invisible infra; the worker-enable is an operator/infra act outside this content macro.

Decision

Primary = knowledge_graph content-map. Backup = cut_pipeline process. The next macro carries the primary; the backup is owner/operator-gated.