Report sections and findings

The report is what a buyer pays for. In a workflow you declare its sections and typed findings, then fill each finding from a step's value. This page covers declaring sections, filling them, how findings map to evidence, and the rules that make a report complete. It is for creators designing a workflow's output.

How a report is put together#

Three parts of the builder work together:

Adding Report section from the library creates all three at once: a section called "Section 1" (the first one you add is required) with one finding, a step that fills it from the most recent data or transform step, and its entry in the report output. Rename the section and its findings in Settings.

Declare sections and findings#

In Settings → Report sections:

• Section title: up to 100 characters. Buyers see it as the section heading.
• Required for a complete result: a required section must be complete for the report to be complete. See Complete reports.
• Each finding has a Code (an identifier such as total-supply), a Label (up to 100 characters, what buyers see) and a Type.
• Add finding adds a finding to that section; the bin button removes one.
• New section title and Add output section add a section without a step. You then need a report section step to fill it.

A workflow has 1 to 12 sections, and each section has 1 to 16 findings.

Changing a finding's code in Settings updates the steps that fill it.

Fill a section#

Select a report section step. In Step settings:

1. Fills the report section: the declared section this step fills. Each section can be filled by one step only.
2. For each Finding N: choose the Finding (listed as "Label · Type") and its Value: an input, a step's output field or result, or a fixed value.
3. Add finding fills another declared finding of the section.
4. Under Depends on, tick every step whose values the findings use.

"Findings cite the evidence of the steps their values came from; values taken straight from inputs are labelled as not observed."

Finding statuses#

Each finding in a report has one status:

Unknown values establish nothing. Every report states: "Skipped steps and unknown values establish nothing, including the absence of a risk or control."

How findings map to evidence#

Every read a data step makes is stored as an evidence item with a content-derived id. A finding lists the ids of the evidence behind its value:

• a value from a data step cites that step's evidence;
• a transform or condition passes on the evidence of the values it used;
• an AI analysis result cites the evidence its accepted claims cited.

In the report, each finding links to those evidence items, and each item says what it proves, the observation, its source and method, and the block or slot it was read at. See Evidence.

Complete reports#

A report's status is decided after every step has run:

A paid run charges the buyer only when its report meets the workflow result contract:

1. The run did not fail, and the report is bound to the exact version and the buyer's input.
2. The version declares at least one required section, and every required section is complete.
3. Every finding in the required sections is observed or from input, and observed findings cite complete evidence.
4. At least one finding in the report is backed by tool evidence.
5. No evidence changed canonicality, and the run recorded no permission, integrity or disabled-capability failure.

Otherwise the whole reservation returns to the buyer. The same contract decides whether a test can be submitted for review, published or shown as a saved example.

Report layout#

A report opens in the standard report view with Overview, Findings, Evidence, Sources, Execution and Export tabs. A workflow built in the builder uses the generic layout, titled "Workflow Report": each section is shown as a labelled list of its findings, followed by the limitations. The six report archetypes (token-protocol, wallet-flow, contract-security, market-liquidity, governance-treasury and monitoring-events), with their headline metrics, tables and charts, are declared by the first-party research workflows; the builder has no setting for them. See How reports work.

Every workflow report also lists its limitations, starting with any limits the tools stated for this run, followed by the general ones:

• "Conditions and built-in transforms are exact comparisons over captured values."
• "Tool evidence comes from the configured providers through read-only calls. It is not an independent attestation, audit, security score or investment recommendation."
• "Skipped steps and unknown values establish nothing, including the absence of a risk or control."
• "Each tool pins its own snapshot; facts from different steps may come from different blocks unless their evidence shows the same snapshot."
• "Provider cost is not priced for this run."

Sample output#

Settings → Sample output (under the advanced groups) lets you type an example value for each declared finding. Each value must match its finding's type, or validation reports "The sample value for (finding) must be (type)." The builder describes sample output as shown on the listing; the listing page currently shows your saved example instead (see Publish a listing).

Related pages#

• Conditions and transforms
• Test privately
• How reports work