02 — Process / Workflow Object Model

Definition

A process/workflow object is a governed, born, ownable unit of multi-step execution — a start condition, an ordered/branched set of components (steps/DOTs/jobs), an end condition, and a lifecycle — that the system can run, count, drill, and govern as one thing. It is distinct from a single task (one work item) and a single DOT (one tool). A process is the graph; tasks/DOTs/jobs are its components.

The three process classes (canonical for this system)

Reconciled with the prior naming (automation_level ∈ automatic/human_in_loop/agent_in_loop/mixed; actor_type ∈ automatic/human/agent; MOT branches A/B). The 3 classes are the RP-visible coarse taxonomy; the finer automation_level enum is the per-object attribute.

Type 1 — DOT-contained process

• Entire process lives inside one DOT/script. Counted primarily under DOT (PIV-007/104).
• Gets a process alias (not a second birth) when it has process semantics (scheduled/event/dual trigger → it runs a sequence).
• Substrate = dot_tools row + script + trigger + run logs (dot_iu_command_run) + IU/SOP.
• Live count: 57 (dot_tools trigger_type ∈ cron/event/dual/on-deploy). Decision: stays DOT-owned; surfaced as Type-1 alias in the process inventory, not re-born.

Type 2 — fully automated multi-component process

• Multiple DOTs/scripts/triggers/queues/events/jobs; no human task.
• Must be born as a process object (today they are implicit/unborn).
• Substrate = start/end condition + component list + triggers + queue/job states + events + health/SLA + count reconciliation + logs + IU/SOP.
• Live example: the cut-pipeline (1 implicit pipeline materialised across 13 job_queue rows / cut.* kinds; no workflows row → blind).

Type 3 — human-in-the-loop workflow

• Includes human task/approval/waiting_human/escalation. Dynamic-depth parent/child/grandchild.
• Substrate = workflow design + tasks + roles + deadlines + states + transitions + escalation + documents/IU + events/queue + governance owner.
• Live: 2 (workflows WF-001 active, WF-002 draft) — both contain human_checkpoint/wait_for_event steps.

Is process an axis / species / registry / pivot family? — RECONCILED

• Governance/authoring home = REGISTRY under MOW (prior canon, Điều-34, Option-3). Not a 5th Mother. Owner = GOV-MOW.
• RP visibility = AXIS (AX-PROCESS), via the generic axis_registry lens. Same mechanism as AX-TOPIC. The axis does NOT own the objects; it reflects the MOW registry onto the pivot/drilldown surface.
• Pivot family = PIV-340..353 (a reporting family layered on the axis; the legacy PIV-004/005/006/010 stay as direct table pivots).
• Species/birth = process designs already born under Điều-0-G (WF-NNN/ND-NNNN). Type-2 pipelines are the unborn gap.

This layering is the key non-obvious result: one object, three projections (MOW registry = home; AX-PROCESS = lens; pivot family = count surface).

Lifecycle (unified)

candidate → designed → approved → active → paused → deprecated → retired, plus a side-state failed (run-level). Maps onto:

• Điều-34 def lifecycle: draft(=designed) → active → deprecated → retired.
• Blueprint Rev2: born → active → deprecated → retired.
• Run state machine (Type 2/3): pending → ready → running ⇄ paused → completed | failed → recoverable_failed → running(replay) | cancelled | archived. Retire = UPDATE status, never DELETE (soft-delete / "Amidan" rule).

Parent/child relations (dynamic depth, no hardcoded levels)

• Sub-process: workflows.parent_workflow_id (self-FK) → process-of-processes (grandchild allowed).
• Step graph: workflow_steps.workflow_id + workflow_step_relations.from→to (DAG of nodes).
• Component edges (planned): job_workflow (1 parent) → N job_queue rows (workflow_id + parent_job_id DAG) for Type-2 pipelines — design sketch, not yet a table. Per the layer-definition canon: depth is emergent (count>1 + valid grouping_dimension), never hardcoded 1/2/3.

Minimum birth identity (Type 2/3)

process_code (WF/PRC-NNN, birth-registered) · process_type (1/2/3) · automation_level · start_condition · end_condition · owner (GOV-MOW) · components_ref · iu_ref (SOP) · lifecycle. Type-1 reuses dot_tools identity (no second birth).