The Distinction Between Navigation and Comprehension
The file naming conventions introduced in Section 2 and the folder structures addressed in Section 3 solve a specific class of problem: they ensure that documents can be found. A professional with a well-named, well-organised file system has addressed the navigational layer of AI-assisted work. When asked to locate a document, retrieve files relating to a specific client or matter, or search for all deliverables produced during a particular period, an AI tool working within that system can do so reliably.
Navigation, however, is only the first requirement. Once a document has been located, the AI tool must be able to understand it. Understanding in this context means something more than reading the words on the page. It means having access to the background against which those words were written: who the parties are, what the relationship history is, what terminology means in this specific organisational context, what decisions have already been made and why, what constraints govern the work, and what the professional using the AI tool is actually trying to achieve. Without this background, an AI tool reading a client strategy document understands the words but not the situation. Its responses will be technically coherent but contextually disconnected.
This is the problem that context documents solve. A context document is a written record of the background knowledge that an AI tool needs in order to produce responses that are genuinely relevant to a specific professional situation. It is the bridge between the general capability of the AI tool and the specific demands of your work. File names and folder structures make documents findable. Context documents make the work intelligible.
The Nature of Professional Context and Why It Is Rarely Written Down
To understand why context documents require deliberate effort to create, it is useful to examine what professional context actually consists of and how it is normally held.
Much of the most valuable knowledge a professional possesses is tacit rather than explicit. Tacit knowledge is knowledge that is carried in experience, judgment, and memory rather than in written records. A management consultant who has worked with a client for three years knows things about that client that do not appear in any document: the CEO's decision-making style, the political dynamics between the strategy team and the operations team, the failed initiative from two years ago that makes certain recommendations unwelcome, the relationship history that informs how formal or informal written communications should be. A paralegal who has worked with a particular attorney for two years knows how that attorney thinks about case strategy, what level of detail they want in research memos, which procedural approaches they prefer, and which aspects of a case they consider most significant. A claims analyst with experience in commercial property claims knows patterns in adjuster behaviour, red flags that commonly indicate coverage complications, and the internal standards that have developed over time within their team.
None of this knowledge exists in any file. All of it is essential for producing AI outputs that reflect professional reality rather than generic best practice.
The reason tacit knowledge rarely gets written down is structural rather than lazy. In normal professional practice, the person who holds the knowledge is also the person who applies it. A consultant who knows their client intimately uses that knowledge every time they work on the engagement, without needing to articulate it explicitly. The knowledge is always present because the person carrying it is always present. The introduction of AI tools creates a new situation: a capable tool that can assist with professional work but that carries none of this knowledge and has no means of acquiring it except through written documentation. Context documents are the mechanism through which tacit professional knowledge is made available to AI tools in a form they can use.
The README Approach
The README document takes its name from the software development world, where a README file placed at the top level of a project folder has been standard practice for decades. Its purpose is simple: to orient anyone who encounters the folder for the first time. In software, that reader is typically a developer who wants to understand what the project is and how to work with it. In professional services work, the reader is an AI tool that needs the same orientation before it can assist effectively with any task related to that folder's contents.
A README document for a professional folder should be short, structured, and current. Its purpose is not to be comprehensive. It is to provide enough background that any AI tool, or any human colleague, can understand the context of the folder's contents within a few minutes of reading. The structure of a useful README covers four elements.
What is here? A brief description of the folder's contents: what types of documents it contains, what work it relates to, and what phase or status that work is currently in. This orients the reader before they open any individual document.
Who is involved? The key people relevant to the work: the client or counterparty, the primary contacts on both sides, the internal team members involved, and their roles. AI tools that know who the relevant parties are can use that information when drafting communications, analysing documents, or identifying relevant references within the file system.
What the work is about. A brief description of the engagement, matter, or function: the core objective, the key constraints, and any significant background that shapes how the work should be understood. This is not a full project brief. It is a condensed orientation that allows the AI tool to interpret the documents it finds in appropriate context.
Current status. A note on where the work currently stands: what has been completed, what is active, and what is pending. This is particularly important for AI tools because it prevents them from drawing on completed or superseded elements of the work as though they were current. A README that records that Phase 1 of the engagement was completed in January and that current work relates to Phase 2 gives the AI tool a temporal orientation that the documents themselves may not provide.
The README should be stored at the top level of the folder it describes, not in a subfolder. It should be updated at natural milestones in the work: when a phase is completed, when key personnel change, when the scope or direction of the engagement changes significantly. A README that is six months out of date is less useful than one that has never been written, because it risks orienting the AI tool around a description of the work that no longer reflects reality.
Four Types of Context Documents
Beyond the README, which provides a general orientation to a folder, there are four specific types of context documents that address the most common gaps between what an AI tool can read from your files and what it needs to know to assist you effectively. Each type addresses a different category of background knowledge, and each becomes more valuable over time as the work it relates to grows in complexity.
The Client or Matter Background Document
This document captures the foundational knowledge about the client, case, counterparty, or organisational entity that the work relates to. Its purpose is to eliminate the need to reintroduce the same background information in every AI prompt. Instead of beginning each session by explaining who the client is, what industry they operate in, what their strategic situation is, and what your relationship with them looks like, you write this information once in a background document and reference it from that point forward.
A useful client background document covers several categories of information. Industry and organisational context: the sector the client operates in, the size and structure of the organisation, the regulatory environment they face, and any significant recent developments in their industry that bear on your work. Key people: the names, roles, and relevant characteristics of the individuals involved in the engagement, including both the client-side contacts and your own team members. Relationship history: how long you have worked with this client, the key engagements or interactions that have shaped the relationship, any sensitivities or preferences that should inform how you communicate with them, and the current state of the relationship. Strategic context: what the client is trying to achieve, what challenges they are facing, and what the work you are doing for them is intended to address.
This document is most valuable when it is written at the beginning of a new engagement and updated at significant intervals, particularly when key personnel change, when the client's situation changes materially, or when the nature of the work evolves.
The Project Scope and Objectives Document
Where the client background document addresses who the client is, the scope and objectives document addresses what the current work is trying to achieve. This distinction matters because a single client may have multiple concurrent engagements, each with a different scope, different success criteria, and different constraints. Without a scope document, an AI tool working on one engagement may draw on context from another, or may apply a broader understanding of the client's objectives without recognising the specific parameters of the current project.
A scope document covers the stated objectives of the work, the specific deliverables expected, the timeline and key milestones, the constraints that govern what approaches are and are not available, and the definition of success that will be used to evaluate the outcome. It should also note any scope boundaries: things that are explicitly outside the current engagement, which the AI tool should know to avoid recommending or pursuing.
This document is particularly valuable for managing the tendency of AI tools to suggest solutions that are technically valid but fall outside the agreed scope of the work. An AI tool that knows the scope has been explicitly limited to operational improvements and does not include technology investment will not suggest a technology platform as the primary recommendation, even if that would be the natural conclusion of a broader analysis.
The Terminology and Glossary Document
Every organisation, practice area, and client engagement develops a specific vocabulary. Internal product names, proprietary methodologies, regulatory terms of art, case-specific shorthand, and firm-specific abbreviations accumulate over the course of professional work and become the natural language in which that work is discussed. For the professional working in that context, these terms are entirely natural. For an AI tool encountering them without explanation, they are opaque or, more problematically, they may resemble standard terms that the AI tool will interpret according to their general meaning rather than their specific usage in your context.
A terminology document records the specific vocabulary of your work. Each entry should include the term as used, its meaning in your specific context, and, where relevant, a note on how it differs from the standard or general-purpose meaning of the same or similar terms. This document does not need to be comprehensive from the outset. It can begin with the terms most likely to cause confusion or misinterpretation and be extended as additional terms are identified. The process of writing it is itself valuable, because it often surfaces terminological inconsistencies within a team or organisation that have been creating inefficiencies in communication without having been explicitly identified.
The Decision Log
Of the four types of context documents, the decision log is the one most frequently overlooked and the one that provides some of the most distinctive value in AI-assisted work. A decision log is a running record of the significant choices made during a project, matter, or engagement: what was decided, when it was decided, who made the decision, and the reasoning behind it.
The value of a decision log for AI-assisted work stems from a specific characteristic of how AI tools respond to complex professional situations. When an AI tool analyses a situation and generates recommendations, it applies general reasoning to the available information. If a decision has already been made, but the reasoning behind it is not documented, the AI tool has no way of knowing that the question is settled. It will surface the decision as an open question, recommend re-examining it, or propose alternatives to the chosen approach as though the choice were still being made. This is not a malfunction. It is the appropriate behaviour of a tool that has not been told what has already been decided.
A decision log closes this gap. When the AI tool has access to a record of past decisions and their rationale, it can apply that context to its responses. It will not recommend revisiting a strategic direction that was deliberately chosen, re-examine a legal approach that has been agreed with counsel, or propose a different organisational structure than the one that was selected after careful analysis. This makes AI outputs more directly useful and reduces the time spent managing responses that address questions the team has already answered.
The decision log should be updated whenever a significant decision is made. The entry for each decision should be brief: the decision itself, the date, the deciding party, and two or three sentences explaining the reasoning. Over time, this document becomes a reliable record of the logic that has shaped the engagement, which is valuable not only for AI assistance but for any team member who joins the work after the relevant decisions were made.
The Principle of Proximity in Context Storage
A context document has its greatest value when it is stored in the folder it relates to rather than in a centralised repository separate from the documents it supports. This principle, which might be called the proximity principle, reflects how AI tools conduct searches and how they apply the context they find.
When an AI tool searches within a folder for documents relevant to a query, it retrieves documents from that folder and interprets them together as a body of related material. A context document stored within the same folder is retrieved as part of this body and used to orient the interpretation of the other documents found there. A context document stored in a separate central location may not be retrieved at all, or may be retrieved in isolation from the documents it is meant to support, reducing its effectiveness.
The practical implication is that context documents should be co-located with the documents they describe. The client background document for Johnson Corporation belongs in the Johnson Corporation folder. The case summary for Smith versus Jones belongs in the Smith versus Jones case folder. The scope document for the Q1 Financial Review engagement belongs in the Q1 Financial Review project folder. When these documents are in the right place, they are retrieved automatically whenever an AI tool works within that folder, providing orientation without requiring explicit direction.
There is a limited exception to this principle for terminology and glossary documents. In organisations where specific terminology is used consistently across all clients, all matters, or all projects, a single glossary document at a higher level in the folder hierarchy may be more appropriate than individual glossaries for each folder. A firm-wide glossary of regulatory terms, for example, is more efficiently maintained as a single document at the top of the file system than as identical copies within every client folder. The judgment to be made is whether the terminology is truly consistent across all contexts or whether it varies by client or matter, in which case co-located glossaries remain the better approach.
Context Documents as a Form of Professional Infrastructure
It is worth stepping back from the practical details of context documents to consider what they represent at a higher level. A set of well-maintained context documents is, in effect, a written record of the professional knowledge that an experienced practitioner applies to their work. It captures the background that makes expertise expertise: the ability to produce outputs that are not just technically correct but situationally appropriate, relationship-aware, and grounded in an accurate understanding of the specific constraints and history of the work.
This knowledge has always existed. In the period before AI tools, it existed only in the minds of the professionals who held it, was transferred informally through conversation and mentorship, and was lost entirely when those professionals left an engagement or an organisation. Context documents make this knowledge explicit, portable, and persistent. They are valuable not only because they improve AI assistance, but because they reduce the organisational cost of knowledge transitions, improve the consistency of work across team members, and create a written record of professional judgment that can be reviewed, challenged, and refined over time.
Building context documents is an investment in professional infrastructure. Like any infrastructure investment, the benefit is not immediate but compounds over time. A context document written at the beginning of a new engagement becomes more valuable with each subsequent task it informs. A decision log maintained consistently throughout a project becomes an authoritative record of the thinking that shaped the engagement. A glossary updated with each new term that enters the working vocabulary of a team becomes a precision tool that reduces misunderstanding and improves the quality of every communication it informs.
The sections that follow address how to maintain this infrastructure over time, how to manage the privacy and security boundaries that govern what should and should not be captured in AI-accessible documents, and how the complete knowledge base integrates with the tools and workflows covered later in Stage 4.