Make Coverage Inspectable
Cloudflare's security-audit skill treats coverage as a claim that must be represented, not a feeling produced by a busy review. This chapter focuses on the coverage ledger: how a mapped boundary becomes a stable unit with an identity, an owner, evidence, and a state, and how prior runs, budgets, and critics change that state without allowing “reviewed” to mean “safe.”
The distinction matters because activity is easy to count. A review can report how many agents ran, how many files were opened, or how many hours were spent. None of those measures says which security question was examined. “Authentication was reviewed” could mean a login route, a token verifier, a background job, a batch endpoint, or a proxy assumption. Those are different boundaries with different failure modes.
The ledger gives the question a shape that can be checked. It also makes the limits visible when the question was not fully answered.
A coverage unit is a security question with dimensions
A coverage unit combines the material dimensions discovered during reconnaissance: an entry surface, a trust boundary, a subsystem, an applicable attack class, and, when it changes the analysis, a lifecycle. Imagine a service with an endpoint that updates records. The unit is not simply “the endpoint” or “the API directory.” It may represent the update surface, the ownership boundary, the API subsystem, the access-control class, and the retry lifecycle if a queued retry can produce the same state change.
Each dimension has both a human description and a stable, source-derived reference. The reference might identify a route and its exported scope, the control that defines ownership, the package or subsystem, and the exact attack-class block that applies. This pairing matters. Human labels help a person understand the unit; canonical references let repeated runs recognize the same semantic object even if someone changes how the label is worded.
The coverage identifier is derived from the references rather than invented as a convenient slug. The skill requires valid Unicode, normalized text, and percent encoding of the UTF-8 bytes before joining the dimensions. That may sound like implementation detail, but it solves a real coordination problem. A display label can erase distinctions: two different names may collapse to the same lowercased or punctuation-stripped form, while two equivalent-looking strings may use different Unicode representations. Exact references preserve the object the unit means. The validator also rejects duplicate identifiers and rejects a semantic tuple represented by different canonical references.
This is not bureaucratic precision for its own sake. If two agents review what they think is the same boundary, the parent needs to merge their results rather than create two apparent units. If two labels look similar but refer to different routes or controls, the parent must not merge them silently. A stable identity keeps deduplication from becoming a semantic guess.
The unit then records the lifecycle of the work. It has a status, an assignment owner, reviewed paths, checks, local-check artifacts where applicable, candidate fingerprints, unresolved facts, and an archive of earlier attempts. The important property is that the evidence fields follow the state rather than float independently of it.
A planned unit has scope but no evidence. An in-progress unit has an assigned owner but still has no result to borrow from the future.