Coverage

It is a progress indicator. It counts records; it does not judge them. A thin statement moves the number exactly as much as a thorough one, because Clause50 has no way to weigh the difference and pretending otherwise would be the dishonest choice.

So the score is genuinely useful to you as a measure of how much of the work is done, and genuinely not a compliance verdict for anyone else. Nobody should read a percentage here as a statement that a system complies with anything.

One edge worth knowing: a system with no in-force duties at all scores 100%. There is nothing to prove, and the alternative — inventing a denominator — would be worse.

• SatisfiedEvidence exists that meets this requirement in full, and is current.
• PartialSome of what the requirement asks for is covered and some is not — typically where the requirement lists several points and only some have been addressed.
• MissingNothing on the record addresses this requirement.
• StaleEvidence existed and satisfied this requirement, but has aged out of the window it had to be repeated in, or is tied to a superseded version of the system record. A separate status from missing because the work differs: refresh something you had, rather than produce something you never had.

You may also see unknown on the detail page. That is not a stored status — it is what a requirement shows when it applies to you but was not part of the last calculation, usually because the rule pack has changed since, or because coverage has never been computed for this system. Clause50 shows unknown rather than guessing at a status it has not worked out.

A gap is any applicable requirement that is not satisfied — the count on your dashboard is simply partial plus missing plus stale. It is the actionable list: how many things stand between you and a complete record.

On the per-system coverage page every gap carries a Fix link, and the link knows where to send you. Requirements fed by connectors point at the connectors page; requirements closed by a person or a document point at the evidence page. You do not have to work out which kind of evidence a given requirement will accept.

Some duties in the rule pack have a date on which they begin to apply — the high-risk requirements ahead of 2 December 2027 are the main example. If such a duty applies to your system but that date has not arrived, Clause50 lists its requirements in a separate Upcoming section, marks them as excluded from the score, and does not count them as gaps.

The reason is that a score is only useful if it answers one question. Folding not-yet-applicable duties in would answer two badly at once: an organisation fully on top of everything currently required would show a mediocre number with no way to tell whether that reflected a present failure or a future deadline. Worse, the number would drop on a date when nothing about the system had changed.

They are still shown, because they are the ones worth planning for. An upcoming duty is not a warning to ignore; it is a warning with a date attached.

Recalculating means re-examining every applicable requirement against your current evidence and your current record, and storing a new result with a fresh timestamp. Your dashboard and coverage page always show the most recent stored result, and always show when it was taken. That happens in three ways.

• Automatically, every hourA scheduled pass checks each system and recalculates any whose stored result has fallen behind — because evidence was recorded after it was taken, because a new record version was opened, because Clause50 loaded a newer rule pack, because the system has never been calculated at all, or simply because the result is more than a day old and a repeating requirement's window may have rolled over since. So the score you see is at most about an hour behind reality, without you doing anything.
• Immediately, when you save the intakeSaving your answers recalculates on the spot and shows you the new score, because a changed answer can add or remove whole obligations and waiting an hour to find out would be the wrong behaviour. Retracting an evidence item does the same. See Systems and intake.
• On demand, when you press RecomputeThe button sits on both the coverage page and the evidence page. It does exactly what the hourly pass does, just now. You need it for impatience, not for correctness — most usefully right after recording evidence, when you want to see the gap close rather than wait, or just before producing a document you care about.

What never recalculates is opening a page. This is deliberate, and it is the reason the timestamp is displayed: each result is a dated record in its own right — documents cite it, alerts are derived from it — so results are produced by the scheduled pass or by an explicit action, never churned by someone browsing. A score with an old timestamp means the pass found nothing to change, not that it stopped running.

One consequence worth knowing: generating a document always recalculates first, as part of the run, so a document can never be built on a stale figure even if you skip every button on this page.

Section 6a, “Basis of assessment”, lists every evidence item this pack's scoring engine actually relied on to decide each requirement's status — not every item of a matching kind, but the specific items the verdict is a function of, for every requirement whether it was satisfied, partial, missing or stale. Each row shows its content hash, the requirement(s) it was relied on for, who attested it, and — for a manual attestation — exactly which checklist items were claimed; where an item was relied on by more than one requirement, every one is listed. This register does not confirm that a claim is true — only this app's stated evidence checks can do that, and are reflected in the coverage score above — but it puts the claim itself, the claimant, and any correlated document side by side in the signed document, so a later audit can compare what was asserted against what was actually submitted. Section 6b, “Evidence shipped, not relied on”, lists evidence held in this system's chain and included with this pack for completeness — the operator's own uploads and connector data — that no requirement in this pack relied on to reach its status; a further count of unbundled chain items, by kind, follows for full disclosure. The hashes throughout tie back to the append-only evidence chain and to the signed manifest accompanying this document.

The files themselves travel with the pack, not just their hashes. A register that cited evidence by fingerprint while shipping nothing to check the fingerprint against would be decorative: the auditor would hold a digest and no document. Every uploaded file the pack cites is included in the download, in an evidence/ folder with a README mapping each register row to its file and hash. See what is in the download.

Some requirements need both a document and a statement about it — an upload alone will not turn them green. The evidence page shows these as two-step requirements, so an uploaded file that leaves a requirement unmet is not a silent dead end: the second step (a checklist attestation) is named right there.

The dashboard and the per-system coverage page both show the state of that system's connectors: how many there are, when they last collected anything, and any that are failing along with the reason.

That is there on purpose. A requirement showing missing because a token expired three weeks ago is not a compliance problem, it is a broken connector — and a coverage view that hid this would send you looking in the wrong place. Stored credentials are never displayed.