Skip to main content

Documentation

Understanding your report

Every assessment lands you on a report page with three sections: the summary cards, the verdicts grouped by clause, and the gap analysis for higher tiers. This page explains exactly what each part means and what to do when something is not green.

The four verdicts

  • Pass - the control's check ran, the evidence satisfied it, no further action required for this rule.
  • Fail - the check ran, the evidence violated the rule. The verdict's note says what specifically went wrong (e.g. "status JSON Object is missing the type member"). This is actionable: fix the underlying issue and re-run.
  • Warn - a soft signal. The control says "should" rather than "shall", or the engine cannot fully judge without external data (trust list, notified-body cert) and surfaces a heads-up. Read the note; decide whether the warn is acceptable for your context.
  • N/A - the check skipped because the evidence does not apply (e.g. a status check on a credential without a status component) or because the control is not auto-tested yet. The note distinguishes the two cases.

Summary cards: what they count

The four cards at the top sum verdicts across the auto-tested controls only. Controls that are not yet auto-tested are excluded from the cards' counts and called out separately on the line "X of Y controls in scope aren't auto-tested yet". This prevents the N/A card from inflating with the catalogue-coverage gap.

Verdicts grouped by clause

Below the cards, every active verdict is grouped under its top-level clause (5.1, 5.2, 5.5, etc.) in a collapsible section. Each row shows:

  • The canonical control id, linked to its catalogue page.
  • The status pill (pass / fail / warn / na).
  • The check's note, explaining what was evaluated.

Click a control id to read the full spec text, the plain-English explanation, the common mistakes, and related controls.

Gap analysis: would this credential pass at a higher tier?

Below the verdicts, the gap-analysis section projects the same evidence to QEAA and PuB-EAA. Two complementary signals per higher tier:

  • Would fail at this tier. Behaviour-aware: the engine re-runs at the higher tier and reports any control that fails. Captures rules whose check function changes by tier (e.g. the shortLived/status mutex strict at QEAA, permissive at Ordinary).
  • Additionally required at tier. Catalogue-level: controls whose applies_to includes the higher tier but not your current tier, and which are not already passing. The "you would need to address N additional controls" callout.

When both signals are clear across every higher tier, the section opens with a confidence-building emerald banner: "This EAA satisfies all controls required for QEAA and PuB-EAA tiers."

What to do with a fail

Click the failing control id to land on its catalogue page. The page explains the rule in plain English, lists common mistakes, and links to related controls. Most fails on structural rules are one-line fixes: a missing claim, a wrong type, a misspelt member name. After the fix, re-run the assessment; the verdict should flip to pass.

For runtime fails (status list resolver), the verdict's note names the most likely causes (CORS not configured, wrong content-type, index out of range). Fix the upstream service, re-run.

If you think a fail is wrong (the engine is misreading the spec), open an issue on GitHub with the offending compact form and the verdict; we treat accuracy bugs as the highest-priority class.

Sharing the report

Below the gap analysis, an email gate unlocks two downloads: a PDF suitable for circulating to stakeholders, and a JSON file with the raw AssessmentResult shape if you want to consume it from your own tooling. Both are produced client-side; nothing is uploaded.

The email is stored in your browser only and used to gate the downloads on this device. Clearing site data removes both the report and the email at once. See the Privacy page for the full picture.

Last reviewed 02/05/2026. All documentation · Back to the Hub ·