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)

  1. Structural candidate — a candidate in AX-PROCESS with a component graph (member_count ≥ 2). Single-component = not_a_process.
  2. Correlation model — run-level correlation across components (shared process_run_id/run_id/correlation_id). Without it, the components are not provably one process.
  3. Endpoint (agent_api only) — for agent_api-engine candidates, ≥1 no-mutation invocation endpoint bound.
  4. Dry-run observed — ≥1 real no-mutation DRY_RUN observation. SIMULATED_DRY_RUN does not count.
  5. Real-run observed — ≥1 REAL_RUN with shared correlation.
  6. Verified — real runtime + cross-component correlation (existing verified_candidates_v3 logic; never hand-set).
  7. Owner — governance owner registered (Điều 37).
  8. 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 → flag unmanaged_auto_workflow.
  • v_process_discovery_orphan_components already 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 a system_issue when 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.

Back to Knowledge Hub knowledge/dev/reports/architecture/dot-agent-api-endpoint-true-dryrun-jobcut-ui-d1d2-readiness-2026-06-04/10-auto-full-workflow-admission-policy.md