AI Sovereign Setup

Who This Is Not For

You want a plug-and-play solution.

You do not want to manage files or version control.

You prefer simplicity over control.

If you fall into the second group, the simplified path at the end of this playbook is the place to start.

What You Need

A note-taking app that uses plain markdown files. Obsidian is the standard. Free for personal use.

A code repository for backup and version history. GitHub. Free for private repos.

A sync method. Obsidian Sync handles phone, tablet, and computer sync without setup. Optional but useful.

An AI tool with file access. Claude Code, ChatGPT desktop with file access, or any equivalent.

Buy the AI subscription on the provider's own website, never through the App Store on your phone. Apple adds its cut to any subscription bought inside an app, and the markup grows with the plan tier. One Mentor client paid about a quarter more for the same plan through her phone than she would have direct. If you already subscribed through Apple, cancel it and re-subscribe on the website.

A computer you control. Not a tablet, not a phone, for the initial setup.

An understanding of model tiers. Not all tasks need the same model. Light file work and formatting use the smallest capable model. Content drafting and reasoning use a mid-tier model. Strategy and architecture use the top model. Matching the model to the task preserves your token budget for work that actually needs it.

How Sync Works: Push Up, Pull Down

This is the part that trips people up, so it is worth slowing down on.

GitHub is the single source of truth. The vault on your computer is a local copy of it. Every other device you work on is also a local copy.

Push up means sending your local changes to GitHub. You do it after you make changes. It backs up your work and updates the source of truth so every other device can get the latest.

Pull down means bringing the latest from GitHub onto the computer you are about to use. You do it before you start. It catches your local copy up to anything that changed since you last worked there.

The question that comes up is why you would ever pull down. The answer is that you do not only work on one computer. When you work in the cloud through an AI tool that runs against the repository directly, or on a second device, those changes land in GitHub first. Your main computer is now behind. If you start editing without pulling, you are working on a stale copy, and when you push you get a conflict.

So the rhythm is simple. Pull down before you start. Push up when you finish. Down to catch up. Up to back up. The Git plugin can run this on a timer, but understanding the direction is what keeps you out of trouble.

If you only ever work on one machine and never touch the cloud, you still push up to back up. You just rarely have anything to pull down. The moment you add a second device or any cloud work, pulling down first is what stops the two copies from fighting.

Setup Steps in Order

Step one. Install Obsidian on your main computer. Create a vault folder in a plain local location. Not iCloud Drive. Not Dropbox. A regular folder on the computer's hard drive.

Step two. Create a private GitHub repository. Open a terminal in your vault folder. Initialise git. Connect the local folder to the GitHub repository. Push the empty vault up.

Step three. In GitHub, create a personal access token with repo permissions. Save the token somewhere secure. You will need it for the sync plugin.

Step four. Install the Obsidian Git community plugin inside Obsidian. Configure it to pull from and push to GitHub every ten minutes. Use your username and the personal access token for authentication.

Step five. On any second device, clone the repository to a plain local folder and open that folder as a vault in Obsidian. Install Obsidian Git there too. Use the same token.

Step six. Optional. Obsidian Sync gives you fast device-to-device sync. I do not run it alongside git on the same vault: two automatic sync layers moving the same files can race each other, and I paused Obsidian Sync on my laptop after a near miss. If you want both, understand the overlap before you switch it on. GitHub is the layer a cloud session can read; a local session reads whatever files you authorise on the machine.

Step seven. Create your starter folders inside the vault. Write a single file in Memory called Memory.md. Add a few lines about your current state. Save. Watch the change land on your other devices within ten minutes.

Step eight. Open your AI tool of choice. Either give it access to your vault folder, or paste in the key files (Memory and any active reference documents) at the start of each session. Tell it how you want it to operate. From that point on, the AI reads from the vault every session.

What to Keep in the Vault

Everything that informs how you make decisions. The methods you operate by. Client context. Voice standards. Pending decisions. Past decisions and why you made them. Performance data that drives the next move.

What not to keep. Passwords. API keys. Anything sensitive that should not sit in a repository, even a private one.

When the AI Marks Its Own Work

A failure mode worth watching for: a vault-connected AI audits itself, or reports its own status, and the report is wrong. Not maliciously, just wrong. A fabricated number. A requirement cited as fact that does not exist anywhere in the vault. A correction that gets made once and then quietly reappears.

The AI sounds exactly as confident when it is wrong as when it is right. A polished status report is not evidence the work happened.

You do not need to verify everything by hand, that would defeat the point of automation. Verify the claims that matter: anything client-facing, anything published, anything touching permissions or access, and any claim that a known error was corrected. Open the actual file or output and check it against the source. Keep routine execution unattended where the stakes are low. Put a human approval step at the points where being wrong is expensive.

