10 — Registration Readiness (Workstream I)

What it takes to move each candidate from candidate → birth-ready. No birth/canon/promotion done.

job:cut — closest to birth

• Status: verified_candidate (real runtime via iu-cutter, cross-component correlation present).
• Runner: TRUE_DRY_RUN_RUNNER_EXISTS.
• Only blocker = owner. owner_missing=true; event_missing=true (but verification does not require events).
• Evidence needed to birth: register a process owner in governance_registry (Điều 37) + owner birth admission. Optionally activate a process.* event for runtime signalling.
• Registration candidate readiness: READY-PENDING-OWNER.

dot:kg — multi-gate

• Status: simulated_observed / runner_contract_missing; fixture_ready + no_execute_tested.
• Blockers (all required): (1) agent_api plan-only contract → enables a true DRY_RUN, then REAL_RUN for verification; (2) cross-DOT correlation binding producer+verifier into one process_run_id during a real run; (3) process.* event activation with a real emit path; (4) owner registration (Điều 37); (5) split into the 10 law-defined process definitions at birth (not one blob).
• Registration candidate readiness: NOT READY — runner contract + real correlated run + events + owner outstanding.

Evidence ladder to birth (general)

structural → simulated → DRY_RUN (real no-mutation invocation) → REAL_RUN (+cross-component correlation) → verified_candidate → owner → birth_ready → birth.

Owner / governance handoff

• Owner registration is a governance act (Điều 37) — not performed (no fake owner row).
• process.* activation is owner/operator-gated (doc 07).
• Birth admission converts a verified+owned candidate into law-defined process definition(s) — owner-only.

Future registration path is clear; nothing registered or birthed this run.