How do you record a key-rotation check that fully satisfies one framework's clause but only partly another?

## The edge is a claim, and claims have strength The naive crosswalk records existence: check X relates to clause Y. That is enough to route a finding into a report and nothing else. The moment someone reads the report as coverage — and someone always does — the missing attribute becomes the whole problem, because *related to* silently renders as *satisfies*. So the edge carries a strength, drawn from a **closed vocabulary** rather than free-text notes. The exact tokens matter less than the discipline; three levels is usually enough: - **Full** — the check's passing result is the answer to the clause for the components in scope. - **Partial** — the check answers a defined portion; something else must be true for the clause to hold. - **Supporting** — the check is corroborating evidence, not the answer. Free text loses this. "Mostly covers, see notes" cannot be aggregated, filtered or diffed, and it is invisible to whoever renders the dashboard. ## Three different reasons an edge is partial The rotation example produces all three, which is why it is worth working through. **1. Partial by dependence on a document.** A clause that requires keys be changed at the end of a cryptoperiod *you* define does not name a number. Your check tests 365 days. The check plus the standard that says 365 answers the clause; the check alone does not. If someone edits the standard to 24 months and nobody edits the rule, the edge silently becomes false while both artifacts still look healthy. The remainder here is a document, and it belongs in the edge as a link, not in someone's memory. **2. Partial by breadth.** A clause covering cryptographic key establishment and management spans generation, distribution, storage, escrow, rotation and destruction. A rotation check answers one of those. Marking that edge full is a claim you cannot defend in a walkthrough, and the auditor's next question — show me destruction — arrives with no warning. **3. Partial by conditional applicability.** Some clauses bite only for a subset of systems. The edge is full *within* that subset and silent outside it. That condition belongs on the edge as a qualifier; without it the same green tick means two different things in two reports. ## Aggregation is where honesty dies An edge with strength is only useful if the strength survives the pipeline that turns edges into a percentage. The classic mistake is counting mapped clauses: every clause with any edge counts as covered, so a crosswalk full of partials renders as 100%. Two rules prevent it: - Coverage counts **only fully satisfied clauses** in the numerator; partial is reported as its own category with the remainders listed. - **No edge may be silent about strength.** An absent value must not default to full. Make the field required, and make CI reject an edge without it. The consequence is a less flattering dashboard, and that is the point. A control owner who knows their nineteen partial edges and who owns each remainder is in a far stronger position than one holding a green tick they cannot explain. ## Who decides, and what it costs to be wrong The control owner decides the strength with the clause text in front of them, and the decision is reviewed like any other claim in the repository. Being wrong in the optimistic direction is expensive: an auditor tests the strongest claim you made, and a full edge that turns out to be partial does not merely fail that clause — it makes every other edge in the file suspect, because you have demonstrated the mapping is not trustworthy. Being wrong pessimistically costs an argument and some remediation work that was probably worth doing. That asymmetry is the whole reason to write partial down. A crosswalk is a set of claims about which you will be examined; the ones you hedged honestly cost you nothing, and the ones you rounded up cost you the file's credibility.