Corvair CorvairKnowledge Substrate
Home / Docs / Coverage report
New deliverable

How well does the base cover this, and where is it weak?

A coverage report documents how complete and healthy a knowledge cluster is, a branch, a topic, or the whole base, read through a frame. Where an analytical deliverable answers a question from the base, a coverage report answers a question about the base. It reads weakness-first and ends in actions, each routable straight into curation.

desktop_windowsSee it in the preview descriptionAll deliverables hubThe Canvas

What it is

A coverage report turns the cluster's coverage read into a structured, warranted document. It is the productised form of the coverage figures the FrameGraph already computes: the match between the expected questions and the generated subsets, the source counts and tiers per aspect, the decaying premises, and the conflicts. It is a governance artifact, not an answer.

Every framed view in the Canvas already carries a one-line coverage read in its Knowledge cluster. The coverage report is that read, made complete and signed: it names what is strong, what is thin, and what is missing, with a candidate source pre-staged for each gap and a prioritised list of actions at the end.

troubleshoot
It reads weakness-first. A coverage report is not a scorecard to file away. It leads with the gaps, the decay, and the conflicts, and every recommendation it makes can be sent into the preview-first curation queue with one action.

What it reports

Organised by aspect and by concept, the same axes as the cluster, so a thin concept is visible even when its aspect looks covered.

Overall
A headline coverage figure, the answered expected questions against the open, and the required subsets present against missing.
By aspect
For each aspect: a status (strong, thin, gap), answered and open question counts, subset completeness, and the source count by trust tier.
By concept
The same read over the concept decomposition, so a thin concept shows even when its aspect looks covered.
Expected questions
The answered and the open. The open ones are the coverage gaps.
Gaps
Each coverage gap with a pre-staged candidate where one exists and a recommended source.
Decay & conflicts
The decaying premises past refresh and the sources that disagree.
Recommendations
Prioritised actions, source this, refresh that, reconcile the other, each routable to curation.
Provenance
The warrants and sources behind the figures, by id.

Coverage by aspect, illustrated

A worked extract, the kind of table the report leads with. The figures come from the cluster; nothing is invented.

AspectStatusAnswered / openSubsetsSources by tier
WhoStrong6 / 03 of 3T1×2 · T2×3
WhatStrong5 / 13 of 3T1×1 · T2×4
WhenThin2 / 31 of 3T3×2
WhereStrong4 / 02 of 2T1×1 · T2×2
WhyGap0 / 40 of 2none
HowThin3 / 22 of 3T2×1 · T3×1
Overall coverage 67% · 20 of 30 expected questions answered · 2 aspects need attention

How it is produced

The coverage report is produced by the same deliverable job as any other report, render_deliverable, run over the cluster. It reads the cluster's coverage data only; the figures come from the cluster, and there is no fabrication.

1

Populate

Gather the coverage data: the expected questions, the subsets and their answers, the coverage gaps, the sources and tiers, and the decay and conflict records.

2

Apply the rubric

Score the report for faithful representation of coverage, source grounding, and no overstatement, with the standard caps.

3

Generate the executive summary

The headline coverage and the top three actions, drawn from the report and the rubric results.

4

Seal the warrant

An optional final step seals an E10 Validity Warrant over the report, so the coverage figures are themselves provable.

summarize
The result presents the report, its executive summary with the completed rubric, and a guideline, each in a popup viewer, exportable in five formats with Markdown the default. As with every export, the document carries only the warrant id, never the warrant body.

Who uses it, and where it sits

One deliverable, three homes. In the catalogue it sits in the picker's Generally applicable group, tied to a coverage frame, so it is produced through the same picker, job, and result as every other deliverable.

account_tree

The steward

Runs it on a branch to see where to curate. Its recommendations feed straight into the preview-first curation queue. This is its primary home.

policy

The auditor

Runs it on a framework, where the coverage report is the crosswalk in report form, exception-first, and folds into an evidence package.

person

The application user

Runs it on a topic to judge how strongly the base covers something before relying on it.

link
Coverage reporting closes the loop the rest of the product opens: the Canvas makes coverage visible, the coverage report makes it a document, and its recommendations route into the same curation the agents and the steward already run. Gaps become work, not silent blind spots.

The document, section by section

  1. Summary, with the overall coverage, the headline gaps, and the top recommendations.
  2. Coverage by aspect, a table of aspect, status, answered and open, subsets, and sources by tier.
  3. Coverage by concept, the same read over the concept decomposition.
  4. Expected questions, answered against open.
  5. Gaps, each with a candidate source.
  6. Decay and conflicts, the premises past refresh and the sources that disagree.
  7. Recommendations, prioritised and routed to curation.
  8. Provenance, the warrants and sources behind the figures, by id.
verified_user
Because the report is itself warranted, a regulator or a reviewer can take the coverage claim at face value: the figures are sealed, replayable, and tied to the sources they came from.