Reviewing Results¶

After a validation run completes, you'll want to understand what passed, what failed, and why. This guide explains how to interpret findings, navigate the results interface, and share outcomes with your team.

The Run Summary¶

When you open a completed run, you'll see the summary panel at the top:

Status badge: Shows the overall outcome (SUCCEEDED, FAILED, CANCELED, etc.)

Result: The automation-friendly conclusion:

• PASS — No errors found; the data meets all requirements
• FAIL — Errors were found; the data didn't pass validation
• ERROR — Something went wrong during validation (not a data problem)

Timestamps: When the run started and ended, plus total duration

Workflow link: Click to see the workflow definition that was used

Submission info: The filename, size, and content type of what was validated

Step-by-Step Results¶

Below the summary, you'll see each workflow step with its individual outcome. Steps are shown in execution order.

Step Status Icons¶

• ✓ Passed — This step completed without errors
• ✗ Failed — This step found errors or encountered a problem
• ⏸ Skipped — This step didn't run (usually because a previous step failed)
• ⏳ Running — This step is currently executing

Expanding Step Details¶

Click on any step to expand its details:

Validator info: Which validator ran and what it checked

Findings: The specific issues found by this step

Assertions evaluated: How many rules were checked and how many passed

Duration: How long this step took to execute

Output: For advanced validators, you may see additional output data or signals extracted from the validation process

Understanding Findings¶

Findings are the core output of validation. Each finding represents something the validator noticed about your data.

Severity Levels¶

Finding Details¶

Each finding includes:

Message: A human-readable description of what was found. For example: "Required property 'name' is missing" or "Value exceeds maximum threshold of 100."

Path: For structured data (JSON, XML), this shows where in the document the issue was found. For example: data.users[0].email or /building/zone[2]/name.

Code: A machine-readable identifier for the issue type. Useful for automation and filtering.

Source: Which assertion or rule generated this finding.

Reading JSON Paths¶

When reviewing findings for JSON data, paths use dot notation:

• root.field — A field called "field" inside the root object
• items[0] — The first element of an array called "items"
• users[2].address.city — The city field, inside the address of the third user

Reading XML Paths¶

For XML documents, paths use XPath-style notation:

• /root/element — An element inside the root
• /root/items/item[1] — The first item element
• /root/element/@attribute — An attribute on an element

Filtering and Searching Findings¶

For runs with many findings, use the filtering options:

By severity: Show only errors, only warnings, or all findings

By step: Focus on findings from a specific workflow step

Search: Type keywords to find specific findings by message content

Assertion Statistics¶

At the bottom of each step (and summarized for the run), you'll see assertion statistics:

• Total assertions: How many rules were evaluated
• Passed: Rules that succeeded
• Failed: Rules that generated error findings
• Warnings: Rules that generated warning findings

These totals include both default assertions (defined by the validator author) and step assertions (defined by the workflow author). Both tiers contribute equally to the statistics, so you get a complete picture of how thoroughly your data was checked.

Sharing Results¶

Copying Run Links¶

To share a run with teammates:

1. From the run detail page, copy the URL from your browser
2. Share it with anyone who has access to the organization

Recipients need at least Viewer access to see the run details.

Exporting Results¶

Depending on your Validibot edition, you may be able to export results:

JSON export: Structured format for integrations or archival

PDF report: Formatted document for stakeholders (Pro edition)

Evidence and Credentials¶

Every completed run produces an evidence manifest — a structured, hashed JSON document recording exactly what was checked, by which validator versions, against which input contract, with what result. On Pro deployments, the run also produces a signed credential that lets anyone verify the result without trusting your deployment.

Both of these are reachable from the run detail sidebar after a run completes.

Three ways to download evidence¶

The run detail page shows up to two cards in the sidebar — what you see depends on your edition.

Evidence Manifest card (always shown when a manifest exists):

• Download manifest.json — just the canonical JSON document. Useful when you want to read the provenance record (which workflow, which validators, which contract) without needing cryptographic verification.
• Download bundle (.tar.gz) — a tarball containing the manifest, the signature (on Pro), and a README.txt explaining how to verify. Useful for archival, audit submission, or sharing the full evidence package.

Signed Credential card (Pro only, when a credential was issued):

• Download Credential — the verifiable credential as credential.jwt. Useful when someone just wants the credential itself to verify against your deployment's published key.

Which one should I send?¶

You don't need to unzip the bundle to get the credential — credential.jwt is downloadable separately and is byte-identical to the manifest.sig inside the bundle.

What can I prove with each tier?¶

The evidence story is deliberately split between editions:

Think of it like notarization: Community gives you a record with your initials on it; Pro adds a notary stamp that anyone can verify against the notary's public registry. Both are useful for different audiences. Community works well for internal records, self-trust, and "show me what happened." Pro is required when the verifier doesn't trust you — regulators, third-party auditors, prospective tenants doing due diligence on your sustainability claims, and any compliance regime that requires cryptographic attestation.

For more on what Pro adds beyond evidence, see Self-Hosted Editions.

Verifying a credential¶

A credential or bundle can be verified at any time:

1. Open the public verification page at /credentials/verify/
2. Upload credential.jwt (or the full bundle .tar.gz)
3. The page recomputes the signature against the issuer's public key (published at /.well-known/jwks.json) and shows ✅ Valid or ❌ Invalid

Independent verification using any standards-compliant JWS library is also supported — the verifier just needs the public key from the JWKS endpoint. No relationship with Validibot or your deployment is required.

Public vs Private Information¶

Some workflows include a "public information" description that's visible to anyone. The actual findings and detailed results are only visible to organization members with appropriate access.

Comparing Runs¶

To see how validation results change over time:

1. Navigate to the workflow detail page
2. View the list of recent runs
3. Compare status and finding counts across runs

This helps identify whether data quality is improving or if new issues have been introduced.

What to Do When Validation Fails¶

When a run fails, here's a systematic approach:

1. Check the error findings: Start with ERROR-level findings since they caused the failure

2. Identify the pattern: Are all errors from one step? One type of issue? This suggests where to focus

3. Review the data: Use the path information to find the problematic section in your source data

4. Fix and rerun: Correct the issues in your data and run the validation again

5. Check warnings too: Once errors are fixed, review warnings for additional quality improvements

Understanding Error Categories¶

Sometimes runs fail not because of data problems but due to system issues. The error category helps distinguish:

Data errors: Your data didn't meet the validation rules. Fix the data and rerun.

Configuration errors: Something's wrong with the workflow or validator setup. Contact your workflow author.

System errors: A technical problem occurred. Try again, or contact your administrator if it persists.

Timeout errors: The validation took too long. This might indicate overly complex data or resource constraints.