Work Order
Dispatch creates a tool-ready Work Order from client or agent intake.
Dispatch schema →Execution binding rail
Routed Work Orders become operating-tool commands.
Wever Labs OS binds each routed Work Order to a tool execution command, task token, queue state, result contract, receipt path, callback path, ledger record, and attestation path.
How execution binding works
Dispatch creates the Work Order. Execution binding sends the work into the tool.
The binding rail gives the OS a single record that connects intake, routing, tool execution, queue movement, results, receipts, callbacks, ledger events, and attestations.
Command
The OS creates a tool execution command with input references and return requirements.
Command schema →Queue
The task enters queue state with heartbeat, retry, and replay readiness.
Queue monitor →Tool
TokenOps, FinanceOps, EnergyOps, DistributionOps, or PacketOps operates the workflow.
Operating tools →Return
The result contract returns machine output, human summary, receipts, callback state, ledger, and attestation.
Result contract →
Machine-readable contracts
Execution binding is discoverable and callable by agents.
Agents and builders can inspect the execution binding schema, tool command schema, result event schema, examples, SQL scaffold, and OpenAPI paths before routing work through the OS.
Work Order Execution Binding
One object connects the Work Order to task, queue, tool, result, receipt, callback, ledger, and attestation records.
Tool Execution Command
The command envelope sends inputs and return requirements into the selected operating tool.
Tool Execution Result Event
Progress, result readiness, exceptions, receipts, callbacks, and attestation events write back to runtime state.
Runtime scaffold
The SQL scaffold maps execution bindings, commands, and result events into durable operating records.