Coverage

The point of testing under regulation isn’t just that tests pass — it’s that every requirement is verified. Coverage is the live measure of that: which requirements have tests behind them, and whether those tests are passing.

What coverage means here

Coverage comes directly from the thread. A requirement is covered when test cases are linked to it as its verification; it’s demonstrably covered when those tests have been run and passed. Because the links are real and the runs are recorded, coverage isn’t an estimate — it’s computed from the actual relationships and results in the system.

Finding the gaps

The value of coverage is in what it exposes. It surfaces uncovered requirements — requirements with no test verifying them, the gaps that sink an audit — and, conversely, tests that don’t trace to any requirement. Closing those gaps is concrete work: link a test to the requirement it verifies, or write the test that’s missing.

Coverage stays current

Coverage isn’t a report you generate once. As you add links, run tests, and change requirements, it updates — and when a verified requirement changes, its tests are flagged suspect so the coverage you’re relying on doesn’t quietly go stale. A requirement can be “covered” on paper yet need re-verification, and the platform makes that distinction visible.

Where to see it

Coverage shows up where you need it: as a signal on requirements and tests, rolled up on your dashboards for a program-wide view, and in the reports that compile it into the trace and coverage documents an auditor asks for. The relationships behind it — the trace matrix, suspect links, and impact analysis — are covered in Traceability.