Four principles
1. Measure before you build. Every installation starts with a scored baseline across six categories of AI capability. The same score is re-run at the end. If the number didn't move, the work didn't work. Most AI advice skips this step because it makes the advice accountable.
2. Your context is the asset. The model is the engine. Models are swapped every few months. The knowledge, voice, and role definitions you codify are what compound. So the system lives in plain files in a repo you own: dated, versioned, readable by any model, portable to any vendor.
3. Codify judgement, not just knowledge. Connecting documents is table stakes. The harder, more valuable work is writing down the four or five things you check when you rewrite AI output: tone, framing, audience respect, absence of buzzwords. That becomes a voice file and an evaluation rubric, and every future output is measured against it. This is the difference between a system that sounds like you and one that sounds like the internet.
4. A system that needs its installer is a failed installation. Every engagement ends with a 30-day handover document and a maintenance loop the owner runs without me. Capability transfer, not lock-in.
Three pillars
The framework installs three things, in this order. Each one builds on the last.
Pillar 1: Context. Connect the knowledge the business already has. Your documents, briefs, decks, and notes become available to the AI directly, so the hour a day spent re-pasting context disappears. The trade-offs of each knowledge store (what to connect, what to leave out, what leaks stale context into answers) matter more than the tool choice.
Pillar 2: Workflows. The three to five jobs you do every week become tuned, reusable workspaces: brand briefs, investor updates, customer replies, campaign strategy. Each workflow is built on your real work, measured against your rubric, and improved by use. Not prompts you retype. Systems you run.
Pillar 3: Archetypes. Written definitions of the AI colleagues your business needs but hasn't hired: the sales development rep, the operations manager, the analyst. Each archetype has a job description, escalation rules, and a quality bar. Archetypes are the most durable layer: they describe roles in your business, so they outlast every tool and model underneath them.
Substrate-agnostic by design
There is a running argument in the AI-systems world about where your context should live: folder structures, vendor features like Claude Projects and Skills, memory systems, RAG pipelines. The loudest voices reverse position on this regularly, sometimes within the same week.
The framework's answer: that argument is about deployment targets, not architecture. Your baseline, voice file, workflows, and archetypes live as plain files in a version-controlled repo. From there they deploy as Claude skills and project instructions today, and re-target whatever surface wins next. When a vendor changes the rules, you redeploy. You don't rebuild.
This is also why the deliverable of every engagement is a repo you own, not an account on someone else's platform.
How this relates to other methods
Structuring context in plain files is increasingly common ground: folder-based methodologies, vendor-native projects, personal knowledge systems. If you've read any of them, the pillars above will feel familiar, and that's fine. The premise is shared: context, structured well, is the durable asset.
What this framework adds is the accountability wrapper: a scored baseline before, a re-score after, a codified voice in between, and a maintenance loop at the end. Method you can read anywhere. Measurement and ownership are the parts that usually go missing.
Two ways to use this
Learn to install it yourself in the cohort course, or have it installed for you in an AI Brain engagement. Either way you end up owning the system.