# Graphs Of Graphs: Mapping Reality, Not Complexity **version** v0.33.40 **date** 18 June 2026 **from** Human (project lead) **to** Strategy, Architect, Security, Publication, @Dev **type** Strategy brief (thesis, in the series) --- ## What This Is The expansion of graphs of graphs and ontologies of ontologies as the thing that underpins the permission and evidence model: **mapping what an agent can do means mapping reality, and reality requires navigating graphs of graphs and ontologies of ontologies, because each company and each division has its own ontologies, taxonomies, and graphs once you apply business context (nationality rules, data isolation, joiners-movers-leavers, sensitive and confidential data), and you must map not just what an app can do but the information it holds, which carries its own controls and weights, all of it evolving over time because time is an event; this is not complexity, it is reality, the reality of business and of complex applications, which people ignored because it is genuinely hard, hard enough to need an engine as powerful as static code analysis, but agents will find it, so we must protect, isolate, and contain the blast radius.** It expands the evidence and graph work for the permission model (cross-ref: the v0.33.38 confidence-through-evidence thesis, the v0.33.40 agent-blast-radius-service and skills-as-code briefs, and the v0.32.3 nhi-2.0-semantic-knowledge-graphs brief). New contributions: **the per-company ontologies point, the SharePoint permission example, the static-analysis-grade insight, and the reality-not-complexity framing.** ## The Series Framing What this expands: **the graphs of graphs, in the permission context.** The project lead: **"I want to expand on the graphs of graphs in the permission context. It is almost the collection of evidence required to provide the permissions for a particular action."** So permissions are not a flat list; they are an evidence graph, and granting a permission means navigating it. ## Graphs Of Graphs, Ontologies Of Ontologies The underpinning: **navigate all sorts of graphs, connect the dots, build the ecosystem of what we understand now.** The project lead: **"this is where the ontologies of ontologies of ontologies, the taxonomies of taxonomies, the graphs of graphs of graphs, are important, because for this to work we need to navigate all sorts of graphs, connect the dots, and create this ecosystem of what we understand at this moment in time, what we can follow down the rabbit holes, or where we need more permissions from the user to make a better decision, and when facts change, because over time you have a better understanding."** So the model is dynamic and layered: graphs composed of graphs, navigated to assemble current understanding, extended when you follow a thread or get more permission, and revised when facts change (cross-ref: the confidence-through-evidence thesis). ## Each Company Has Its Own Ontologies Why there is no single graph: **business context makes every company and division different.** The project lead: **"each company will need its own ontologies, its own taxonomies, its own graphs, because then you apply business context. And companies are made of multiple companies, multiple divisions, each with a different focus, different evolutionary scales, different Wardley maps, different maturities. We need to take that into account."** So the graph is not universal; it is per-company and per-division, and those parts sit at different evolutionary stages, which the model must represent rather than flatten (cross-ref: the Wardley explorer-to-town-planner concept). ## The Under-Appreciated Complexity Of Permissions A concrete example, from experience: **understanding file permissions needs an engine as powerful as code analysis.** The project lead: **"take file sharing, a SharePoint or document management system. Once you apply the business logic, nationality rules, data that needs to be isolated, who has access to what, joiners-movers-leavers, what data should be seen, HR data, sensitive, private, business-confidential data, and you map all that, I remember doing static analysis to analyse software code, and I realised I needed an engine as powerful as the ones we had for code to have a chance of understanding the privileges of the file mappings. That is the challenge: we need to connect, map, and graph this business-logic application layer so you can make decisions."** So the privileges hidden in something as ordinary as a document store are as complex as a codebase, and understanding them needs comparably powerful analysis (cross-ref: the artefact-driven-security-assessments brief). ## What An App Can Do, And What It Knows A distinction worth drawing: **map not only the actions but the information.** The project lead: **"it is when you look at what an app can do in terms of assets, and not just what it can do, but what information it has, because information also has its own controls, permissions, requirements, and weights. Only when you map all of that do you understand what actions should be done."** So the blast radius is not only the actions an app can take; it is also the information it holds, which carries its own controls and weights, and both must be in the graph. ## This Is Reality, Not Complexity The headline framing: **what is being described is the reality of business, not gratuitous complexity.** The project lead: **"a lot of companies ignored this complexity, especially because you also need to take time into account. Time is an event, things change. But what I am describing is not complexity, it is reality. This is the reality of business, the reality of the complex applications we have."** So the response to anyone who calls this too complex is that the complexity is real: it is how businesses and their systems actually are, and time makes it move. Ignoring it does not make it go away. ## The Agents Will Find It Why it can no longer be ignored: **agents will discover and exploit this reality.** The project lead: **"the problem is the agents will find it. They will proactively be creative and discover how to access this data and do all this stuff. So we now need to protect, isolate, and contain the blast radius."** So the reality that companies got away with ignoring will be found by agents that traverse it efficiently, which is why mapping it, and then containing the blast radius, is now necessary (cross-ref: the why-now-inefficiency-of-exploitation and infrastructure-not-built-for-agents briefs). ## What This Points To 1. **Model permissions as an evidence graph** (graphs of graphs, not a flat list). 2. **Build per-company, per-division ontologies** (business context, evolutionary stages). 3. **Analyse the business-logic layer at code-analysis grade** (the privileges are that complex). 4. **Map information, not just actions** (information has its own controls and weights). 5. **Make time a first-class dimension** (the graph moves; facts change). 6. **Then protect, isolate, and contain** (the blast radius, once mapped). Estimated effort: this is the conceptual underpinning; the build is the graph navigation, the per-company ontologies, and the analysis engine, on the existing graph and evidence work. ## What This Does Not Try To Be - **Not a single universal graph.** Each company and division has its own. - **Not a flat permission list.** It is graphs of graphs. - **Not actions only.** Information and its controls are in scope. - **Not static.** Time is an event; the graph changes. ## Honest Tensions **Tension 1: mapping reality is genuinely hard.** It needs analysis as powerful as static code analysis. Mitigation: LLMs now make building the parsers and connectors affordable (cross-ref: the agent-blast-radius-service brief). **Tension 2: per-company ontologies do not standardise.** Every company differs. Mitigation: the ontology-of-ontologies approach is built to hold many local ontologies, not force one. **Tension 3: the graph is never finished.** Time and change keep moving it. Mitigation: treat time as an event and update continuously; map the gaps. **Tension 4: connect for understanding versus isolate for containment.** The same model that connects to understand must also isolate to contain. Mitigation: connect the evidence needed to decide, isolate the assets needed to contain (cross-ref: the confidence-through-evidence thesis). ## Open Questions | Question | Notes | |----------|-------| | How are per-company ontologies built and maintained? | Business context, evolutionary stages | | What engine analyses the business-logic layer? | Code-analysis grade | | How is information weighted alongside actions? | Its own controls and weights | | How is time represented in the graph? | Time as an event | | Where do we connect, and where isolate? | Understanding versus containment | ## Relationship To Previous Briefs | Date | Document | Relationship | |---|---|---| | 16 Jun | `v0.33.38__strategy-brief__confidence-through-evidence-blast-radius-graphs-mapping-the-gaps.md` | Evidence, graphs, and mapping reality | | 18 Jun | `v0.33.40__strategy-brief__sg-send-agent-blast-radius-service-value-proposition-read-only-evidence-commercial-model.md` | The gigantic enterprise semantic graph | | 18 Jun | `v0.33.40__arch-brief__skills-as-code-permission-granularity-oauth-not-enough-units-of-execution.md` | The permissions this graph models | | 4 Jun | `v0.32.3__arch-brief__sg-send-nhi-2.0-semantic-knowledge-graphs-of-identity.md` | Semantic graphs of identity | --- ## Key Claims | # | Claim | |---|-------| | 1 | Permissions are an evidence graph, navigated to grant an action | | 2 | Graphs of graphs and ontologies of ontologies underpin the model | | 3 | Each company and division has its own ontologies and graphs | | 4 | Understanding file permissions needs code-analysis-grade engines | | 5 | Map information and its controls, not only actions | | 6 | Time is an event; the graph is never static | | 7 | This is not complexity, it is the reality of business | | 8 | Agents will find this reality, so we must contain the blast radius | --- This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).