Generating a conformance report

A report records every reportable artefact loaded in the Playground (credentials still locked by encryption are left out) and the result of each check that ran on it. It is generated on demand from what is on screen, and downloaded as HTML or JSON.

When Generate Report is available

The Generate Report button is enabled once at least one reportable credential, conformity scheme or link set is loaded (a locked credential alone does not count), every credential and scheme has settled, and every link set's Schema Validation step has settled:

• Every credential and every conformity scheme must have a settled result. A card still verifying holds the button.
• A link set must have a settled Schema Validation step. Its Link Type Coverage step counts how many linked credentials you have verified so far, so it can still be pending; that does not hold the button.
• Encrypted credentials that have not been decrypted are not part of the report and do not hold the button.

A link set on its own is enough to generate a report.

A generated report describes the screen at the moment it was made. Adding, replacing or removing an artefact, verifying or re-verifying a linked credential, or decrypting a credential discards it, and Download Report is disabled until you generate again.

What the report contains

Three sections, each shown only when its family has at least one entry, with an instance count in the heading:

• Verifiable Credentials, grouped by credential type in the order of the Credentials tab (Digital Product Passport, Digital Conformity Credential, and so on), each group headed by the type name and its instance count. Each block is titled the way its card is: the filename, or the final path segment of the URL it was fetched from, else the credential type; never the raw URL. A credential decrypted in the browser lists Decryption as its first step; an unencrypted credential has no such step.
• Conformity Schemes, one block per scheme, titled by the scheme's own name when it is not blank, else the final path segment of its URL, else its filename, else Conformity Scheme. Each block carries four steps: Version Detection, Schema Validation, Structural Parse and JSON-LD Document Expansion and Context Validation. Structural Parse reads the scheme with the parser the rest of the toolchain uses and lists each field it rejects, so a blank required value is reported even where the published schema accepts an empty string. A failure established as a fault in the scheme is labelled Scheme invalid; a fetch or unusable-artefact failure keeps its own class label. A step an earlier failure prevented from running is recorded as a failure labelled Not executed, naming the blocking step. A scheme whose declared version has no parser is a fault in the scheme and is labelled Scheme invalid.
• Identity Resolver Link Sets, one block per link set, subtitled Link Set and the UNTP spec version it was validated against, with Schema Validation then Link Type Coverage. A failed Schema Validation lists each offending path and the rule it broke, or explains that the schema could not be loaded or used. Link Type Coverage shows n of m credential links checked, or says there are no UNTP-relation credential links to check when the link set lists none. It lists each mismatch as <relation> link resolved to <detected type> with the link's href. A pending coverage step means some linked credentials were not verified when the report was generated; it does not fail the link set. A mismatch does.

Each failed step may also carry a failure object. Its machine class is could-not-fetch, unusable-artefact, credential-invalid or unknown. credential-invalid means the fault is in the submitted document: either it failed validation against an artefact that was fetched and used, or it declared a type or version the Playground could not match to any artefact. The HTML report opens the step's failure line with that class, Credential invalid on a credential or extension step and Scheme invalid on a scheme step. A failed link-set schema step carries its failure in the JSON report only. The object also records the diagnostic code, message, remediation, and, when known, artefactUrl, serviceStatus, upstreamStatus, declaredVersion, and blockedBy naming the earlier step whose failure stopped this one from running.

The VCDM Version Detection step records a failure class with View Details when the declared VCDM version cannot be mapped. If an upstream host returns an HTTP 403, 404 or 410 for a schema or declared context URL and no bundled copy exists, the artefact is reported as not published for the declared version. Other 4xx responses, including 408 and 429, remain could-not-fetch with retry-or-report remediation. A third-party context URL is named as its own missing @context entry without a UNTP version claim. A 403, 404 or 410 for a dependency imported by a declared context remains could-not-fetch and names the dependency. When the document declares a single context URL and the declaration walk completes, the report names that declaring context. Otherwise, including when the document is too large for the Playground to trace fully, it names only the dependency and status without asserting which context imported it. It directs the dependency's publisher to publish it. Link-set schema fetches are excluded: a 4xx remains could-not-fetch and advises picking a UNTP version with a published link-set schema. HTTP 5xx, network and timeout failures remain could-not-fetch, and a bundled copy is still used when one is available.

Context retrieval has two budgets: the server-side resolver gives up on any single context fetch after 10 seconds, while the browser allows up to 60 seconds for the whole check, covering the request, the server's expansion of the document and the response body. A proxy in front of a deployment may end the request sooner. This applies to credential and Conformity Scheme context checks.

The report passes when every entry passes.

The JSON report

The JSON download carries the same content as the HTML without the grouping, which is a reading aid. Its top-level fields:

Field	Contents
verifiableCredentials	One entry per credential instance, in upload order. Each has title, status, core (type, version, steps), source when the origin is known (for a credential verified from a link set, source.via is link-set and source.linkSet names that link set by its resolver URL or filename), and extension when one was detected. Failed core or extension steps may carry the additive failure object.
conformitySchemes	One entry per scheme instance, in upload order. Each has title, status, type, version, steps, the conformityScheme document, source when the origin is known, and name and id when the document carries them. title is what the HTML shows; name is the document's own field, present only when it has one. Failed steps may carry failure.
linkSets	One entry per link set, in upload order. Each has title, status, validationVersion, source when the origin is known, the linkSet document and exactly two steps: the schema step with its recorded attempt (always kind, version and schemaUrl, then the validation errors when the schema ran, a reason and a message when it could not be loaded, or a message alone when it loaded but could not be used) and the coverage step with total, checked, mismatches, and a note when there was nothing to check. A failed schema step may carry failure. Its reason retains timeout, not-found, parse and network, and may also be unreadable-response. The coverage step is the only step whose status can be pending.
pass	true when every entry in every family passes.

A scheme's Structural Parse step carries more in the JSON than the HTML shows. Its details.diagnostics holds one entry per structural fault, each with a code and, where the parser records them, a pointer to the field, the received value and the expected one. A step that did not run carries skipped, and blockedBy naming the earlier step that prevented it when one did; its status is still FAILURE. The HTML report shows the messages only.

All three family arrays are always present, empty when nothing of that family was loaded.

The scheme array was called conformitySchemeResults in Playground 0.3.0, and every entry carried a duplicate overallStatus beside status; both are gone. Tools reading them need updating.