BPMN
Token-based BPMN 2.0 engine. SOPs are executable. The principal model keeps humans accountable for decisions.
BPMN is the workflow engine — a token-based BPMN 2.0 execution engine implemented as native Rust inside the Object Store module. It is not a flowchart renderer. Process instances are rows; live tokens are rows; reducers move tokens from one node to the next inside a single Object Store transaction. There is no external scheduler, no separate runtime, no network boundary between the engine and the substrate it sits in.
SOPs become deployable ProcessDefinition rows. Those definitions execute as token flows. Human and agent tasks are generated. Gateways branch. Timers fire via scheduled reducers. Errors surface as codes and get matched by boundary events. Every step has a principal, and every state transition is recorded in the commitlog.
PRINCIPALThe principal model
Every BPMN step has a principal — agent OR human. The engine doesn't care which; it just runs the step. What matters is that the principal is recorded on every state transition and lands in the commitlog.
This is what makes BPMN the load-bearing black-box derivation primitive. Given any two of {in, process, out}, derive the third — agents do it at the speed of light, and the human gets pulled in only where accountability requires. The platform makes the agents fast and the humans accountable. It doesn't pretend the second part is optional.
Principal identity is JWT-claim driven — see authorization. The philosophical framing of BOX-as-derivation lives at the name.
ELEMENTS15+ element types in production
The parser turns BPMN 2.0 XML into typed ProcessDefinition rows; the engine understands a wide slice of the spec. A single 2026-03-17 sprint closed 8 of the 18 original engine gaps.
| Element | Status | What it does |
|---|---|---|
| Start events | built | None, timer, message, signal start triggers. |
| End events | built | None, terminate, error end states. |
| User tasks | built | Human steps with claim/unclaim/complete lifecycle and OODB-driven forms. |
| Service tasks | built | Typed connector framework — Rust fns with declared inputs/outputs. |
| Script tasks | built | Inline expressions via the evalexpr engine. |
| Exclusive gateways (XOR) | built | Branch on first matching condition; default flow supported. |
| Parallel gateways (AND) | built | Fork into concurrent tokens; join on all-arrived. |
| Inclusive gateways (OR) | built | Fork on every matching condition; join on all-fired-arrived. |
| Embedded subprocesses | built | Nested scope with variable inheritance from the parent. |
| Ad-hoc subprocesses | built | The agent-workspace pattern — Fundi decides activity order. |
| Call activities | built | Invoke another deployed ProcessDefinition by id. |
| Boundary events (error) | built | Error-code matched; walks outward to find a handler. |
| Timer events | built | Duration, date, cycle — fired by scheduled reducers. |
| Message / signal events | built | The reverse bridge — Object Store changes signal waiting tokens. |
| Multi-instance activities | built | Parallel and sequential, with completion conditions. |
| Expression language | built | evalexpr with I/O mappings between task scope and variables. |
| Post-deploy timer init | partial | Start-event timers need a manual first-call to initialize. |
| Agent feedback in procedures | planned | Procedure outcomes feeding back to the Fundi that issued them. |
LIFECYCLEDocument-controlled definition lifecycle
A process definition is a document. Documents have approvers. Approvers are accountable. The lifecycle is the audit trail an accountable human relies on when the regulator knocks.
- DRAFT — author edits; not yet deployable.
- REVIEW — submitted; reviewers comment.
- APPROVED — signed off; ready for authorization.
- AUTHORIZED — live; instances can be started.
Transitions are recorded in a DefinitionTransition table. The principal of every transition is captured. A regulator asking "who approved this procedure?" gets a name, a timestamp, and the JWT-claim that proved it.
AGENT WORKSPACEThe ad-hoc subprocess
The ad-hoc subprocess is a novel BPMN pattern in IOBOXX: an agent workspace where the AI determines activity execution order. A Fundi operates inside the subprocess scope; every MCP call the Fundi makes runs in a normal Object Store transaction, but the subprocess's lifecycle is tracked by the engine so the Fundi's work is a traceable execution unit.
This is how Fundi agents orchestrate complex work. The author of the procedure declares the activities available inside the workspace; the Fundi picks the order, the count, and the stopping condition (subject to the subprocess's completion expression). The token-level audit trail makes the agent's decisions reviewable after the fact — every activity invocation, every variable mutation, every Object Store write is on the log.
TRANSACTIONOne module, one transaction boundary
BPMN engine state and Object Store state live in the same module. An engine step that mutates both commits atomically or rolls back together. There is no saga pattern, no two-phase commit, no outbox. A user task completion that mutates five attributes and advances the token across three gateways is one transaction. A crash mid-way replays cleanly on restart.
This is only possible because BPMN state lives in memory-adjacent tables — memory is the substrate the engine sits inside, not a separate database it has to talk to.
STATUSWhere the engine is today
The engine is in production. 8 of 18 original engine gaps closed in a single 2026-03-17 sprint — timer events, error boundary code matching, terminate end events, embedded subprocesses, multi-instance, ad-hoc subprocesses, typed service task connectors, expression language. Remaining gaps: agent feedback loops in procedures, and post-deploy timer initialization for start-event timers.
Compensation handlers are design-stage only. Transactional subprocess semantics — every subprocess currently runs in the same Object Store transaction as its parent — work but are not standard BPMN.