| CLIENT MATTER ISOLATION PROCEDURES REFERENCE OpenClaw · Chroma Vector Database · Local AI Confidential Personal Reference | March 2026 |
|---|
| About This Document This document defines the procedures required to keep each client's matter — including all documents, AI session memory, and vector database records — fully isolated from every other client's matter. It addresses the requirements of ABA Model Rules 1.6, 1.7, and 1.9 as applied to the local AI and document research environment. Two systems require isolation: (1) the Chroma vector database used for document retrieval, and (2) the OpenClaw agent and its persistent memory. Both must be configured and used correctly for client matters to remain truly segregated. |
|---|
Three ABA Model Rules of Professional Conduct are directly implicated when AI tools process client documents alongside documents from other clients.
| Rule | Title | Relevance to AI Systems |
|---|---|---|
| Rule 1.6 | Confidentiality of Information | Requires that all information relating to a client's representation be kept confidential. An AI system that can retrieve one client's documents in response to queries about another client's matter creates a confidentiality risk. |
| Rule 1.7 | Conflict of Interest: Current Clients | Prohibits representation that is materially limited by the lawyer's responsibilities to another client. A shared AI knowledge base creates a technical mechanism by which one client's matter can influence work product generated for another. |
| Rule 1.9 | Duties to Former Clients | Extends confidentiality and conflict protections to former clients. Documents from closed matters must remain isolated from active matters and from other former clients. |
In a standard vector database setup, all documents from all clients are indexed together. When you ask the AI a question, it performs a semantic search across everything — and the most relevant results may come from any client's documents, regardless of which client you are currently working on.
Example: You are working on a lease analysis for Client B on a tract that is adjacent to a tract you researched for Client A last month. In a shared database, Client A's instruments, WI calculations, and lease terms could surface as context in Client B's answer — without any indication that those documents belong to a different matter.
The same risk exists in OpenClaw's persistent memory. If the agent wrote notes from a Client A session into its memory files, those notes remain on disk and will be read into the context window during a Client B session unless the memory is physically isolated.
The legal AI industry has converged on the concept of "ring-fenced" environments as the architectural standard for confidentiality compliance. A ring-fenced environment is one where matter data is physically isolated and cannot cross-contaminate another matter's context — not just through access controls, but through structural separation.
The procedures in this document implement ring-fencing at two layers: the document retrieval layer (Chroma collections) and the agent memory layer (OpenClaw workspaces).
Chroma, the local vector database used for document storage and semantic search, organizes documents into named collections. Each collection is a completely independent index. A search run against one collection cannot return results from another collection — this is enforced at the query level by the database itself, not through filtering.
Each client matter must have its own dedicated collection. No documents from one client are ever indexed into another client's collection.
The following folder structure is used for all land records work. Replace client_1, client_2, etc. with the actual matter identifier (typically the client name or project code):
~/Documents/LandRecords/
client_1/
inbox/ ← Drop new documents here before processing
processed/ ← Cleaned text + original PDFs after OCR
database/ ← Chroma collection for this client only
client_2/
inbox/
processed/
database/
client_3/
inbox/
processed/
database/
⚠ NOTE: Never place documents from different clients in the same inbox folder. Documents are indexed at the point of processing, and a document processed into client_1's database cannot be selectively removed from a combined collection later.
Run these commands once when setting up a new client matter:
mkdir -p ~/Documents/LandRecords/client_1/inbox
mkdir -p ~/Documents/LandRecords/client_1/processed
mkdir -p ~/Documents/LandRecords/client_1/database
Always specify the client when processing. Never run the pipeline without a --client flag:
# Process a single document into client_1's collection
python3 process_doc.py process myfile.pdf --client client_1
# Process everything in client_1's inbox folder
python3 process_doc.py inbox --client client_1
Always specify the client when querying. The --client flag restricts the semantic search to that collection only:
# Chain of title query — client_1 only
python3 process_doc.py ask "chain of title NW/4 Section 22" --client client_1
# Generate runsheet draft — client_1 only
python3 process_doc.py ask "Create runsheet for SW/4 NE/4 Section 14" --client client_1
✔ RULE: There is no command that queries across all clients simultaneously. If you find yourself wanting to do this, stop — the question being asked should be scoped to one client matter at a time.
When a client matter is closed, its database folder should be archived, not deleted. Retain the full folder structure (inbox, processed, database) so that historical queries can be run if needed. Archive to an encrypted backup location and remove the folder from the active LandRecords directory:
# Archive client_1 to external backup
cp -r ~/Documents/LandRecords/client_1 /Volumes/BackupDrive/ClosedMatters/
rm -rf ~/Documents/LandRecords/client_1
OpenClaw has three memory layers that behave differently:
| Layer | What It Contains | Does It Survive Session End? |
|---|---|---|
| Conversation history | Everything said in the current session window | No — cleared when session ends |
| Long-term memory files | Notes and facts the agent writes to disk (memory/YYYY-MM-DD.md) | YES — persists indefinitely across sessions |
| Pre-compaction flush | Context the agent saves before the context window fills up | YES — written to disk, persists |
Starting a new session clears the conversation history but does not clear long-term memory files. If client-specific notes were written during a client_1 session, those notes remain on disk and will be read back into context when any subsequent session is opened in the same workspace — including a session you intend for client_2.
A new session is necessary but not sufficient for client isolation. The workspace itself must be different.
OpenClaw's workspace is the directory it reads from: AGENTS.md, SOUL.md, and the memory/ folder. Each client matter must have its own workspace directory. When OpenClaw is started, it is pointed at a specific workspace, and the agent's memory is confined to the memory/ subfolder of that workspace.
~/openclaw-workspaces/
client_1/
AGENTS.md ← Project-specific instructions for this matter
memory/ ← Memory files for client_1 sessions only
client_2/
AGENTS.md
memory/
client_3/
AGENTS.md
memory/
shared/
AGENTS.md ← General instructions not specific to any client
SOUL.md ← Agent persona (same across all clients)
Run these commands once when setting up a new client matter. Copy the shared AGENTS.md as a starting point, then add any matter-specific instructions:
mkdir -p ~/openclaw-workspaces/client_1/memory
cp ~/openclaw-workspaces/shared/AGENTS.md ~/openclaw-workspaces/client_1/AGENTS.md
cp ~/openclaw-workspaces/shared/SOUL.md ~/openclaw-workspaces/client_1/SOUL.md
Then edit ~/openclaw-workspaces/client_1/AGENTS.md to add matter-specific context: the county, state, abstract numbers in scope, the type of work being done, any specific instructions for this engagement.
To start an OpenClaw session for client_1, launch OpenClaw with the workspace flag pointing to that client's directory:
# In the OpenClaw terminal or config, set workspace path:
openclaw --workspace ~/openclaw-workspaces/client_1
Alternatively, in your openclaw.json config, set the workspace path before launching:
"workspace": "/Users/yourname/openclaw-workspaces/client_1"
⚠ NOTE: Verify the correct workspace is loaded before beginning any client session. OpenClaw displays the active workspace path at startup. Confirm it matches the intended client before proceeding.
Follow these steps every time you work on a client matter:
| Step | Action | Why |
|---|---|---|
| 1 | Close any open OpenClaw session | Ensures previous client's conversation history is fully cleared from the context window |
| 2 | Verify which client you are about to work on | Prevents launching into the wrong workspace under time pressure |
| 3 | Launch OpenClaw with the correct --workspace flag | Confines memory reads and writes to that client's folder only |
| 4 | Confirm workspace path shown at startup matches the client | Catches misconfiguration before any work begins |
| 5 | Proceed with the session | All memory writes will go to client's memory/ folder only |
| 6 | Close the session cleanly before switching clients | Ensures pre-compaction flush completes, writing all pending memory to disk in the correct folder |
| 7 | Do not open another client's workspace until step 6 is complete | Prevents memory from one session being written into another client's folder |
Add the following instruction to each client's AGENTS.md to prevent the agent from writing identifying cross-matter information into memory:
## Memory Rules
- Never write the client's name, company name, or matter number into memory files.
- Never write specific legal descriptions, tract identifiers, or instrument numbers
into memory files unless they are directly relevant to an ongoing task.
- Workflow preferences and procedural notes may be written to memory.
- When in doubt about whether to persist information, do not write it.
This keeps the memory files useful for workflow continuity while preventing them from accumulating client-identifying information that would need to be purged on matter close.
When a client matter is closed:
The local deployment architecture (Ollama + DeepSeek R1 14B running on the Mac Mini) provides an important additional protection that cloud-based AI systems cannot match: the AI model itself does not retain anything between sessions.
Cloud-based AI systems — including publicly available versions of ChatGPT, Claude, and similar tools — run on shared inference infrastructure. While reputable providers maintain contractual prohibitions on cross-customer data use, the technical architecture involves shared systems that process multiple users' queries. Self-learning models in particular (those that improve by processing user inputs) create a risk that confidential information entered in one session could influence outputs in another session for a different user.
With a local model running via Ollama, each query is fully stateless. The model processes your prompt, generates a response, and retains nothing. There is no shared infrastructure, no training feedback loop, and no mechanism for information from a client_1 session to ever appear in a client_2 session at the model level.
This means the isolation requirements described in this document focus entirely on the two layers that do retain information: the Chroma database (by design) and OpenClaw's memory files (by design). Both are addressed by the procedures above. The model itself requires no special handling for client isolation because it is already fully stateless.
| System Component | Retains Data? | Isolation Method |
|---|---|---|
| DeepSeek R1 14B (Ollama) | No — fully stateless | No action required |
| Chroma vector database | Yes — by design | Per-client collections with --client flag |
| OpenClaw memory files | Yes — by design | Per-client workspaces with --workspace flag |
| OpenClaw conversation history | Session only | New session before each client switch |
— End of Document —