00 — Readme First

Macro: PROCESS_DISCOVERY_CORRELATION_RUNTIME_INVENTORY_FIX_AND_DOT_EXECUTION_READINESS Date: 2026-06-04 · Mode: EXECUTION_MODE · Status: PARTIAL (all safe branches done live; only owner/operator schema + runtime-enablement decisions remain). Channels: query_pg (RO, independent read-back) + ssh contabo → docker exec postgres psql -U directus (RW) + KB upload_document.

What this macro did (one paragraph)

The prior pilot proved Process Discovery can infer structural candidates but cannot verify them because there is no cross-DOT runtime correlation. This macro built the runtime/correlation model, fixed the on-demand producer blind spot live, hardened the discovery scoring against a backfill artifact, declared the process event vocabulary (draft), and prepared a runtime observation substrate + DOT execution dry-run path — all without executing a single production DOT, birthing a process, or faking a run.

Live mutations (all additive, birth-free, reversible)

1. 8 read-only views committed: v_axis_process_inventory_v2 + v_process_discovery_{evidence_graph_v2, candidates_v2, runtime_gaps, correlation_gaps, dot_family_pairs, verified_candidates, birth_readiness_v2}.
2. 7 DRAFT event types in event_type_registry (process.*, active=false, domain system).

• birth_registry 1,158,148 before == after == post-commit for every PG step (rehearsed BEGIN/ROLLBACK net-zero, then committed). v1 views and v_axis_process_inventory left untouched.
• KB authoring creates the usual document-provenance births (one per uploaded doc) — disclosed, not process/taxonomy/approval births.

Apply-ready (NOT committed — operator-gated)

• Runtime observation substrate: process_run_observation + process_component_observation DDL — rehearsed birth-free + DROP-reversible; staged contabo:/tmp/02_observation_substrate.sql (+ rollback). Empty base tables with no consumer yet → held for operator sign-off (owner "no infra drift" direction).

The four decisive live findings (live wins over old reports)

1. last_executed is a backfill, not runtime — 157 DOTs carry it but all share 1 distinct timestamp and usage_count=0. v1's evidence graph keyed runtime off last_executed; v2 ignores it and keys off real run rows.
2. The blind-spot filter is exact: v_axis_process_inventory → dotp CTE → WHERE trigger_type = ANY('cron','event','dual','on-deploy') drops on-demand → 18 KG producers invisible. Fixed in v2 (pair-grouped, producers visible, no inflation).
3. The correlation substrate already exists: event_outbox/event_pending already have correlation_id; job_queue.run_id already groups a real run (why job:cut is the only verified candidate). The gap is purely on the DOT layer.
4. dot_iu_command_run is the wrong grain for DOT process runtime — it logs the IU-command governance layer (55 rows / 15 commands, plan/apply/verify), keyed by command_name, with no process_run_id/correlation_id. DOT runtime needs the new observation ledger.

Read in order

• 01 live state + SSOT confirmation
• 02 runtime/correlation model (the core design)
• 03 on-demand producer inventory fix (LIVE)
• 04 runtime observation substrate (apply-packet)
• 05 KG/dot-kg event model (DRAFT live)
• 06 DOT execution readiness without execution
• 07 discovery views v2 (LIVE)
• 08 KG/dot-kg readiness rescoring
• 09 RP/UI runtime/correlation impact
• 10 next macro decision
• 11 final summary
• 12 GPT/MCP-readable checkpoint
• short checkpoint: knowledge/dev/reports/architecture/checkpoint-process-discovery-runtime-correlation-2026-06-04.md

Forbidden actions — none taken

No DOT executed · no process born/canon · no AX-PROCESS activation · no approval approved · no taxonomy node · no IU body edit · no workflow run · no fake runtime observation · no structural candidate marked verified · no producer hidden · no KG-only hardcode.