Guides · Demo draft

A Division Swarm workflow whose event log is a chain of receipts

Division Swarm orchestrates durable workflows: system nodes run deterministic logic, agents call tools, humans decide through typed review cards. This demo drafts a small flow where one system node calls a public AINumbers MCP calculator and records the returned execution_hash onto the entity as evidence, so every computational step in the orchestration log points at a receipt anyone can verify offline.

Draft · drafted, never executed Public endpoint · no credentials Pinned commits · swarm 5a334401c
Start here

What this demo is, and what it is not

Two pieces of software meet on this page, neither owned by the other.

Division Swarm is an open-source workflow orchestration engine from division.sh (github.com/division-sh/swarm, a Go project). You author a contract bundle: entities move through lifecycle stages, guards check conditions, decision gates open review cards for humans, and every admitted event lands in an immutable log.

The AINumbers MCP server (https://mcp.ainumbers.co/mcp) exposes deterministic financial calculators over standard MCP JSON-RPC, with no authentication. Every tool call returns a fully verifiable artifact: an execution_hash you can check later with the verify_execution_hash tool, with zero network access at verification time.

The demo is one sentence: the orchestration log becomes a chain of receipts instead of a chain of trust. Division provides the orchestration and evidence accumulation; the MCP server provides verifiable computation; a human holding the decision gate reviews the receipt, not the node's word.

What this is not. This is a draft authored from public documentation only. Nothing here was executed against the swarm CLI or validated by its static analyzer, Post Oak Labs is not affiliated with or endorsed by Division, and no integration claim is made: the mapping is published as a neutral, informative correspondence. See the limitations section before relying on any format detail.
The idea

Five steps, each pointing at something verifiable

This is the conceptual event log a real run of the drafted flow would produce. The column that matters is the last one: what each entry lets you check independently.

  • 1

    A caller publishes the ingress event

    The event mcp-evidence.started arrives with tool_name: catalog-search; the platform creates the entity in its ingress stage.

    Points at: the ingress event payload itself, the tool name the caller asked for.
  • 2

    A system node calls the public MCP tool

    The deterministic node mcp-evidence-node passes its guard and calls the tool through the platform's connector to mcp.ainumbers.co/mcp.

    Points at: the JSON-RPC result, which carries an execution_hash: a verifiable artifact receipt rather than a plain text answer.
  • 3

    The platform records the hash as evidence

    The returned execution_hash is appended to the entity's evidence accumulator, and the entity advances to review_stage.

    Points at: the recorded evidence field on the entity (mcp_evidence.execution_hash), auditable for the life of the record.
  • 4

    A decision gate opens a review card for a human

    The typed gate mcp_result_review opens a mailbox card showing the tool name, the recorded hash, and one review question.

    Points at: the card content is derived from the recorded evidence, so the human is reviewing the receipt rather than the node's word.
  • 5

    The human decides, and the decision joins the evidence chain

    Approve advances to evidence_accepted; reject advances to evidence_rejected with the reviewer's feedback attached as evidence.

    Points at: the human outcome, recorded against the receipt it was raised on. The final authority stays human; the computation under it stays checkable.
The artifacts

Three files, one clearly marked mock

All three were authored from public sources only: the swarm repository's own examples and spec, and the AINumbers public docs.

  • A

    flow.yaml, the contract bundle draft

    One entity lifecycle: an ingress event starts the flow, the system node calls the MCP tool and records execution_hash as an evidence field, and a decision gate routes the result to a human. Every format choice cites the swarm repo file it was copied from.

  • B

    scenario.yaml, the scripted test draft

    A swarm test style scenario exercising the flow against a mocked MCP response whose values are clearly marked MOCK-. Its expect block asks for exactly what a reviewer would want: the evidence event emitted, the entity parked at the review stage, and no dead letters.

  • C

    real-mcp-response.json, the real receipt

    A response captured from the live endpoint, input chosen as the first committed fixture vector of the lookup_reg_z_thresholds kernel so anyone can reproduce it bit for bit:

    curl -s https://mcp.ainumbers.co/mcp -H 'Accept: application/json, text/event-stream' -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"lookup_reg_z_thresholds","arguments":{"policy_parameters":{"year":2026,"table":"qm_points_fees"},"compute":"server"}}}'
    The receipt: execution_hash 43d43e1b5ac519566dd345496b655fe80a2f815428ab17703c092c15f490c8b6, tool_id the art-220 node, compute_mode server.
Hand test

How to run it

For a human with the swarm CLI available. These commands were drafted from the swarm repo's documented mechanisms and were never executed by us. Treat them as a checklist and read the CLI's own help for exact flags.

  • 1

    Clone both repositories at the pinned commits

    git clone https://github.com/division-sh/swarm && cd swarm && git checkout 5a334401c

    The demo's format choices were read at swarm commit 5a334401c; if the repo has moved, re-check the pack layout against its current examples.

  • 2

    Arrange the files as a pack

    Place the bundle and scenario into the pack layout the swarm repo's own examples use: a package manifest at the pack root with flows and tests beneath it, following examples/ and tests/ in the clone.

  • 3

    Run the scripted scenario

    swarm test <pack> <scenario>

    The exact flag surface was not read from live help text; the repo README documents the test workflow. That limitation is stated here rather than hidden.

    Success looks like: the evidence event emitted, the entity parked at review_stage, no dead letters. The approve or reject choice stays unscripted on purpose: the gate is held for human judgment against the receipt.
Make it real

Swap the mock for the real response, then verify

Two minutes, and the demo stops being a mock.

Swap: in the scenario, replace the MOCK- tool id and hash values with art-220-reg-z-threshold-lookup and the 43d43e1b... hash from the captured response above, and point the scenario's tool name at lookup_reg_z_thresholds with the same input. The evidence field the flow records then holds a hash from a real server run.

Verify: feed the recorded pair to the verify_execution_hash tool on the same MCP server, or run the calculator yourself on the art-220 threshold lookup page with the same inputs and compare hashes. Because the input is the kernel's committed fixture vector, the value reproduces for anyone, forever, with no network at verification time.

For the same receipt idea in a browser-native walkthrough, see WebMCP Demo 1; for prompts that drive the MCP suite end to end, see the prompt library, and the MCP playground runs example prompts live, hash by hash.

Limitations

What was not done, stated plainly

Nothing executed. The bundle and scenario were never run through swarm, its static analyzer, or the live endpoint. Every format choice cites the file it was copied from; every unverified choice is flagged in the artifacts themselves.
The MCP call is a connector step, not a bundle primitive. The platform spec read at the pinned commit does not define an MCP tool-call action. The demo models the call as an external step whose result re-enters the flow as the evidence event payload. Division orchestrates the state machine; the call stays outside the bundle.
Three drafted details to confirm against the repo. The CEL guard placeholder, the dotted entity evidence accessor, and the handler evidence key were authored from spec vocabulary but not confirmed against worked examples. A hand tester should check each against the swarm repo's own examples before treating them as valid.
Versions pinned. swarm at 5a334401c; AINumbers docs read at ea29ed00b. If either moves, format details may drift. No credentials anywhere: the endpoint is public, and this demo transmits nothing private.