Core Concepts
What is a Loop?
A loop is a governed decision cycle in the runtime taxonomy. This page explains the loop as a product unit; finite states are the mechanism underneath.
The problem
Enterprise AI systems fail when actions are not bounded by explicit state, policy, and traceability.
Boss Loops provides finite states, deterministic transition checks, and event traces that make decisions auditable.
Workflow vs. State Machine vs. Decision Loop
When designing operational processes, mixing up execution pipelines with governance models leads to brittle systems and decisions that cannot be defended later.
| Dimension | Workflow Engine (e.g. Temporal, n8n) | Finite State Machine (pattern) | Boss Loops (Decision Loop) | |---|---|---|---| | Primary focus | Tasks & execution — orchestrating sequences, API calls, data pipelines | Status & transitions — ensuring an entity moves legally between named states | Governance & evidence — proving why a transition was authorized | | Progression | Linear / forward-moving pipelines | Cyclical, event-driven, multi-directional | Cyclical execution with strict policy and authority guardrails | | Core unit | The task (what runs next?) | The state (where are we right now?) | The Decision Record (what is the immutable proof?) | | Triggers | Completion of the previous programmatic step | External raw events or inputs | Signals paired with runtime evidence evaluation | | Handling rejection | Complex error branching or manual exception code | State reset (e.g. back to draft) | Attributed rejections, guard failures, and historical loop resets |
One-liner: Workflow engines excel at sequential execution; state machines excel at status, events, and legal transitions; Boss Loops uses state-machine enforcement to govern decisions with durable evidence — and composes with workflow engines for everything that runs after approval.
Reclaim approval chains from workflows
Traditional guides classify document approvals as workflows. Boss Loops treats them as state-driven decisions. A sequential pipeline treats approval as another API step; an auditor asking why a $10M invoice was paid needs more than step completion logs.
In Boss Loops, the invoice sits in PENDING_APPROVAL protected by active guards. It cannot transition to APPROVED without the required C10 authority and a frozen snapshot of the evidence as it was seen at that moment.
Active governance, not passive status
Generic explainers describe state machines as passive — waiting for external events. Boss Loops is an active gatekeeper: while it waits for signals (temperature excursion, invoice over threshold), invariant enforcement and authority configuration deny illegal transitions — for example COMMIT_AUTHORITY_NOT_CONFIGURED.
Composition, not replacement
Boss Loops does not replace your workflow engine. It governs the commit; the workflow engine executes the approved work.
1Signal → Boss Loops (govern decision) → transition approved → Workflow engine (execute sequential APIs)Example: AI drafts a proposal → Boss Loops governs draft → approved → Salesforce or Temporal runs the downstream pipeline. See Workflow + Boss Loops.
:::note Alpine supplier invoice While naive tooling models invoice approvals as sequential workflows, the Alpine demo treats invoices as an FSM pattern — reset, exception handling, and strict state-based guardrails that a linear pipeline cannot enforce without brittle branching. :::
Anatomy of a loop (LoopDefinition)
id: LoopIdversion: stringdescription: stringdomain: stringstates: StateSpec[]initialState: StateIdtransitions: TransitionSpec[]outcome: OutcomeSpecparticipants?: string[]spawnableLoops?: LoopId[]metadata?: Record<string, unknown>
Use optional fields (participants, spawnableLoops, metadata) only when needed by your platform model.
Lifecycle (LoopStatus)
LoopStatus values: pending | active | completed | failed | cancelled | suspended.
1pending -> active -> completed2pending -> active -> failed3pending -> active -> cancelledUser-defined state IDs (like OPEN, PO_CONFIRMED, SETTLED below) are independent of LoopStatus — LoopStatus tracks the lifecycle of the instance itself, while state IDs track position within a specific loop definition.
Real example (abbreviated from loops/scm/procurement.yaml)
1id: scm.procurement2version: 1.0.03domain: scm4description: Purchase order lifecycle from requisition through settlement5states:6 - id: OPEN7 - id: PO_CONFIRMED8 - id: RECEIVED9 - id: INVOICE_MATCHED10 - id: SETTLED11 isTerminal: true12initialState: OPEN13transitions:14 - id: confirm_po15 from: OPEN16 to: PO_CONFIRMED17 allowedActors: [human, automation, ai-agent]18 guards:19 - id: approval_obtained20 severity: hard21 evaluatedBy: external22 description: PO must be approved before confirmation23 failureMessage: PO confirmation requires explicit approval24outcome:25 id: po_settled26 description: Purchase order fully settled27 valueUnit: po_settled28 measurable: true