Open Data Infrastructure
Context Graph Policy Edge Modeling
How context graphs can model policy edges among people, tools, datasets, purposes, and decisions.
A context graph that cannot explain blocked paths is only half a graph.
Allowed paths and blocked paths both matter
Context graphs are usually described as a way to connect entities, documents, datasets, metrics, tools, and people. That is useful. It is not enough for governed AI.
The graph also needs policy edges. Which person can use which tool for which purpose? Which dataset can support which decision? Which policy denied the path? Which owner can approve an exception? Without those edges, the graph can explain relevance but not authority.
Core idea: Context graph policy edge modeling gives AI systems a way to explain allowed and blocked paths through people, tools, data, purposes, and decisions.
Policy and provenance need graph-shaped evidence
The Open Policy Agent documentation describes a policy engine for offloading policy decision-making from software. W3C PROV gives a model for provenance across entities, activities, and people.
Those ideas belong together in AI context. The policy decision should not sit outside the graph. It should become an edge with subject, object, purpose, policy version, decision, time, and evidence.
Model policy as navigable edges
- Represent people, service accounts, tools, datasets, documents, purposes, actions, and decisions as graph nodes.
- Use edges for allowed, denied, requires-review, derived-from, owns, approves, and expires-at relationships.
- Attach policy version, reason, time, and evidence packet to each decision edge.
- Keep blocked paths queryable so agents can explain refusal.
- Review high-risk paths where one tool can cross multiple policy domains.
This builds on knowledge graphs and ODI, context graph evidence chains, and AI governance operating models. Authority is context too.
What breaks first
- The graph retrieves the right evidence but omits the policy that forbids use.
- Denied decisions disappear from the graph, so agents cannot explain refusal.
- Ownership edges exist, but approval edges are stored in a separate ticketing system.
- Purpose is modeled as text instead of an enforceable relationship.
Questions to ask while modeling
- Which policy decisions should become edges in the graph?
- Can the graph explain why a path was allowed or denied?
- How does purpose constrain dataset and tool use?
- Which edges expire, and how does the agent learn that?
Sources to start with
These primary sources anchor the technical claims in this guide.
A governed context graph has to know where the answer is not allowed to go.