Run a hardening pass periodically, not just at setup: ask your AI to check itself for contradictions across files, claims stated with no source, and instructions pointing at files or processes that no longer exist. Treat what comes back as leads to check, not a clean bill of health. The findings are not verified until you have looked at the consequential ones yourself. For anything consequential, the same principle in AI Outside View applies: a single model checking its own work is the least likely source to catch what it is confidently wrong about. A second source with different context will.

A related signal, separate from the compaction guidance above: a session that keeps re-asking something you already answered, or returns to a conclusion you already corrected despite a clear reminder, has lost the thread. Before you close it, capture what is actually true: the verified state, the correction, and the next action. Write that to your Memory file yourself if you are not confident the session's own summary has it right. Then close it and start fresh.

Two smaller checks worth adding to your setup routine. After any restructure, confirm folders are named and referenced exactly as intended, a near-duplicate folder from a naming slip is an easy thing to miss. And for any connected app with access to your repository, GitHub, Cloudflare, or similar, check what it can actually reach: which repositories, which data, read or write. Apply the same minimum-access rule to people. Do not assume separating a repository is enough on its own, check who and what can see it.

Run It From Anywhere

Everything I built used to work only when I sat at one desk. The scripts, the local tools, the files, the connections to the services I use. Leave the desk and the system stayed behind.

The fix is a split. One machine does the work. Any device steers it.

What runs. My main desktop stays on at home. Every working session starts on that machine. From a laptop or a phone I open the same session and give it instructions. The desktop reads the files, runs the tools and does the job. I see the result wherever I am.

Why start the session on the desktop. The local tools live there. The scripts, the file access, the saved connections. A session started on a phone has none of that. A session started on the desktop and steered from a phone has all of it.

What it replaced. Waiting until I got home. Carrying a laptop set up as a second copy of the desk and keeping the two in step.

What changed. I edited a video from my phone on a weekend away while the session ran on my computer at home. The file was on the desk. The tools were on the desk. I was on holiday with a phone.

A word on the cloud-hosted versions of this. There are tools that will run an agent for you on their servers. The problem is that your keys sit on someone else's machine. It might be remote, but it is never truly yours. Stop paying the subscription and you lose the lot. And every key you hand over is one more place a leak can start. Running it on your own machine, in your own environment, is the most secure and the most controllable option. It is the same idea as Own the Racecourse: use the rented services to reach the system, never to hold it.

Those cloud tools also tend to burn a lot of tokens or credits whenever they run things in the background. On your own machine you can run regular routines and scripts locally without any cost or token usage.

Two rules keep this safe. Test one real job end to end before you trust it. Pick a job you can check, run it from the phone, then check the output on the desktop. And run one job per session. A phone is a poor place to supervise three things at once.

This is a later-stage capability, like the unattended routines below. If you are still on the simplified path, skip it for now. The vault, the close sequence and the backups come first.

The Client File That Updates Itself

This is what the Clients folder looks like once a routine feeds it.

For years my client notes lived in four places. The call recording. A notebook. A chat thread. My memory. Before each call I would hunt through them. Often I walked in having forgotten what we agreed last time.

Now one file per client updates itself after every call.

What runs. Every client call is recorded as a transcript. Audio only, with consent. No video. After the call, the transcript is split by client. Each client's part becomes a dated entry at the end of that client's file. The commitments they made, and the ones I made, go to a focus line at the top. Before the next call I read the focus line. That takes under a minute.

What it replaced. The hunt through four places. The notes I meant to write and did not. The first ten minutes of every call spent catching up.

What changed. I walk into every call knowing where we left off. The client's own words from last time are in front of me. If they said they would send the proposal by Friday, Friday is on the focus line. The call starts on the thing that matters instead of a recap.

The tool reference is short. Whatever records your calls and gives you a transcript. The rest is the vault doing what it already does: one folder per client, dated entries, the AI reading the file at the start of a session.

Privacy is the reason for two of the choices above. Transcripts, never video. A transcript holds what was said and nothing else. And the files stay on your own machine, in your own repository. Client data never goes into a public tool or a shared chat. If a client asks where their notes live, you can show them the folder.

Two rules keep the file useful. Only the durable facts go in. A decision, a commitment, a change in the business, a number. The chat about the weather does not. And the focus line is rewritten each time, never added to. It should read in ten seconds.

If you run group calls, the same routine splits one transcript across every member's file. One call, every file current.

Start with one client. Record the next call, make the entry by hand if you have to, write the focus line. Read it before the following call. Once you feel the difference, hand the routine to your AI and let it run.

What Actually Shifts When You Move From Chat to Vault

This is the operational layer. The architecture above describes what to build. This describes what changes the day after.

