Coverage and Fidelity
Before relying on a piece of documentation, you need to know three things: what it covers, what it is worth, and how current it is. Coverage and fidelity (in the Quality group of the portal rail) answers them in three tabs:
| Tab | Question it answers |
|---|---|
| Coverage | What did the scan see, document, and deliberately leave out? |
| Verification | How faithful is the documentation to your org's actual metadata? |
| Versions | Which business rules were added, modified or removed between two scans? |
All three refer to the version selected in the portal. They are available on every plan.
Coverage (scan perimeter)
The Scan perimeter page shows what the scan saw, what it documented, and what it excluded by design. It is produced at the end of each scan.
Objects
- Objects scanned and Objects documented.
- Data-only objects -- documented through their field glossary because they carry no business rules.
- Objects not documented -- objects whose business rules could not be generated in this scan, although automation exists in the org. They are listed so that a missing page is never mistaken for an object without rules.
Completeness by metadata type
For each metadata type: how many components were Listed, Fetched, Analyzed and Documented, and how many were excluded by design. Each type carries a status such as Fully analyzed, Partially analyzed or Partially fetched; use View affected items to see the exact components concerned. Exclusions by design include managed-package metadata (excluded by default), types that are only inventoried, and inputs used as context rather than documented.
Other sections
- Global analysis perimeter -- elements left out of the org-wide overview because of the model's size budget. Their own pages are unaffected.
- Build substrates -- optional inputs of the documentation build and their state (Loaded, Empty, Failed). A failed input degrades only the sections that depend on it.
- A notice when the functional process map could not be produced for this version.
Use this page when a figure looks lower than expected, or before handing the documentation to an auditor.
Verification (fidelity certificate)
During each scan, before the collected metadata is purged, aprity samples statements from your documentation and checks them against the source metadata of your org. The result is the fidelity certificate.
What the certificate shows:
- Fidelity score -- the mean of per-item scores (0-100) over the items actually audited.
- Artefacts audited, Verified claims, and Divergences -- statements contradicted by the source, shown in full.
- By verification mode -- the score split between Verified without AI (deterministic checks against the org model, for example field and permission facts) and Reviewed by a judge model (narrative content). The overall score is weighted by the number of items in each mode.
- Verification status of each mode: Measured, Not measured, Incomplete verification, and so on. An incomplete sample is flagged as such.
- Verification scope -- what the score does not reach: objects for which no documentation was produced, and content families that no verifier samples. The score says nothing, good or bad, about what it does not cover.
- Scope and sampling -- per content type, the population, the sample size, the number audited and the caps applied.
- For each audited item, its verdict (Faithful, Mostly faithful, Divergent, Misleading, Not verifiable) and, for each claim, the verdict with the verbatim source excerpt (Show source excerpt).
The score covers only what was verified, for the stated sample. It does not measure the completeness of the documentation, nor the business correctness of your org.
Verify this document yourself
From the certificate you can open Verify this document, a protocol for checking the documentation independently:
- Choose a sample size (10, 15 or 25 rules).
- Draw rules at random. The draw is derived from a seed that you can keep and replay, so the sample cannot be hand-picked.
- For each rule, compare the narrative with the verbatim source, open the component in Salesforce Setup, and record your verdict.
Keep in mind that the documentation describes a snapshot of the org at scan time: if a component changed since, a difference reflects freshness, not fidelity.
Versions (change history)
The Change history tab lists the business rules Added, Modified and Removed in your org between analyses, most recent first, with filters by kind of change. For a modified rule, the changed fields are shown (title, condition, action, business relevance, error message).
When two analyses cannot be compared honestly -- different perimeter, different output language, an aprity engine upgrade that re-derived the rules -- the page shows a notice instead of reporting differences that are not real changes in your org.
See Business Rule Evolution for details.