> For the complete documentation index, see [llms.txt](https://docs.talus.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.talus.network/talus-docs-v2.1.0/concepts/05-workflow-dag-execution.md). # DAG and Execution {% hint style="info" %} **Audience:** Agent developers, Tool developers, and integrators. **Goal:** Distinguish business state, DAG definitions, transient proof state, and durable execution state as a workflow advances. {% endhint %} ### Four kinds of state Nexus workflows use four distinct state layers. **Business state** is application-defined and owned or used by the Agent and its Tools. A **static DAG definition** is the published graph of vertices, ports, variants, edges, loops, and failure routes. **Transient worksheet/proof state** moves through one transaction to prove which components participated. **Durable execution state** records the live run, its walks, outputs, payment, and terminal result. The execution record does not define the application's business schema or automatically write it. Nexus records the result and runtime transitions; an application Tool or consumer decides whether and how to mutate business state under application-defined authorization and invariants. An on-chain Tool can mutate that state atomically in its Tool transaction before a later workflow transaction consumes the `OnchainToolResult`, materializes a `CommittedToolResult`, and settles payment. A shortfall, result cleanup, refund, or execution abort does not roll back an application mutation that already committed. Make asset effects idempotent or compensatable and verify business-state effects separately from result, Task, and settlement state. This is distinct from an off-chain/application consumer that intentionally waits for an accepted result before applying its own mutation. #### DAG structure A DAG contains vertices, typed input and output ports, output variants, and directed edges. An edge can route an output variant to the next vertex, terminate a branch, or feed a loop. Entry groups define the inputs that begin a walk. A vertex may produce one value or many values; a loop can expand a many value and collect the branch results. **Edge kinds, branching, and concurrency** * **Normal** — the ordinary output-to-input connection. * **ForEach** — runs one iteration per item in a many value. * **Collect** — recombines the per-item results into one many value. * **DoWhile** — continues a bounded repeat loop. * **Break** — exits that loop. * **Static** — supplies a fixed value from outside the loop to each iteration. A selected output variant chooses one branch; fan-out from that selected variant may start concurrent downstream walks. A merge is valid only when its sources are mutually exclusive, because two concurrent writers cannot fill the same input port.

Phase 1: Exclusive branches merge at one input.

Phase 2: Concurrent writers conflict on one input port.

Failure is a routed outcome when a Tool returns an `err` variant or verifier evidence, and it is a transaction failure when a contract invariant aborts. The DAG definition should make both paths visible: output variants route data, while aborts stop the transaction at the failed boundary.

DAG workflow topology from entry inputs through branches, loop collection, and terminal output — DAG topology: entry inputs branch on output variants and converge on terminal output.

#### Workflow values Values carried between vertices use typed `NexusData` references. Inline data keeps short bytes on chain, while an off-chain backend such as Walrus keeps a key or reference on chain and stores the payload outside the chain; the storage choice is part of the value contract, not an encryption promise. For remote values, the publisher writes the payload and the aggregator reads and verifies it; configured retention epochs control lifetime. A reference can outlive the retained remote blob. Retry availability failures only within the Leader budget; retry exhaustion produces no result, while a digest mismatch is an integrity failure. Nexus does not own remote deletion, retention, restoration, or provider cleanup; those remain provider/operator responsibilities. A value is either **single** or **many**. A many value can fan out one loop item per iteration and a later vertex can collect the branch outputs into one value. The DAG ports and loop edges must agree on that cardinality before execution starts. An on-chain Tool returns a `TaggedOutput` whose named fields carry checked `NexusData` values; the immutable `MetaSchema` checks `Object` versus `Data` and `One` versus `Many`. Application JSON semantics such as number, string, bool, or address are encoded inside `Data` bytes, not protocol type hints. The exact Move fields and constructors remain in the generated [data and tagged-output references](/talus-docs-v2.1.0/reference/move/nexus_primitives/data.md) and [tagged-output reference](/talus-docs-v2.1.0/reference/move/nexus_primitives/tagged_output.md). #### From Task to Execution A caller first creates a Task or an occurrence using a skill contract. Scheduler admission checks the pinned Agent, DAG, Tool, verifier, schedule, authorization, and funding requirements. When an eligible occurrence is dispatched, the protocol creates a `DAGExecution` with one or more walks.

Phase 1: Admit a funded occurrence into an execution walk.

Phase 2: Leader claims a vertex and invokes its Tool.

Phase 3: Submit result evidence and advance the walk.

#### Worksheets and proof state A worksheet is a single-use proof value carried through a step. Participating modules stamp it with their identity and may attach data. The worksheet is consumed as the transaction advances; it is not an application asset and should not be described as durable business state. The workflow uses worksheet evidence to bind a Tool call to the expected DAG vertex, Tool identity, authorization grant, and input/output shape. A missing or mismatched stamp rejects the step even when the transport request itself returned successfully. #### Effect authority boundary Admission is separate from effect authority. At the effect boundary, `RuntimeAuthority` and the accepted runtime witness produce an ephemeral `RuntimePermit` carried through execution and settlement calls. A cached protocol field, earlier package read, or event-emitter identity is not permission to mutate a stable object; the accepted package witness must authorize the object’s typed inner state. The selected network and client must expose matching objects, bindings, and effects. #### Durable execution state The live `DAGExecution` records the run and its walks. A walk tracks the current vertex, pending input, output variants, branch or loop progress, and terminal state. An on-chain Tool can create an `OnchainToolResult`; execution consumes exactly one result into a `CommittedToolResult` before settlement. `ExecutionPayment`, Task reserves, and Invocation/payment locks are durable accounting state associated with the run rather than part of the DAG schema. **Walk states and timing** A walk preserves iterator identity, and `WalkRequestAuthorityPhase` distinguishes request authority from Tool evaluation. | State | Meaning | | ----------------- | ------------------------------------------------------------------ | | Active | Eligible for submission. | | PendingSettlement | Committed result awaiting settlement. | | Successful | Terminal success. | | Failed | Terminal non-abort failure. | | Consumed | Output already used downstream. | | Aborted | `_err_eval` resolved to `Terminate`. | | PendingAbort | Double-timeout state while remaining walks and settlement resolve. | | Cancelled | Later walk stopped because the execution aborted elsewhere. | The primary may submit strictly before `created_at + timeout_ms`. The secondary may submit strictly after that boundary and strictly before `created_at + 2 × timeout_ms`. At or after the double-timeout boundary, timeout recovery may begin. Here `timeout_ms` is the effective timeout stored on the walk when it becomes active: the captured Tool timeout plus the 5,000 ms Leader-evaluation buffer. Read [On-Chain Result Resolution](/talus-docs-v2.1.0/concepts/11-onchain-result-resolution.md) for how an on-chain result becomes a committed result and advances a walk. Read [Payment Vaults, Reserves, and Settlement](/talus-docs-v2.1.0/concepts/06-payment-vaults-reserves-and-settlement.md) for funding and accounting; these pages summarize one another instead of repeating the full lifecycle. #### Execution lifecycle 1. Resolve the Agent skill and pinned DAG contract. 2. Create a Task and advertise a funded occurrence. 3. Admit the occurrence and create a `DAGExecution`. 4. Advance a walk through vertices, worksheets, Tool calls, and verifier verdicts. 5. Commit accepted output or route a failure variant. 6. Resolve payment and close the execution when the walk reaches a terminal state. #### Diagnosing a Stuck or Failed Run First identify whether the run is waiting for a Tool response, verifier evidence, a committed-result settlement, or an affordable payment source. Follow the exact result and payment state rather than inferring execution progress from transport logs; [On-Chain Result Resolution](/talus-docs-v2.1.0/concepts/11-onchain-result-resolution.md) owns pending-result recovery and timeout resolution. **Next** Continue to [Payment Vaults, Reserves, and Settlement](/talus-docs-v2.1.0/concepts/06-payment-vaults-reserves-and-settlement.md), then [Leaders](/talus-docs-v2.1.0/concepts/07-leaders.md), to connect execution state to public actors and settlement. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.talus.network/talus-docs-v2.1.0/concepts/05-workflow-dag-execution.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.