Module swarm 

The Swarm — verify-before-pay distributed jobs.

A swarm job is work that one node cannot (or should not) do alone, dispatched across the socially-defined network in one of three job::JobModes:

• Personal — your own devices cooperate (no payment).
• Collaborative — done with named peers (no payment).
• Paid — dispatched to a provider for payment (the solar-excess case: a node with surplus renewable energy sells idle compute).

The load-bearing invariant: verify before you pay

A paid swarm is dual-use. The same dispatch is autonomy (your fabric works for you) or extraction (you pay for fabricated or wrong work, or a node lies about what it computed). What decides which is a result-verification gate that runs before any payment instruction is emitted:

  spec ──► execute (untrusted provider) ──► VERIFY (trusted local reference)
                                                 │
                                      Verified ──┴── Rejected
                                         │             │
                                   emit Pay         emit Refund
                                   instruction      (no provider payment)

Verification never trusts the executor — it re-derives correctness with a cheap trusted reference (Freivalds’ algorithm for matrix products in O(n²); ranking reproduction for embedding artifacts; see [verify]). Only a Verified verdict lets settlement emit a crate::rpc::MicropaymentInstruction. This library never moves funds — it emits the instruction that the existing crate::ilp_dispatcher (the actual rail) executes under human authorisation.

Reuse, not reinvention

• Compute reuses crate::solvers::linear_algebra (matmul/matvec) and crate::solvers::learning::kg_embedding (the real KGE trainer).
• Money arithmetic reuses crate::modalities::value_flow (pool/discharge, eroi_viable — the thermodynamic supply gate that refuses net-extractive jobs).
• Payment transport reuses crate::ilp_dispatcher.

Kernel-class boundaries are explicit and CPU references are always present (§13): the executor is dispatch-ready, the verifier is the always-present CPU oracle.

Re-exports

pub use dispatch::run_job;

pub use dispatch::DispatchOutcome;

pub use executor::JobExecutor;

pub use executor::LocalKernelExecutor;

pub use isolate::isolate_b_compute;

pub use job::content_id;

pub use job::JobInput;

pub use job::JobKind;

pub use job::JobMode;

pub use job::JobResult;

pub use job::JobSpec;

pub use settlement::price_paid_job;

pub use settlement::Escrow;

pub use settlement::EscrowState;

pub use settlement::SettlementOutcome;

pub use verify::verify;

pub use verify::VerificationVerdict;

pub use verify::VerifyPolicy;

Modules

dispatch

Dispatch ties the pieces into the one path that matters: execute → verify → settle, with payment impossible without verification.

executor

Job executors. The JobExecutor trait is what a worker cell — local or a remote peer — implements. LocalKernelExecutor is the real one: it runs each job’s kernel through the actual engine (the dynamic GEMM and the real KGE trainer), so a dispatched job produces genuine computed work — never a stub.

isolate

The de-mocked Isolate B computation.

job

The job envelope: a deterministic, content-addressed specification of work plus its result. “Deterministic” matters — a job is reproducible from its (kind, input, seed), so any node can re-derive or verify it, and a paid job’s outcome is auditable rather than taken on trust.

settlement

Escrow + settlement — the money side, gated on verification, and incapable of moving funds itself.

verify

Result verification — the trusted gate that runs before payment. It never trusts the executor; it re-derives correctness cheaply with a local reference.

Enums

SwarmError

Fail-closed errors for swarm job handling.