Cross-session memory becomes real. In a chat-based setup the AI forgets between conversations. You re-explain who the client is, what was decided last week, what voice you use. In a vault-based setup the AI reads the client extract at the start of every session. Patterns logged three weeks ago surface in today's response. Decisions you made in March show up in May coaching. The vault remembers so you do not have to.

Voice consistency stops being interpretive. In chat the AI tries to match your voice from inference. It drifts. It uses your forbidden phrases. It leaks AI tells. In a vault setup voice rules live as files: hard stops, forbidden phrases, per-client constraints. A file on its own is a reminder the AI reads; enforcement is a check that runs on the output. My Claude Code setup uses a hook to check final replies for specified banned patterns and request a rewrite when it finds one. It has exceptions and cannot judge every voice rule. Drift drops hard with the files and further with the hook. It never reaches zero: the scanner catches what it can match, the rest is judgment, so the rules keep getting sharper.

Specific intel stops being approximated. Numbers, dates, deal terms, client preferences, prior commitments. In chat these blur over time because the AI is summarising from compressed memory. In vault they live in extract files. The reply quotes them exactly. "You handed Helen to Dan this morning" lands because the file says so.

Pattern recognition compounds. Every coaching call, decision, content piece, and outcome lands in a file. A pattern that surfaces three times across two months gets named and tracked. The next time the pattern shows up the AI catches it inside one sentence. This is not memory tricks. It is structured note-taking made readable by the AI.

Operator judgment becomes the moat, not the framework. The architecture is increasingly public. Folder, routing, interface, loops. Anyone can build the structure. What stays scarce is the operator running it. The judgment about which work to cut, which AIs to avoid, which signals matter. The vault holds and applies that judgment consistently. The framework is the floor. The operator is the ceiling.

You stop rebuilding context every session. You start building leverage every session.

Naming the Stack

The brand-level name for an operator-grade vault system varies. Pick one or use the names that already exist in your space.

Operator OS, Knowledge System, AI Sovereign Setup, or your own brand name applied as the wrapper.

The internal engineering stays internal. The brand wrapper is the consumer-facing layer. Same logic any product business runs by. Internal: code, infrastructure, frameworks. External: the brand customers say out loud.

For Mentor clients running this playbook, the recommended split is a recognisable consumer-facing brand on the outside, plain framework names on the inside. The brand earns the conversation. The frameworks do the work.

The Starter Prompt

If you want the whole thing built in one go, including your existing Claude projects, this is the prompt I send people. Make a new empty folder on your computer, open Claude Code and point it at that folder, and paste in everything between the two lines below. If it says it cannot see Chrome, install the Claude in Chrome extension first and run it again.

You are setting up my business operating vault. This folder is the single source of truth for how my business runs and for everything you learn while working with me. Build it now.

Step one. Create this structure, all plain markdown files: CLAUDE.md at the root, MEMORY/Memory.md, PROJECTS/, SESSIONS/, REFERENCE/, CONTENT/, DATA/, and OPEN_QUESTIONS.md.

Step two. Write CLAUDE.md as your standing instructions. At the start of every session read MEMORY/Memory.md first, then the PROJECTS file for whatever we are working on. At the end of every session, or when I say close, write a session log to SESSIONS/YYYY-MM-DD-topic.md with what we did, what we decided and what is still open, then update MEMORY/Memory.md with only what changed. Keep Memory.md under 150 lines. Never invent a fact; if you are unsure, write the question in OPEN_QUESTIONS.md. Ask before deleting anything. Plain text, no filler.

Step three. Migrate my existing Claude projects. Use the Claude in Chrome extension to open claude.ai, go to Projects, and work through every project I have. For each one read the project instructions, every file in its project knowledge, and the recent conversations. Write PROJECTS/project-name.md with: what the project is for, the rules and preferences I gave it, what it worked out that worked, what went wrong or wasted time, and open tasks. Copy the knowledge files into REFERENCE/ where they are still useful. Route what you find by type, not by convenience: facts about a client go in that client's folder, voice rules go in the voice file, strategy goes in STRATEGY/, and only live state (what is open now, what is pending, what to watch) goes into MEMORY/Memory.md. Memory.md is a short cockpit read at the start of every session, capped at a page or two. If everything true about me lands there, the AI reads all of it every session and stops noticing what changed.

Step four. Run git init and commit the vault so I have version history on my own machine.

Step five. Show me the folder tree, a ten line summary of what you found, and the open questions. Then close the session properly per CLAUDE.md so I can watch the loop work once.

That is the whole prompt. The first session builds the folder, reads your projects into it and closes the loop once so you can see it work. Every session after that starts by reading the memory file and ends by updating it.

Deciding what your AI should know about your business, and what it should never touch, is the judgment call. That is what I work through with Mentor clients.

End of playbook.