Logic Loom Orchestration
What it is
Section titled “What it is”A Logic Loom is a named, deployed orchestration spec that runs a sequence of compute cells — possibly against different tables — as one atomic unit. Where a single cell works against one table, a loom can coordinate cells that touch the inventory, orders, accounts, and ledger tables, committing all of them together or none of them.
A loom runs each step’s cell in order, and applies every step’s writes together at the end. For long-running flows that touch external systems, a step can declare a compensation cell — undo logic that runs automatically if a later step fails. That’s the saga pattern, expressed as database DDL, with no external orchestrator to operate.
Why it matters
Section titled “Why it matters”A typical e-commerce checkout is several round-trips from the application server, each a chance for the network or the app to die mid-flow. A loom turns the whole checkout into one round-trip with built-in atomicity.
- One round-trip per business operation — several steps that used to be several SQL statements collapse to one loom invocation.
- All-or-nothing — a failed loom leaves no partial writes behind.
- Deadlock-free — tables are locked in a globally consistent order, so two concurrent looms with overlapping tables can never form a cycle.
- Saga compensation built-in — declare a per-step undo cell and the engine runs it automatically on failure.
- No external coordinator — there’s no separate workflow engine to operate.
flowchart TB classDef m fill:#1f2640,stroke:#7c5cff,color:#e8eaf0 classDef c fill:#1f2640,stroke:#00d4ff,color:#e8eaf0 classDef g fill:#1f2640,stroke:#4ade80,color:#4ade80 classDef r fill:#1f2640,stroke:#f87171,color:#f87171 M[Loom: purchase_flow]:::m M --> S1[step 1: check_inventory<br/>inventory · read]:::c M --> S2[step 2: create_order<br/>orders · write]:::c M --> S3[step 3: charge_payment<br/>accounts · write]:::c M --> S4[step 4: ship_notification<br/>ledger · write]:::c S1 --> COMMIT[Atomic commit<br/>all writes together]:::g S2 --> COMMIT S3 --> COMMIT S4 --> COMMIT S3 -.->|on fail| COMP[compensate: cancel_order]:::r
How you use it
Section titled “How you use it”Deploy a loom as an ordered list of cells with per-step failure policies, then invoke it like any other cell.
-- Deploy the orchestration spec.DEPLOY LOOM purchase_flow AS ( STEP 1 CELL check_inventory ON FAIL ABORT, STEP 2 CELL create_order ON FAIL ABORT, STEP 3 CELL charge_payment ON FAIL COMPENSATE cancel_order, STEP 4 CELL ship_notification ON FAIL LOG_WARNING);
-- Run the whole purchase as one atomic call.SELECT * FROM INVOKE_LOOM( 'purchase_flow', ROW(user_id => 4711, product_id => 9001, qty => 2));When you invoke it, the engine locks each required table in a consistent order,
runs each step’s cell, and — if every step succeeds — applies all writes
together. If step 3 fails after step 2 already wrote, it automatically runs
cancel_order to undo step 2, then releases the locks.
Key concepts
Section titled “Key concepts”| Concept | Meaning |
|---|---|
| Loom | A named, deployed orchestration spec — an ordered list of cells with per-step failure policies. |
| Step | One cell invocation inside a loom. |
| Compensation | A cell run automatically to undo an earlier step when a later step fails. |
| Atomic commit | A single action that publishes all of the loom’s writes at once. |
| Failure policy | ABORT, COMPENSATE <cell>, or LOG_WARNING — declared per step at deploy time. |