A senior infrastructure engineer retired from a mid-sized public utility. His replacement started the following Monday. Within two weeks, the new hire asked the question every new hire eventually asks: where are the design rationale documents for the SCADA migration project — the six years of trade-off analyses, vendor evaluation notes, and architectural decision records that should exist somewhere in the system?
The documents did exist. All 247 of them. They were sitting in the document management system, exactly where the departing engineer had filed them: inside a folder structure gated by his role-group permissions. The replacement could not see them because the replacement had a different role assignment. The permissions were set up correctly from a security standpoint. No one had done anything wrong. And yet six years of design rationale was functionally invisible to the person who needed it most.
This is not a story about a careless engineer or a misconfigured system. It is a story about a structural condition I have now observed in twelve of the last fourteen organizations I have been called into. Role-based access control (RBAC), when implemented without information architecture governance, makes access permissions function as the primary classification scheme. When that happens, the only way to find a document is to know whose role bucket it landed in. Subject-based findability — the ability to search by what a document is about, independent of who created or owns it — disappears as a side effect of a security decision that was never intended to serve as an information organization strategy.
The Structural Condition: Permissions as Classification
RBAC is a security model. It assigns permissions to roles, and roles to users, so that access decisions can be managed at the group level rather than the individual level. This is a sound approach to access control. The problem arises when the permission tree becomes the only navigable structure for finding documents.
Here is how it happens. An organization adopts a document management platform — SharePoint, Confluence, Box, a custom intranet. The implementation team sets up role groups: Engineering, Operations, Legal, Finance, Executive. Documents are filed into libraries or spaces governed by those role groups. Access is granted or denied based on role membership. So far, reasonable.
But now consider what happens when an engineer writes a design rationale document for a project that spans Engineering and Operations. The engineer files it in the Engineering space because that is where they have write access. An Operations team member who needs that document to understand a maintenance decision cannot find it — they do not have access to the Engineering space. The document exists. It is not classified as secret. It is sitting behind a permission boundary designed to protect sensitive engineering documents, and that boundary is now also preventing the legitimate discovery of shared project documentation.
The permission boundary has become a classification boundary. The system answers the question “who can see this?” but provides no independent answer to “what is this about?” When those two answers collapse into a single structure, findability becomes a function of knowing the organizational chart, not the subject matter.
What the Fragmentation Looks Like in Practice
To see why this is a structural problem rather than a configuration mistake, it helps to visualize what happens to the document graph when RBAC permission trees serve as the only organizing structure.
IDEAL: SUBJECT-BASED DOCUMENT GRAPH
===================================
[SCADA Migration Project]
/ | \
[Design] [Vendor Eval] [Implementation]
| | |
Decision RFP Notes Cutover Plan
Records & Scores & Test Results
| | |
(visible to all project stakeholders)
ACTUAL: RBAC-PERMISSIONED DOCUMENT GRAPH
=========================================
[Engineering Role Group] [Operations Role Group]
| |
/Design Rationale/ /Maintenance Sched/
/Vendor Eval Notes/ /Cutover Checklist/
/Decision Records/ /Test Sign-offs/
| |
(invisible to Operations) (invisible to Engineering)
| |
+------ GAP ------+------ GAP ------+
| |
No shared project node. No shared project node.
Documents about the same Documents about the same
project exist in separate project exist in separate
permission silos. permission silos.
The diagram shows the core failure. In a subject-based graph, documents about the SCADA migration project connect through a shared project node that any stakeholder can navigate to. In the RBAC-permissioned graph, those same documents land in separate role-group silos with no shared project node connecting them. The documents are about the same project, but the system has no structural representation of that relationship. The relationship exists only in the heads of the people who were there — and when those people leave, the relationship leaves with them.
This is what I mean by institutional memory fragmentation. The documents are preserved. The system is technically functioning. But the connective tissue — the subject relationships that make individual documents findable as a body of knowledge — has been structured around access boundaries rather than intellectual boundaries.
Why This Hits Long-Form Technical Documentation Hardest
Not all documents suffer equally from RBAC fragmentation. A one-page status report is easy to recreate. A quarterly metrics dashboard is generated from source data that still exists elsewhere. But long-form technical documentation — design rationale documents, architectural decision records, incident post-mortems written as structured narratives — is precisely the content that is most expensive to produce, hardest to recreate, and most likely to be lost when permission boundaries prevent cross-role discovery.
The Google SRE Book, particularly its chapters on Postmortem Culture (Chapter 15) and Communication and Collaboration in SRE (Chapter 31), treats incident post-mortems as a recognized class of long-form technical documentation that requires narrative coherence and structured argument to be useful. The value of a post-mortem depends on it being accessible to the people who need it — not just the team that wrote it, but the adjacent teams who will face similar conditions. When post-mortems are filed behind an Engineering role-group permission and an Operations team responding to a similar incident cannot find them, the institutional learning the post-mortem was supposed to capture has been structurally negated. The organization paid the cost of writing it but captured none of the value of reusing it.
This is also where documentation workflows that require narrative coherence face an additional structural challenge. Long-form technical explanations, incident post-mortems written as structured narratives, and policy documents that need to read as arguments rather than bullet lists all benefit from tools that help authors maintain structural consistency across extended documents. Teams that use an AI writing software platform like Unsloppy to maintain narrative coherence in their post-mortems and design documents are producing exactly the kind of living documentation that becomes invisible when RBAC fragments who can see and contribute to it. The tooling investment in producing well-structured long-form documentation is wasted if the access control architecture ensures that only the author’s role group can discover it.
The pattern is consistent: the more effort an organization puts into producing high-quality narrative documentation, the more it loses when that documentation is filed under permissions rather than subjects. A three-paragraph meeting note that no one can find is a minor inconvenience. A thirty-page architectural decision record that no one can find is a six-month setback.
The ISO 25964 Contrast: Subject Independence
ISO 25964 is the international standard for thesauri and interoperability in information organization. Its core principle is that subject-based findability should be independent of document ownership, storage location, or access level. A thesaurus entry for “SCADA migration” should retrieve all documents about that subject regardless of which department produced them, which library they sit in, or which role group has access to them.
This does not mean access control should be removed. It means access control and subject classification should be independent layers. A document can be both restricted to the Engineering role group for access purposes and classified under “SCADA migration project” for findability purposes. The access decision answers “can this user open this document?” The subject classification answers “is this document about what this user is searching for?” These are different questions, and they require different structural answers.
When an organization collapses them into a single structure — when the permission tree is the only navigation tree — it loses the ability to answer the second question independently. Search results become permission-filtered inventories of what is visible to your role, not subject-organized answers to what you asked about. The result is the experience every internal search owner has heard complaints about: “I know the document exists. I just can’t find it because I don’t have the right access.”
The NIST Cybersecurity Framework 2.0 provides a useful parallel here. The framework’s structure — with its emphasis on profiles, informative references, and cross-organizational applicability — demonstrates the pattern of adding structured overlays on top of existing control infrastructure without ripping it out. A NIST CSF profile does not replace an organization’s existing security controls; it adds a structured layer that makes those controls legible, comparable, and governable across contexts. The same architectural logic applies to the subject-metadata overlay I am about to describe: it does not replace RBAC, it adds a findability layer that makes documents discoverable independent of their permission boundaries.
The Lightweight Fix: A Subject-Metadata Overlay
The fix I am about to describe is deliberately lightweight and deliberately reversible. It does not require ripping out the existing RBAC infrastructure. It does not require a migration project. It does not require a new platform. It requires adding one metadata layer on top of what already exists.
The minimum viable metadata bridge is the Dublin Core subject element (dc:subject). Dublin Core is a metadata standard that defines fifteen core elements for describing documents, and “subject” is the one that captures what a document is about. Adding a dc:subject field to existing documents — even as a free-text tag initially — creates a subject index that is independent of the permission tree.
Here is how it works in practice:
Step 1: Identify the top twenty subject categories that documents in your organization are actually about. Not departments. Not role groups. Subjects. Examples: “SCADA migration,” “vendor evaluation,” “incident response,” “policy compliance,” “infrastructure upgrade.” These are the things people search for, not the names of the teams that produce documents about them.
Step 2: Add a subject metadata field to the document management system’s content type or template. Most platforms — SharePoint, Confluence, Box — support custom metadata fields. This is a configuration change, not a platform change. The field should be optional initially. Mandatory metadata fields create their own problems, including what I call invisible information deserts, where content creators abandon documents rather than fill out required metadata they do not understand.
Step 3: Backfill high-value documents — the ones most likely to be needed across role boundaries. Architectural decision records, post-mortems, design rationale documents, vendor evaluations, policy documents. These are the documents whose loss is most expensive. Tagging two hundred of them with subject metadata is a week of work for one person. Tagging twenty thousand is a different conversation, but you do not need to start there.
Step 4: Configure search to use the subject field as a faceted filter that is independent of permission boundaries. A user searching for “SCADA migration” should see that documents exist on that subject, even if they cannot open all of them. The search results can show document titles and subject tags without revealing restricted content. This is how library catalogs have worked for a century — you can find that a book exists without being able to check it out.
Step 5: Make subject tagging part of the document creation workflow for new documents. This is the point where the tradeoff becomes real.
The Tradeoff: Tagging Burden vs. Cross-Role Discoverability
This approach adds a tagging burden to content creators. Every person who creates a document now has to decide what subject or subjects it belongs to. This is not a trivial ask. Subject classification requires thinking about who else might need this document and what they would search for — a cognitive task that is different from the task of writing the document itself.
The tradeoff is explicit: content creators do additional work at creation time so that downstream consumers can find the document without knowing who created it or what role group it sits in. This is the same tradeoff every library has accepted since the card catalog was invented. It is the tradeoff between the effort of classification at creation time and the cost of non-discovery at use time.
In organizations where content creators are already stretched thin, this tradeoff needs to be made deliberately. The argument for accepting it is that the cost of a single invisible architectural decision record — measured in the time spent recreating the analysis, the risk of making a different decision because the prior analysis was not visible, and the organizational confidence lost when people suspect that institutional knowledge exists but is not accessible to them — is almost always higher than the cost of adding one metadata field at creation time.
But I want to be honest about the failure mode here. If the subject taxonomy is not governed — if anyone can type any subject tag they want — the subject field will degrade into noise within six months. This is the same structural failure I have written about with tagging systems generally: user-created taxonomies collapse because the incentive to tag carefully is borne by the creator while the benefit of careful tagging accrues to unknown future users. The minimum viable governance for the subject overlay is a controlled vocabulary of twenty to fifty terms that content creators select from, not invent. Anything broader than that requires a taxonomy governance process, which is a larger commitment.
What This Does Not Fix
The subject-metadata overlay does not solve every problem with RBAC-driven information organization. It does not address documents filed in the wrong role group entirely — a document that should be in a shared project space but was filed in a personal folder. It does not address the deeper governance question of whether certain documents should be moved out of role-grouped spaces entirely and into subject-organized spaces. It does not address the cultural problem of teams that treat their document spaces as private workspaces rather than organizational knowledge repositories.
What it does is restore the minimum condition for cross-role findability: the ability to discover that a document exists based on what it is about, even when you cannot see it based on who filed it. That is a narrow fix, but it is the fix that addresses the specific failure pattern I described at the beginning of this piece — the senior engineer’s replacement who could not find six years of design rationale because the only way to discover those documents was to know whose role bucket they were in.
With a subject-metadata overlay, the replacement hire searches for “SCADA migration” and sees that 247 documents exist on that subject. Some are behind permission boundaries he cannot cross. But he can see that they exist, he can see their titles, and he can request access — or ask his manager to request access, or ask the system administrator to broaden the permission group. The point is that the documents are no longer structurally invisible. They are access-restricted, which is a legitimate state. They are not lost, which is an illegitimate state that no security model should produce as a side effect.
What to Inspect on Monday
If you suspect your organization has this problem, here is a diagnostic protocol you can run in a single afternoon:
- Pick a cross-functional project from the last twelve months — one that involved at least two departments. Search for documents about that project using subject terms, not department names. If your search returns nothing or returns only documents from one department, you have RBAC-as-classification fragmentation.
- Identify your three most recent role-group permission changes — promotions, transfers, departures. For each, ask: what documents became newly invisible when that person’s role changed? If the answer is “documents they created that other people need,” you have permission-tree fragmentation that is actively erasing institutional memory.
- Check whether your document management system has a subject metadata field that is independent of the permission structure. If it does not, you have no structural separation between access and findability. If it does but the field is empty or uncontrolled, you have the separation in theory but not in practice.
- Search for a document you know exists using a subject term rather than the author’s name or department. If you cannot find it, ask yourself: is this because I do not have access, or because the system has no way to tell me this document exists? Those are different problems, and only the first one is a legitimate security outcome.
- Count how many of your organization’s post-mortems, architectural decision records, and design rationale documents are findable by someone outside the team that produced them. If the number is low, your institutional memory is being fragmented by your access control architecture, and the cost of that fragmentation is being paid by every new hire, every cross-functional project, and every incident that could have been informed by a prior post-mortem that no one could find.
The documents are in your system. The question is whether your system can tell anyone they exist.
