The Structural Layer of Your Knowledge Base
File names, as addressed in Section 2, establish the identity of individual documents. Folder structure establishes something different and equally important: it establishes the relationships between documents. Where a file name tells an AI tool what a document is, the folder structure tells it what that document belongs to, what surrounds it, and what other documents are likely to be relevant in the same context. These are different kinds of information, and both are necessary for AI-assisted work to function reliably.
When an AI tool searches a file system or processes a collection of documents, it reads the full path of every file it encounters. That path is the sequence of folders and subfolders that leads to the document: for example, Clients / Johnson Corporation / Strategy Review 2024 / Deliverables / Johnson_StrategyReview_ExecutiveSummary_2024-03-15.docx. Every element of that path is a piece of contextual information. The AI tool knows, before opening the file, that this document is client work, that the client is Johnson Corporation, that the engagement is a strategy review, that this document is a deliverable rather than a research note or an internal draft, and that it was produced in March 2024. None of that information came from the document's content. All of it came from the structure in which the document sits.
A well-designed folder structure is therefore not an administrative convenience. It is a contextual scaffolding that makes every document within it more interpretable, more discoverable, and more useful to the AI tools that will be asked to work with it.
The Depth Principle: Why Shallow Structures Outperform Deep Ones
The most consequential decision in folder design is how many levels of hierarchy to create. Professional file systems frequently grow deeper over time as new categories are added, exceptions are accommodated, and subfolders are created to manage accumulation. The result is often a structure that is six, seven, or eight levels deep, where reaching any individual document requires navigating through a sequence of folders that few people can hold in their working memory and that AI tools struggle to traverse with consistent accuracy.
The principle that guides good folder design is that depth should be minimised. Three levels of hierarchy is a reliable upper bound for most professional contexts. Four levels is occasionally justified. Beyond four levels, the marginal organisational benefit of additional depth is almost always outweighed by the navigational cost it imposes.
The reason depth creates problems for AI tools is rooted in how path-based context is read. A very deep folder path contains a great deal of structural information, but much of that information is redundant, granular to a degree that provides no additional interpretive value, or actively confusing because it introduces distinctions that are not meaningful at the level of the work being done. A folder structure that distinguishes between fifteen subcategories of correspondence within a single case file may reflect a genuine organisational logic known to the paralegal who created it, but it presents an AI tool with a classification system it cannot interpret without extensive explanation.
Shallow structures, by contrast, tend to contain distinctions that are genuinely meaningful and that carry interpretive value at each level. When every level of hierarchy communicates something important about a document's context, the AI tool can use the full path productively. When levels exist primarily to manage accumulation or to mirror a bureaucratic category system, they add noise without adding signal.
The discipline of maintaining a shallow structure also has a secondary benefit: it forces a more considered approach to organisation. When you cannot create a new level of hierarchy to manage every new category of document, you are required to make decisions about what distinctions actually matter. Those decisions, when made thoughtfully, produce a file system that is cleaner, more consistent, and more useful to every person and every tool that needs to work with it.
The Organising Principle: What Belongs at the Top Level
The most important structural decision in folder design is what principle governs the top level of the hierarchy. The top level determines how everything beneath it is organised, and changing it later is a significant undertaking. The decision should therefore be made deliberately and with a clear understanding of how the work it will contain is actually structured.
The guiding principle is straightforward: organise by the thing that changes least frequently in your work. The top level should represent the most stable, most durable category in your professional context. Everything beneath it can be more variable, because the top-level structure provides the anchor from which the rest of the system navigates.
For professionals whose work is organised around long-term client relationships, the client is the most stable unit of organisation. Clients persist across multiple engagements, multiple project types, and multiple years. Organising at the top level by client means that all documents relating to a client, regardless of when they were produced or what specific engagement they belong to, are held within a single top-level folder. This makes client context coherent and makes it possible for AI tools to retrieve a complete picture of a client relationship when that is what the task requires.
For professionals whose work is organised around discrete projects that may involve multiple clients or stakeholders, the project is a more appropriate top-level principle. This applies in contexts such as management consulting, where a single engagement has a defined start and end, involves a specific client and a specific scope, and produces a coherent set of deliverables that belong together. Project-level organisation groups all documents from an engagement in one place, making it easier to close out a project cleanly when it concludes and to retrieve its full documentation if it is needed for reference later.
For professionals whose work is function-based and repeatable, where the same types of tasks are performed continuously rather than in discrete project cycles, function is the appropriate organising principle at the top level. An operations manager responsible for warehousing, shipping, receiving, and vendor management performs work in each of these areas continuously, not in discrete project phases. Organising by function at the top level reflects how the work is actually structured and makes documents in each area consistently findable.
Folder Structures for Five Professional Roles
The following structures apply the principles above to the five professional roles addressed in the walkthroughs in Module 4.4. Each structure is presented with the reasoning behind its design choices, not only the template itself, because the reasoning is what allows you to adapt the structure when your own context differs from the examples.
Management Consultant: Clients / ClientName / ProjectName / Deliverables, Research, Admin
The top level is the client because client relationships are the most durable unit in consulting work. Beneath the client is the project, because a single client may have multiple concurrent or sequential engagements. Beneath the project are three document type categories: Deliverables, for client-facing outputs; Research, for source material, benchmarks, and supporting analysis; and Admin, for contracts, scope documents, invoicing records, and internal correspondence about the engagement. This three-level structure keeps the active deliverable documents cleanly separated from supporting material and administrative records, which matters both for human navigation and for AI context: when drafting a client deliverable, you do not want the AI tool drawing on administrative emails as though they were strategic inputs.
Paralegal: Cases / Year / CaseNumber-ClientName / Pleadings, Discovery, Correspondence, Research
The top level is Cases rather than an attorney name or a client name. Organising by attorney creates structural problems when matters are reassigned, when attorneys leave the firm, or when a paralegal supports multiple attorneys simultaneously. Organising by client creates ambiguity when a client has multiple matters open at the same time. The case is the most stable and unambiguous unit of organisation in litigation work. The second level is the year the case was opened, which provides a temporal anchor and prevents active cases from being mixed with closed matters. The third level combines the case number and client name, providing both a unique identifier and a human-readable label. Beneath this level, document type categories reflect the natural phases and components of litigation: Pleadings for court filings, Discovery for the document production and review process, Correspondence for communications with opposing counsel and the court, and Research for legal research outputs. The AI tool working within this structure can, for example, search within the Discovery folder of a specific case for documents relevant to a particular issue, without surfacing pleadings or research from unrelated matters.
Claims Analyst: Claims / Year / ClaimID / InitialDocs, AdjusterNotes, CoverageMemos, Resolution
The top level is Claims because all of an analyst's work relates to the claims function. The second level is the year, which separates current claims from closed files and aligns with how most insurance organisations report and audit claims activity. The third level is the claim identifier, which is the primary operational reference in insurance work, as discussed in Section 2. Beneath the claim identifier, document categories reflect the lifecycle of a claim: InitialDocs for the first notification of loss, policy documents, and claim submission; AdjusterNotes for field investigation reports and adjuster communications; CoverageMemos for coverage analysis and position documents; and Resolution for settlement documents, payment records, and closure communications. An AI tool working within this structure can retrieve all documents relating to a specific phase of a specific claim with precision, and can distinguish between, for example, the initial coverage analysis in CoverageMemos and the final settlement terms in Resolution.
Financial Analyst: FinancialReporting / Year / Period / Actuals, Budget, Variance, Narratives, Presentations
The top level is FinancialReporting, which establishes the function. The second level is the year, reflecting the financial reporting cycle. The third level is the period within that year: a quarter, a month, or a specific reporting date depending on the organisation's reporting cadence. Beneath the period, document categories correspond to the components of financial reporting work: Actuals for source data exports and data files, Budget for the approved budget and any revisions, Variance for variance analysis workbooks and supporting calculations, Narratives for the written explanations of financial results, and Presentations for the executive and board-facing output. This separation is important for AI-assisted work because the nature of each category is different. Actuals are data files that should be read but not interpreted. Narratives are documents whose language style and framing the AI should understand before drafting new narrative content. Presentations are structured outputs that inform the format and level of detail appropriate for new presentations.
Operations Manager: Operations / Function / Processes, Training, Metrics, Projects
The top level is Operations. The second level is Function, populated by the specific operational functions the manager oversees: for example, Receiving, Warehousing, Shipping, Inventory, and Vendors in a logistics context. The third level, beneath each function, contains four document type categories: Processes for Standard Operating Procedures and process maps, Training for materials used to onboard and develop team members, Metrics for KPI definitions, tracking documents, and performance reports, and Projects for improvement initiatives or change management work within that function. This structure reflects the two primary types of work an operations manager performs: maintaining and improving operational processes (Processes and Training) and tracking and reporting operational performance (Metrics and Projects).
The Archive Strategy
Every well-designed folder structure requires a mechanism for managing documents that are no longer actively used but should not be deleted. Without such a mechanism, folder structures accumulate historical material alongside current work, which creates two problems. For the human professional, it becomes increasingly difficult to find current documents within folders that contain completed, superseded, and active files indiscriminately. For AI tools, the problem is more specific: when a tool searches for relevant information, it has no way of distinguishing between a current context document and an outdated one unless the folder structure makes that distinction explicit.
The Archive subfolder is the standard solution to this problem. Every primary folder in the structure contains an Archive subfolder. When a project closes, a case settles, a claim reaches resolution, or a process is superseded by a revised version, the documents relating to that completed work are moved into the Archive subfolder rather than deleted. This preserves the documents for future reference while removing them from the active working set that AI tools will search by default.
The discipline of archiving also creates a useful forcing function for knowledge base maintenance. Moving documents to Archive requires a moment of deliberate review: is this work actually complete? Is this version actually superseded? That moment of review reinforces the habit of keeping the active folder set current and meaningful.
An important practical note: archiving should be distinguished from deleting. Professional documents may have legal, contractual, regulatory, or institutional retention obligations that require them to be preserved for a defined period. Archiving within the folder structure satisfies this obligation while removing the documents from the active workspace. The decision about when archived documents may be permanently deleted should be made in accordance with your organisation's document retention policy and any applicable regulatory requirements.
Cloud Storage and AI Accessibility
The folder structures described in this section are most valuable when implemented in cloud storage platforms, and the reason is directly related to how AI tools access information. AI tools that integrate with your file system, whether through a platform like Cyrenza, through a connected general-purpose AI tool, or through the native AI features of platforms like Google Workspace or Microsoft 365, can only read and search files that are stored in accessible locations. Files stored exclusively on a local hard drive, a local network drive that has not been configured for cloud synchronisation, or a physical storage device are, from the perspective of any cloud-based AI tool, invisible.
The major cloud storage platforms, including Google Drive, Microsoft OneDrive, and Dropbox, all support AI integration to varying degrees. When documents are stored in these environments and appropriate access has been granted, AI tools can search by content and by file name, retrieve documents relevant to a query, summarise content across multiple files, and identify relationships between documents in a folder. The same documents stored locally cannot be accessed in any of these ways without manual upload.
This has a practical implication for how you approach the implementation of the folder structures in this section. If your current working files are stored locally, the process of implementing a well-organised folder structure is also an appropriate moment to migrate active files to a cloud storage environment. This migration, done alongside the implementation of consistent naming conventions, produces a working file system that is fully accessible to the AI tools you will connect in Module 4.3.
There is an important qualification to this guidance. Not all files should be migrated to cloud storage indiscriminately. Documents containing highly sensitive information, including the categories discussed in Section 6 of this module, require careful consideration of the cloud platform's data handling terms before being stored there. The migration of sensitive files to cloud storage should be preceded by a review of what is being moved and confirmation that the storage environment meets the appropriate security and compliance requirements for that category of information.