Compliance is usually treated as a document problem. Write the policy, map the control, attach the evidence, produce the report.
That framing starts in the wrong place. Compliance is graph-shaped before it is workflow-shaped.
A policy points to obligations. Obligations point to controls. Controls point to implementation statements, system components, assessment procedures, evidence, exceptions, owners, findings, and remediation work. The document is one view over that structure. It is not the structure.
The useful unit is the edge.
The policy is not the proof
A policy can state that access is reviewed quarterly. It cannot answer, by itself, which review covered which system boundary, who performed it, which population was tested, which evidence was used, which exceptions were accepted, and which downstream claim depended on that acceptance.
Those are not formatting problems. They are traceability problems.
The hard compliance question is not "where is the policy?" It is "which claim depends on this evidence, and who relied on that claim?"
That question needs edges. A control claim depends on an assessment activity. The assessment activity used evidence. The evidence came from a scanner run, a ticket export, a configuration snapshot, a review record, or a signed exception. Each of those has a time, a scope, a producer, and a failure mode.
If the evidence expires, the graph should show what breaks. If a system boundary changes, the graph should show which controls were covered by the old boundary and which claims need reassessment. If an exception is accepted, the graph should preserve the path from obligation to risk decision, not bury the decision in a PDF appendix.
Structured controls already exist
This is not a futurist version of compliance. The public standards world has already moved part of the way there.
NIST OSCAL represents control catalogs in standardized, machine-readable formats. Its terminology separates control definition, implementation, and assessment concepts: define the control, describe how a system implements it, then assess the result.
That split matters. It stops "the control" from being one overloaded object. A catalog control is not the same thing as a local implementation statement. An implementation statement is not the same thing as an assessment plan. An assessment result is not the same thing as the evidence that supported it.
The NIST Cybersecurity Framework 2.0 has the same graph pressure. Its Core is a hierarchy of Functions, Categories, and Subcategories, and its Informative References point outcomes toward standards, frameworks, regulations, and policies. Those references are edges. Treating them as footnotes leaves the operational value on the floor.
NIST SP 800-53A Rev. 5 adds another edge type: assessment procedures. Evidence is not just attached to a control after the fact. It is gathered through a method. The procedure matters because it tells you what the evidence is evidence of.
Provenance is the missing layer
Evidence without provenance is decoration.
The W3C provenance model gives useful language here. PROV-O describes provenance around entities, activities, and agents. PROV-DM frames provenance as entities being used and generated by activities influenced by agents.
That maps cleanly onto compliance work. A vulnerability scan is an activity. Its output is an entity. The scanner, schedule, configuration, and operator are part of the provenance. A manual review is an activity. The reviewer, checklist, sampled population, and resulting finding belong in the trace.
The point is not to make every compliance team adopt RDF, OWL, or a graph database on day one. A typed relational model with stable identifiers and explicit join tables can still follow graph discipline. The discipline is to model the relationships as first-class facts rather than let them hide in filenames, spreadsheet columns, and auditor narratives.
That is also where the RDF versus property graph question becomes practical. I argued earlier that RDF earns its keep when shared meaning crosses boundaries, while property graphs earn their keep when traversal is the product. Compliance needs both instincts. The control vocabulary needs shared meaning. The daily work needs traversal: show me every claim that depends on this stale evidence.
The report still matters
Auditors still need human-readable narratives. Executives still need a report. A regulator will not accept a graph query as the whole answer.
But the report should be a view over the trace, not the only source of truth.
This is where structure can create its own false confidence. A weak control in OSCAL is still weak. A stale screenshot with a stable identifier is still stale. A graph that records evidence without freshness, scope, and provenance can make bad assurance easier to repeat.
The answer is not to abandon judgment. It is to make judgment inspectable.
The graph does not decide whether an exception was acceptable. It records which obligation the exception touched, which evidence was reviewed, who accepted the risk, when the acceptance expires, and which claims now depend on that decision. That record is what governance roles need before they can mean anything.
A later post can make the policy-control-evidence pattern concrete. The prior claim is simpler: compliance fails when the edge is implicit.
The PDF is the artifact people ask for. The graph is the artifact they rely on.