I Read Patrick's Eight Bones and Recognised My Own Skeleton

My friend Patrick Prill published a post this week called "System Seeing Adventure - The AI Lock-In Catastrophe." It's one of the best things I've read about what's actually happening when organisations adopt AI without thinking about what they're giving up. He uses Ruth Malan's "System Seeing" concept to lay out eight "causality bones" of AI dependency. Eight ways organisations lose sovereign agency by handing cognitive capability to vendors they don't control.

I read it and kept nodding. Not because I'd thought about all eight in those exact terms. But because I've been building a system for over a year that, bone by bone, tries to avoid ending up in exactly the situation he describes.

So this isn't a rebuttal. Patrick is right. This is the story of how I accidentally ended up designing around his eight bones before he wrote them down.

The knowledge stays here

Patrick's first bone is the Knowledge Exodus. Organisations fire domain experts, lean on AI, and then discover that no one can evaluate whether the AI is hallucinating because the people who would know are gone. Each day starts with a "junior developer" who has forgotten everything.

I hit this wall personally. Every Claude conversation started blank. No memory of yesterday, no knowledge of my projects, no context from emails or calendar. The AI was capable, but it was amnesiac.

So I built a personal knowledge base. 64,000 documents. Emails, calendar events, meeting notes, past conversations, project history. All indexed locally with hybrid search. The AI doesn't hold the knowledge. I do. The AI gets handed context at query time, from my index, on my machine. If Anthropic disappeared tomorrow, I'd lose the reasoning engine. I wouldn't lose a single document.

That's Patrick's Bone 1, inverted. The knowledge never left.

The model is a swappable part

Bone 2 is the Brain Transplant Fallacy. Switching AI models isn't like swapping cloud providers. It's neurosurgery. Your prompts, your RAG pipelines, your evaluation frameworks are all calibrated to one model's quirks.

I've thought about this a lot. My system uses Claude as the primary reasoning engine, but the architecture treats the model as one layer in a stack. The knowledge base, the FUSE filesystem, the org-mode task management, the MCP tools, the ingestion pipelines - none of that is Claude-specific. I run a local Gemma model for doc card generation. I've tested Qwen for PA fallback. I built an evaluation framework specifically so I can benchmark new models against real workflows before switching.

Is it painless to swap? No. Patrick is right that it's harder than changing plumbing. And I'll be honest, I haven't had to do a full swap under pressure yet. The theory is sound. The emergency drill hasn't happened. But it's possible because the system was designed for it. The model is the brain, but the body is mine.

The end goal is to be able to run the whole thing locally. That's half the reason the eval framework exists, and why I bought a second GPU. I want to be in a position where I can cut the transatlantic trip entirely and run against local models if I need to. Anthropic just keeps raising the bar and making it harder to justify the switch.

The reinforcing loop has a brake

Bone 4 is the reinforcing loop: fewer staff leads to more AI reliance leads to less verification capacity. Patrick calls this "velocity without verification." For organisations, it's a death spiral.

I feel this pull personally. The PA handles email triage. Claude Code writes code. The knowledge base surfaces context I'd otherwise forget. Every month the system gets more capable, and every month I rely on it more.

But there's a deliberate brake built into the design. The PA suggests actions. It doesn't take them. Every email reply, every task created, every file modified goes through an approval gate. I called the feature "suggestions" for a reason. The system proposes, the human disposes.

When the automated entity aggregation engine ran against the full corpus, it surfaced 1,512 entity candidates. 79% were rejected as noise. Days of the week. Programming language names. API terms. "Monday" is not an entity. That rejection rate isn't a failure. It's the brake working.

Whether I'll still have the discipline to review every suggestion when there are 50 a day instead of 5, I don't know. Patrick's loop is patient. It doesn't need you to stop checking all at once. It just needs you to start skimming.

Non-determinism needs a constitution

Bone 5 is about non-determinism. AI models produce different outputs from identical inputs. You can't reproduce, trace, or debug a black box.

I can't solve non-determinism. Nobody can. But I can build infrastructure that assumes it exists.

The Data Constitution is a 7-gate pipeline that every document passes through before entering the index. If an LLM generates a summary with a missing field, the system doesn't fill in a blank. It quarantines the item, preserves the payload, and logs exactly why. 761 items quarantined so far. 300 replayed successfully after the underlying issue was fixed.

You can't make AI deterministic. But you can build a system that catches when it's wrong and preserves the evidence. That's what the Constitution does.

My data stays on my machine

Bone 7 is about intellectual property taking a transatlantic trip. European organisations invested in GDPR and data residency, then routed their codebases through US-based AI APIs without thinking about it.

I'm a Swedish consultant. I think about this.

The knowledge base lives on my local machine. The FUSE filesystem, the SQLite databases, the LanceDB embeddings, the org-mode files - all local. When I use Claude, the reasoning happens via Anthropic's API under their no-training policy. My data transits for inference but isn't stored or used for training.

Is this perfect? No. The prompts still cross borders. Every time I ask Claude about a contact or a project, fragments of personal data transit through a US-based API. I trust Anthropic's no-training policy, but trust is not the same as control. There's a deliberate trust boundary between what stays local (everything) and what transits for reasoning (the minimum necessary context). I control what goes over the wire. Most organisations don't even think about it.

The price trap has an escape hatch

Bone 8 is the price trap. Current AI pricing is subsidised. When venture capital runs out, costs will multiply. And by then your workflows are rebuilt around the platform.

This one I think about at 3am sometimes.

My system depends on Anthropic's API for the reasoning layer. If pricing triples, I have a problem. But the architecture was designed so the expensive part (the model) is the most replaceable part. Local models handle doc card generation and embedding. The evaluation framework lets me test whether a cheaper model can handle specific workflows. The knowledge, the tools, the pipelines - those are sunk costs that work with any model.

I can't escape the price trap entirely. But I can make sure that when prices move, I'm moving a brain from one body to another. Not rebuilding the body.

What Patrick gets right that I can't design around

Reading Patrick's post did something useful. It gave me language for risks I'd been designing around instinctively but hadn't articulated as clearly. It also made me honest about the bones I haven't solved.

Bone 3 (systemic bottleneck) is real. If Anthropic goes down or changes terms, I'm in the same queue as everyone else looking for alternatives. Having a swappable architecture doesn't help if there's nowhere to swap to.

Bone 6 (the ground shifting) still bites. Anthropic deprecates models, changes behaviour between versions, and I discover it when outputs feel different. I've pinned model versions where I can, but I'm still standing on someone else's platform.

And the biggest thing Patrick gets right: most organisations won't build what I built. I'm one person with a testing background, a taste for Python, and an unreasonable willingness to spend weekends writing FUSE filesystems and entity aggregation pipelines. I've been building this for over a year. Twelve systemd services. Eight interconnected subsystems. 64,000 indexed documents. A data governance framework I wrote because search results felt slightly off.

That's not a template. That's a hobby that got out of hand.

Patrick's post isn't for people like me. It's for the organisations that adopted AI the easy way - vendor API, off-the-shelf tools, let it handle things - and haven't thought about what happens when the ground shifts. For them, all eight bones are load-bearing. And none of them have escape hatches.

See the system

Patrick ends with Derek Cabrera's principle: "Love Reality!" Reality should inform models, not the other way around.

I'd add one thing. Seeing the system is the first step. Building around what you see is the second. And honestly admitting what you still can't control is the third.

My system is a bet that knowledge should be sovereign, that models should be swappable, and that human judgment should remain in the loop. Patrick's eight bones are a map of what happens when you make the opposite bet.

Read his post. Then look at your own dependencies. Really look.