KB-2AC6
10 — Auto-Full Workflow Admission Policy
4 min read Revision 1
process-discoverypolicyadmissionauto-workflow2026-06-04
10 — Auto-Full Workflow Admission Policy (Workstream I)
Operating policy for how a newly discovered auto-full workflow (an autonomous, multi-step process) may be admitted to birth — turned into the live view v_process_discovery_auto_workflow_policy_gaps.
The ladder (mandatory order; no skips)
- Structural candidate — a candidate in AX-PROCESS with a component graph (member_count ≥ 2). Single-component =
not_a_process. - Correlation model — run-level correlation across components (shared
process_run_id/run_id/correlation_id). Without it, the components are not provably one process. - Endpoint (agent_api only) — for agent_api-engine candidates, ≥1 no-mutation invocation endpoint bound.
- Dry-run observed — ≥1 real no-mutation
DRY_RUNobservation. SIMULATED_DRY_RUN does not count. - Real-run observed — ≥1
REAL_RUNwith shared correlation. - Verified — real runtime + cross-component correlation (existing
verified_candidates_v3logic; never hand-set). - Owner — governance owner registered (Điều 37).
- Birth-ready — verified and owner present.
Stricter pre-birth gate for auto workflows
Auto-full workflows (no human in the loop) carry more risk than MOW/MOT-born workflows. Required additionally before birth:
- a dry-run observation is mandatory (not optional) — never admit an auto workflow on structure alone;
- a negative-control proof (the verifier rejects a bad output) — as demonstrated by the fixture self-check;
- a rollback / kill-switch equivalent (runtime gate that defaults closed).
MOW/MOT-born vs discovered auto workflows
- MOW/MOT-born: a human authored the workflow definition; provenance and owner exist by construction. Admission focuses on runtime evidence.
- Discovered auto: surfaced by the discovery engine from structural evidence; provenance is inferred. Admission requires the full ladder including dry-run + owner before any birth — the structure alone is a hypothesis.
Orphan / uncovered-workflow detection (periodic scan)
An auto workflow that runs in production but has no candidate is an unmanaged risk. Periodic scan rule:
- any autonomous DOT (
trigger_type ∈ {cron, event, dual, on-deploy}) or queue/event producer not a member of any candidate → flagunmanaged_auto_workflow. v_process_discovery_orphan_componentsalready surfaces orphaned components (e.g. dot:kg's 18 producers were orphaned by an inventory filter, since fixed in v2). The scan should run on the discovery cadence and raise asystem_issuewhen an unmanaged auto workflow is found.- No silent caps: if a scan bounds coverage, it must log what was excluded.
Live policy snapshot (this run)
v_process_discovery_auto_workflow_policy_gaps over 17 candidates: 8 not_a_process, 8 gap_no_correlation_model (incl. dot:kg, which also fails endpoint + dry-run gates), 1 gap_no_owner (job:cut). Each row carries the exact next_required_action.
Completion
Admission policy defined and live as an enforced, queryable surface.