Loading
Boss Loops is open core — inspect and self-host the Apache-2.0 engine, or run governed decisions on Boss Loops Cloud.
Explore Boss Loops Cloud →Loading
How it works
Boss Loops is built from a small number of ideas that compose: decision loops governed by guards, worked by attributed actors, opened by signals, explained by evidence. Each is explained below — no reference docs required.
The unit of work — a governed cycle around one decision
A decision loop carries one consequential decision from the moment something opens it to a recorded, accountable outcome. A supplier invoice lands over threshold; a refrigerated shipment records a temperature excursion; a customer asks for credit beyond their limit. Each of those opens a loop.
Inside the loop, the pieces the rest of this page describes do their jobs: evidence attaches from governed sources, policy evaluates every proposed step, the right participants — human and AI — act under their own names, and the outcome is measured after the fact. When the loop closes, what remains is a Decision Record: what was known, who decided, under which rules, and what happened next.
Under the hood a loop is a finite-state machine, which is what makes it enforceable — a transition either satisfies the rules or it does not commit. But the state machine is the mechanism, not the point. The point is that the decision, not the task, is the object your organization manages.
Active guards · PENDING_APPROVAL → APPROVED
Go deeper: What is a loop →
Execution pipelines, status models, and governance — how they stack
Workflow engines excel at sequential execution: step two follows step one, APIs fire, boxes get checked. State machines excel at status, events, and legal transitions: an entity sits in a named state until a valid event moves it. Boss Loops uses state-machine enforcement to govern decisions with durable evidence — and composes with workflow engines for everything that runs after approval.
The trap is filing consequential approvals as workflows. A sequential pipeline treats approval as another API step. If someone asks why a $10M invoice was paid, step logs are not enough. In Boss Loops the invoice sits in PENDING_APPROVAL behind active guards — it cannot transition to APPROVED without the required approval on the record and evidence frozen at that moment.
Generic explainers call state machines passive. Boss Loops is an active gatekeeper: invariant enforcement denies illegal transitions while the loop waits for signals. A transition that fails policy does not commit.
Signal → Boss Loops governs the commit → transition approved → your workflow engine executes the downstream pipeline. Temporal, n8n, Salesforce — unchanged. Boss Loops is the brains before the muscle.
Go deeper: What is a loop →
Humans, automations, and AI on one attribution model
Everyone who touches a decision acts as an attributed actor: the quality manager who approves, the automation that advances routine state, the AI model that recommends. One identity model, one audit trail, one set of rules about who may do what.
That symmetry is what makes AI safe to put inside consequential decisions. An AI actor's recommendation carries its model, its prompt fingerprint, and its confidence — recorded the same way a human signature is. When the answer to "who decided?" includes an AI, the record says so precisely, instead of leaving "the system did it" as the final word.
It also means governance doesn't care how the work gets done. Shift a decision from human review to AI recommendation to partial automation over time — the attribution, guards, and audit trail stay identical. Autonomy becomes a dial you turn, not a rewrite.
Go deeper: The actor model →
Deterministic invariants for agentic systems
Guards are the enforcement mechanism: deterministic checks evaluated at every proposed transition. Hard guards block outright — a missing piece of required evidence, an approver without authority, an AI recommendation below the confidence floor. Weighted guards score and flag, so borderline cases route to a human instead of sailing through.
The crucial word is deterministic. Guards are code in the runtime, not instructions in a prompt an AI might creatively reinterpret. A transition that fails policy does not commit — there is no "the model decided to proceed anyway." And denials are recorded with the same fidelity as approvals, because the decisions you stopped are part of the story too.
This is what "governance is the substrate" means in practice: the rules aren't a review meeting or a wiki page. They execute.
Go deeper: Guards & policy →
How the world opens a decision
Something changes in your operation: a sensor reads out of band, an invoice exceeds a threshold, demand spikes on one channel. Most systems turn that into an alert — a notification someone has to notice, interpret, and chase across three other tools.
In Boss Loops, that change is a signal, and a signal opens the right decision loop directly: a lot-release review, an invoice approval, a replenishment decision — with the relevant evidence already attaching. The difference sounds small and isn't. An alert asks "did anyone see this?" A signal asks "what did we decide about this?" — and guarantees there will be an answer on the record.
Go deeper: Signals →
Every transition, announced
Each state change in a loop emits a structured event: who acted, what evidence was attached, which guards evaluated and how. Events are how the rest of the world keeps up — they deliver approval requests into Slack or Teams, notify downstream systems that a decision committed, and feed the observability that makes any run replayable.
Because events are structured contracts rather than log lines, they're dependable enough to build on: your systems can react to decisions the way they react to transactions, and anyone reviewing a decision later can replay its history without reconstructing it from chat scrollback.
Event stream · supplier-invoice-approval · INV-2026-004521
Canonical seeded scenarioGo deeper: Event contracts →
How loops reach your stack
Adapters wire the outside world into governed loops, and the taxonomy matters: Model Providers (Claude, GPT, Gemini, Grok) participate as attributed AI actors; channels (Slack, Teams, OpenClaw) carry human coordination — approvals and escalations where people already work; integrations (PagerDuty, Postgres, HTTP APIs) execute against systems of record, and only after governance passes.
The layers are deliberately not interchangeable. Intelligence can't write to your CRM directly; a chat channel is never the system of record; execution never precedes policy. That separation is what lets you adopt AI aggressively at the recommendation layer while the blast radius of a wrong answer stays bounded.
AI analysis and recommendations. Models classify, predict, and draft — they never commit operational state.
Governed data frozen at the moment it informs the decision — the value, its definition, and its provenance.
Deterministic policies that enforce rules before side effects land. Humans and AI act under the same guards, attributed on the record — a transition that fails policy does not commit.
Final execution in your systems of record — updates, tickets, and writebacks run only after the governed commit.
Go deeper: Adapters & integrations →
What they knew at the time — frozen
Every consequential decision rests on evidence, and evidence has a failure mode every operator knows: the dashboard that looked different last month, the screenshot in an email thread, the number nobody can trace to a definition. Decisions get defended with links to things that have since changed.
Boss Loops captures evidence as a governed snapshot at the moment it informs the decision — the value, the source's own definition of what that value means, its freshness, and its provenance, frozen onto the record. Evidence Providers do this against the systems you already trust: a certified Looker metric, a governed Snowflake semantic view, a Samsara reading at decision time. Your definitions, not re-derived ones; a snapshot, not a link.
Qualification travels with the evidence — how governed the definition is, how attestable the provenance — inherited from the source, never asserted by whoever built the loop. A decision can require "a governed metric and an origin-attested reading," and the engine enforces it.
Decision
Sarah Chen — Case file complete. Release for payment.
Business object
Participants · 3
Outcome
Released for payment.
Go deeper: Evidence Providers →
Decision loops as reusable definitions
The decisions that matter in your operation are not unique to you: supplier invoice approval, purchase approval, inventory exception, returns triage, credit review. The catalog holds these as published loop definitions — the participants, evidence requirements, and policy shape already modeled — so your team instantiates and adapts a proven pattern instead of rebuilding governance from a blank page.
As your own decision systems mature, they join the catalog too: institutional judgment, versioned and reusable, that survives the person who designed it.
Screenshot — the loop catalog grid (supplier invoice, purchase approval, returns triage, credit review)
Go deeper: Browse the catalog →
These pieces exist so the platform above them can make a simple promise: every consequential decision becomes a record you can defend. See how the four pillars compose on the product overview, or ask us to walk you through a governed decision end to end.