> 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/guides/vision-explorer/checking-workflows.md). # Checking Vision Workflows {% hint style="info" %} **Audience:** Anyone reading a published DAG — before running it, after publishing it, or to copy it. **Goal:** Verify what a workflow actually does on chain: its graph, its entry points, the tools it calls, and how its past runs went. {% endhint %} ### Finding a workflow * **Entities → Workflows** lists published DAG objects — **Recent Workflows**, newest first, each with its id and **Creator**. * Paste a DAG id into the [search](/guides/vision-explorer/search.md). * Every agent skill card, task, and execution links to the workflow it runs. Workflows are shared on-chain objects: anyone can inspect the graph and open it as a template, but a shared DAG is not universally runnable. Execution requires suitable inputs, funding, a selected Agent and skill, scheduler admission, an eligible runtime path, and any Tool or application authorization required by the published vertices. The object is immutable — changing a workflow means publishing a new one. #### The workflow page `/explorer/workflow/`: * **Workflow Graph** — the published DAG drawn as the canvas would draw it, read-only, with **Open graph in full screen**. Entry groups, default values, edges, and per-vertex policies are shown *as published*. * **Tools in workflow** — every Tool the vertices reference, resolved from the registry, each linking to [its Tool page](/guides/vision-explorer/checking-tools.md) for price, timeout, and earnings. A retained UI estimate based on listed Tool prices is not an accounting formula or funding guarantee. Choose funding from the signed `occurrence_budget_mist` and the on-chain gas/priority split described in [Payment Vaults, Reserves, and Settlement](/concepts/06-payment-vaults-reserves-and-settlement.md), not from this display. * **Execution History** — the workflow's runs with their outcome (**Success**, **Failed**, **Incomplete**), loading more as you scroll; each opens [its execution page](/guides/vision-explorer/inspecting-runs.md). A workflow with many successful runs by many callers reads very differently from one that has never run. * Where the workflow is bound to a skill, a **Skill** link back to [the agent that owns it](/guides/vision-explorer/checking-agents.md).
A workflow page with its graph, tool list and execution history

A workflow page: the graph as the chain stored it, the tools its vertices call, and its execution history.

#### The one check worth making after you publish The DAG document parser drops fields it does not recognise instead of rejecting them, so a hand-edited document can "publish successfully" while silently losing something you wrote. The graph on this page is decoded from the chain, not from your draft — **if a default value, entry group, or edge you configured is missing here, it is missing on chain.** Follow [DAG Construction](/guides/dag-construction.md) for the wallet-authorized publication and verification path. #### Running or copying it Treat the decoded workflow as read-only verification evidence. To create a replacement, export or reconstruct an editable DAG through the documented CLI or SDK path, then publish it only after verifying the required inputs, funding, selected Agent/skill, admission, and Tool/application authorization. A shared graph alone does not authorize a run. --- # 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/guides/vision-explorer/checking-workflows.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.