Inside DOVU Flow: How Flows, Runs and Records Make Every Credit Auditable, and Where $DOVU Actually Does Work

Carbon markets have a trust problem, and it is not really about the credits. It is about the paperwork behind them. A credit can be scientifically sound and still be commercially worthless if a buyer cannot verify how it was created, who approved it, or whether it is actually what they paid for, let alone understand the terminology used to describe it. Most registries answer that problem with a PDF. We think the answer should be a ledger you can query, inspect and compare yourself.

That is what DOVU Flow is built to coordinate. An operator publishes a Run through the console, participants complete their assigned actions through a separate email and QR-based signing application, and the console shows their signed Records arriving in real time. When the Flow completes, DOVU Explorer automatically renders the resulting asset as an indexed and searchable provenance asset.

The console is the observability layer inside that process. It gives you a view into every Flow, Run and Record moving through the platform, showing exactly what happened at every step and the evidence behind it.

Watch the walkthrough: Jon demonstrates how a Run moves through DOVU Flow from submitted data to issued assets.

Flows, not one-off scripts

A Flow defines the intent of a process. It is a sequence of Tasks that describes what needs to happen, what data each Task accepts and which Role is allowed to act on it. Actors progress through those Tasks until the Flow completes and triggers its consequence.

In the walkthrough we recorded, the Flow is called dovu-trust-choice. It is useful precisely because it is generic. It tests a decision path rather than one specific type of credit. The same underlying structure is already being used for a Carbon Border Adjustment Mechanism scenario, renewable energy certificate issuance, and animal identity and vaccination records. One engine, several asset classes.

A live Run moving through verification, branching and issuance.

Each Flow is built from a small set of Task types:

• Data Tasks capture an input and record who submitted it, what schema it follows, and what Role is allowed to process it.
• Decision Tasks verify that data against the schema and against the rules of the Flow — approved or not, with a signed record of who made the call.
• Branch Tasks let a single Flow split into multiple parallel paths, which matters when several parties or several data points need to be evaluated independently before the Flow can continue.
• Mint Tasks issue the asset once everything upstream has been validated and approved.

That is the whole vocabulary. Complexity comes from how those Tasks are arranged, not from adding hundreds of special cases. This is deliberate. It is easier to understand and audit a system built from a few clear primitives than one built from endless bespoke rules.

From a published Run to a searchable asset

A Flow is the reusable process definition. A Run is a live execution of that process. An operator publishes a Run through the DOVU Flow console and assigns or opens the Roles required by the Flow.

Participants do not need access to the console itself. They receive an email link or scan a QR code, then use DOVU’s signing application on desktop or mobile to complete the Task assigned to their Role. That action might involve submitting data, uploading evidence, making a decision, approving an earlier submission or signing an attestation.

Each completed action creates a signed Record, which appears in the Run timeline as it arrives. Several independent actors can therefore complete the process together while everyone watches the provenance of the asset assemble in real time. Once the final conditions of the Flow are satisfied, the asset is issued and automatically made available through DOVU Explorer, where its attributes and supporting Records are immediately indexed and searchable.

The three surfaces have distinct jobs. The console is used to publish and observe the Run. The signing application is used by participants to submit and sign data. The Explorer is where the completed asset can be searched, inspected and compared.

Where $DOVU actually does work

Processing a Task inside a Run is not free, and that is the point. Open the inspector on any Task and, alongside the Record data, there is a Cost field. That cost is denominated in $DOVU, with its fiat equivalent shown next to it.

In the Run below, the branch step splits into three parallel Data Tasks. Each carries its own $DOVU processing cost as it moves from submission to validation.

Each Task records its processing cost in $DOVU.

This is where $DOVU actually does work inside DOVU OS. It is the unit of account for executing the trust process. Every data submission, decision check, branch evaluation and mint represents a discrete piece of computational and consensus work, priced and paid for in $DOVU Task by Task rather than hidden inside an opaque platform fee.

That is meaningfully different from treating a token as an incentive added on top of a product after the fact. Here, the token meters the infrastructure itself. It serves a similar purpose to gas on a general-purpose chain, but each unit of execution relates to a specific and auditable step in the lifecycle of a real-world asset, such as a submission, schema check, approval, branch evaluation or issuance.

Every Run, verifiable

The part that matters most is not the workflow diagram. It is the evidence arriving behind it. As participants submit, approve and sign through the signing application, their Records appear in the Run timeline.

Click into any Task and the inspector shows the account that processed it, the schema it validated against, when it started, when it completed and its $DOVU cost record. Underneath that sits a cryptographic digest of the data, allowing someone to confirm that it has not been changed since it was submitted. Underneath that is the Record itself, a consensus message anchored to Hedera, viewable through HashScan and linked to the source data on IPFS.

Once every upstream Task in a path has been approved, the Mint Task executes and the asset is issued. It becomes immediately visible inside the Run with its own Record.

Once the Run completes, the issued assets and their supporting evidence are immediately visible.

In practice, this means a buyer does not have to take a registry’s word for the history of a credit. They can trace which account submitted the data, who approved it, when they acted, which schema was applied, what it cost to process in $DOVU and where the underlying Record lives.

The console also includes a timeline scrubber for every Run. This allows the process to be replayed Task by Task, showing the Record history and associated $DOVU spend building exactly as it happened.

Why this is infrastructure, not a feature

It would be easy to describe this as a workflow dashboard, but the dashboard is only the visible control surface. DOVU is built around a bigger idea. Different industries should not need to adopt the same data model in order to share the same trust infrastructure.

A shipping container can carry food, machinery or electronics because it does not standardise the cargo itself. It standardises the boundary around the cargo, including how it is identified, handled, transferred and inspected. That shared structure allows ports, ships, trains and warehouses to coordinate without needing to understand every individual item inside every container.

A Flow serves a similar purpose for digital provenance. The underlying evidence might describe a carbon project, a renewable energy certificate, a steel shipment, an animal vaccination or another real-world event. Those things are not the same, and DOVU OS does not try to flatten them into one generic data model.

Instead, it gives them a consistent outer structure. Roles define who may act. Tasks define what must happen. Schemas define what valid data looks like. Signed Records preserve what happened. Runs coordinate the process. The Explorer turns the completed result into an indexed and searchable asset.

The console is where the Run is published and observed. The signing application is where independent actors submit evidence, make decisions and sign their contributions. As those Records arrive, the provenance of the asset assembles in real time. When the Flow completes, DOVU Explorer automatically renders the result using the schemas and Records produced during the Run.

This is the meta-structure DOVU OS provides. It is not one universal format for every asset. It is a universal way to describe how evidence moves, who acted on it, which rules were applied and what asset emerged from the process.

DOVU standardises the container, not the cargo.

The same trust container can work across different industries without pretending that the underlying assets are interchangeable. A carbon credit and an animal identity record remain fundamentally different things, but their provenance can be created, verified, indexed and queried through the same infrastructure.

That is why DOVU Flow is more than a workflow feature. It is an interoperability layer for producing trusted assets.

Publish the Run. Invite the actors. Watch the signed Records arrive. Then search and inspect the assets they created together.

This is how DOVU Flow turns a multi-party process into a provenance asset that can be independently checked.