A production access policy says access must be reviewed quarterly. At the end of Q2, an identity-provider export shows one unapproved privileged account. Which assurance claim just failed?
A folder of policy PDFs, control spreadsheets, and evidence attachments cannot answer that reliably. The answer lives in the path between them.
One review, eight objects
Start with a policy clause called POL-AC-04-v3. It states the obligation: production access is reviewed quarterly. CTRL-QAR-01 translates that obligation into a control for the production identity-provider boundary. IMPL-QAR-01 records the local implementation: the owner, in-scope groups, workflow, cadence, and exception path.
The assessment begins at TEST-QAR-01-v2. This procedure compares the quarter-end account population with approved role assignments. Every discrepancy must be resolved or covered by an accepted exception.
For Q2, ACT-2026Q2-QAR executes that test using two artifacts: EXPORT-IDP-2026Q2 and ROSTER-APPROVED-2026Q2. The comparison produces OBS-2026Q2-17, an observation that one privileged account lacks approval. FIND-2026Q2-03 connects that observation to the control objective. The resulting CLAIM-2026Q2-QAR is a conclusion over this scope, this test version, this evidence set, and these findings.
That claim is not a timeless control effective = true field.
This separation follows the shape of NIST OSCAL. Its models distinguish control definitions, local implementations, and assessment results. The Assessment Results model separates performed activities, observations, relevant evidence, and findings. Each object has its own lifecycle because each can change without the others changing.
Evidence needs a procedure
The identity-provider export is not self-describing proof. It becomes evidence through the assessment activity that records which system boundary was queried, when the export was captured, which population it represents, who or what produced it, and how the test used it.
That provenance is part of the assurance claim. PROV-O provides useful primitives: entities, activities, and agents connected through use, generation, association, attribution, and derivation. Here, the export and roster are entities. The export job and quarterly review are activities. The software service and reviewer are agents.
Without those edges, an auditor can locate a file but cannot establish what it proves. This is the operational version of the argument in Compliance as a graph problem: the useful unit is the edge.
Stable identifiers make the edges durable. Renaming TEST-QAR-01-v2 for elegance must not detach historical findings from the procedure that produced them. As I argued in Schema evolution in production ontologies, identifiers become promises once another system stores or reasons over them. Labels can improve. Identity has to survive.
Make failure travel
The graph earns its keep when invalidation propagates through it.
Suppose EXPORT-IDP-2026Q2 passes its retention date, POL-AC-04-v3 is superseded, or the production boundary expands to include another privileged group. The system should answer three questions:
- Which claims depend on this expired export?
- Which tests still implement the superseded policy clause?
- Which findings were assessed against the old system boundary?
Those answers should become deterministic reassessment queues. A graph diagram that cannot produce them is documentation, not control infrastructure.
The same rule belongs in a gate. Before an assessment bundle is released, validate that every active assurance claim has one applicable policy version, a linked implementation and assessment activity, resolvable evidence with capture time and provenance, and a finding or explicit no-finding result. No expired exception should remain on the path.
SHACL is one way to express those constraints and produce a stored validation report. Typed relational tables with integrity checks can do the same job. So can a disciplined spreadsheet with stable IDs, explicit link columns, versions, and automated checks. The database category is not the commitment. Queryable relationships and executable validation are.
What the graph cannot prove
A complete trace can still formalize weak assurance. It cannot prove that the export contained the full population, that the test was well designed, or that the reviewer made a sound judgment. It makes those choices visible enough to challenge.
The graph also concentrates sensitive evidence and dependency metadata. Access control, retention, redaction, and deletion rules have to be designed with the trace, not added after it.
Auditors and decision-makers still need a bounded narrative of scope, judgment, findings, and exceptions. That report should be rendered from the versioned graph. Fluent control prose, including prose drafted by AI, does not substitute for this chain. The document explains the conclusion. The graph keeps the conclusion answerable to change.