Four stages.
One operating system.

The whole book, in one ladder.

1. 1 Starter 2 to 3 weeks
   1. 1.0 Choose one workflow
   2. 1.1 Know me
   3. 1.2 Learn my work

   Gate: One real run, human-reviewed, recorded.

2. 2 Intermediate 4 to 6 weeks
   1. 2.1 Know what is true
   2. 2.2 Remember my world
   3. 2.3 Capture and commit

   Gate: Memory stays current and the routine is in use.

3. 3 Expert about 10 weeks total
   1. 3.1 Know your limits
   2. 3.2 Help me operate

   Gate: Limits enforced; stop and restore drills pass.

4. 4 Frontier Operator 12 to 14 weeks total
   1. 4.1 Automate the proven work
   2. 4.2 Improve and survive

   Gate: Value, portability, and continuity proved.

The Promise

What you can say at day 1

At the end of your first working session, you hold a printed page titled “How I operate.” It was built from your own words, in an interview, not from a quiz, not from a template. Every claim on it traces to something you actually said. It includes at least one finding you would not put on a brochure, because that is how you know the rest of it is true.

You also hold a one-page brief for one real workflow, with a first real use scheduled inside seven days. No new tools. No automation. But for the first time, an AI assistant has read a document telling it who you are, what your work requires, and what it must never assume, and behaved accordingly in a fresh session, under test.

That is day 1.

What you can say at day 180

Six months in, the standard is harder. At day 180, you can say:

• The system is still in use at every expected opportunity. Not abandoned. Not “meaning to get back to it.”
• You no longer re-explain yourself. Your context, sources, decisions, and boundaries, the AI has them, current, from files you own.
• Failures happened, and each produced a recorded correction and a passed retest.
• A second AI tool ran your system without losing anything. The vault moved. The knowledge stayed.
• Someone else could resume your work from your maintained records if you disappeared for two weeks.
• The value exceeds the upkeep, and you can show the numbers.

And the sentence the whole program is built to earn: “I cannot imagine going back.”

That sentence is not marketing copy. It is the graduation criterion. If the answer at day 180 is no, the program produced a binder, not an operating system.

Why most AI use fails

Most AI adoption fails for one reason: the workflow integration gap, not the model.

The models are good enough. They have been good enough for a while. What is missing in almost every failed attempt is the surrounding structure, the context the model never received, the source rules it never knew, the boundaries nobody wrote down, the review ritual nobody scheduled. People paste a request into a chat box, get a plausible answer, and either over-trust it or give up. Both outcomes come from the same cause: the AI was asked to operate inside a vacuum.

The research behind this program is blunt about the failure rates. Training-style AI programs lose roughly 90% of what they teach within a week when nothing reinforces it. Markdown memory systems, the obvious “just write it down” fix, fail temporal and adversarial recall about half the time when built naively. Ambitious personal knowledge systems burn out their owners in about two months under their own complexity. And enterprise studies find that the organizations succeeding with AI are about three times more likely to measure it, not because measurement is virtuous, but because what isn’t measured isn’t maintained.

The gap is never “a better prompt.” It is always the missing operating system around the model.

What makes this different

Three things, each chosen against the grain of the market.

Interview-built, not template-filled. A blank template asks abstract questions and gets vague answers. An interview asks about the last time the work went wrong and gets the truth. Every artifact in your system is extracted from conversation, your words, your incidents, your constraints, and then tested. We do not hand you worksheets. We extract your operating system in conversation.

Tested, not trusted. Every interview ends with an artifact that must pass a defined test in a fresh session, and a real use on real work, before the next interview begins. A filled template is not evidence. A passed test is not real use. Real use is not continued reliance. The program respects all three distinctions.

Reinforced, not delivered. The program is deliberately paced across weeks, with scheduled touchpoints at day 3, 7, 30, 66, 90, and 180, because the science of habit formation and forgetting says that is where systems live or die. We stay until it’s a habit.

Installations produce artifacts; tests prove them. That is the whole method.

How the Program Works

The operating rule

Every interview, all ten, plus the intake, ends with the same five things:

1. A reviewed artifact. Drafted by AI, edited and approved by the accountable human. AI proposes; the owner decides.
2. A passed test. Each artifact carries a pass/fail test, run in a fresh session with no chat history to lean on.
3. A real use scheduled. On the calendar, against real work, within days, not “when you get a chance.”
4. An outcome recorded. Date, result, review time, corrections, failures, next improvement, one entry in the evidence log, every time.
5. A correction loop. Every recorded failure changes the artifact, and the failed test is rerun until it passes.

An interview that ends without all five did not happen. It was a conversation.

The interview cycle

Each of the ten interviews follows the same eight steps:

1. Choose one real target. One workflow, one capability, one artifact. Never “AI in general.”
2. Set the boundary. Which records may be used, which audiences are involved, which actions are permitted, which require approval, which are never allowed, who owns and who reviews.
3. Conduct the interview. One question at a time. Critical incidents over hypotheticals. Follow-ups only when an answer would materially change the artifact.
4. Draft the artifact. AI converts the answers into the required document, separating approved facts, proposed rules, assumptions, unanswered questions, and evidence still needed.
5. Human review. The owner edits. Every material claim must trace to something the participant said, decided, or demonstrated. Unknowns stay marked as unknowns.
6. Run the test. The module’s pass/fail test, in a fresh session. A filled template is not proof.
7. Use it on real work. The first real use is scheduled immediately, at Starter, within seven days.
8. Record the outcome. The evidence-log entry closes the loop: result, review time, errors, corrections, retest date, next use.

One capability at a time. Do not run all ten interviews in one conversation. Complete one capability, test it, and use it before moving to the next, roughly one capability per week, never one per day. The pacing is not a courtesy. It is the mechanism.

The operating loop, in one picture

Pick your lane. The stages are the same.

At Intake you choose one real workflow, and that choice picks your lane. The two lanes run side by side through the same four stages; every section shows both. Pick one now and this site lifts it first on every page.

Two people, same tools, twelve months apart.

Suppose two people have the same talent, the same AI tools, and the same workload. One uses AI one prompt at a time. The other builds the playbook. The gap is small in month one and structural by month twelve.

The first person gets occasional help. The second becomes progressively harder to replace, and can switch vendors tomorrow without losing the system.

The Document System

The vault is the asset

The program’s central material promise: the vault is the asset; the agent is rented.

Everything the interviews produce lives as plain markdown files that you own, in a folder you control, backed by private version control (git or equivalent), readable by any AI tool. Claude, ChatGPT, Gemini, Obsidian, a future tool that doesn’t exist yet, the files do not care. Printed copies are renderings of the vault, never the source of truth. If every AI vendor disappeared tomorrow, you would still hold your entire operating system in a format humans have read for decades.

This is the anti-lock-in design, stated inside the front cover of the printed set:

Everything in this binder exists as plain markdown files you own, version-controlled, readable by any AI tool. The vault is the asset; the agent is rented.

The complete checklist, what a graduate holds

A Frontier Operator graduate holds 24 documents: 15 canonical one-pagers, 8 supporting records, and 1 graduation set. (Starter and Intermediate graduates hold the relevant subset, see the level table.)

The one-page rule

Every canonical document fits on one page. Every canonical page carries four items in its metadata bar: owner, review date, version, and source interview. Where relevant, it also carries a “Never do” block at the top, stated negative constraints outperform implied ones.

The rule is not aesthetic. Documents that don’t fit on a page don’t get run. Depth is allowed, appendices, logs, full registers, but it lives behind the canonical page, in the working tier of the vault. The canonical set is what gets printed, reviewed, and shown. The 15 canonical pages are the operating surface; everything else is storage.

A standing diagnostic keeps the system honest: for each document, ask “What decision or output did this serve in the last 30 days?” A document with no answer gets archived, not maintained. The system’s greatest enemy is its own complexity, and the budgets are how we fight it: canonical pages ≤ 1 page; auto-loaded instruction files ≤ 200 lines; newly systematized habits ≤ 2 per review period.

File naming and portability

We recommend the converged plain-markdown naming convention, SOUL.md, USER.md, AGENTS.md, MEMORY.md, SOURCES.md, TASKS.md, SECURITY.md, HEARTBEAT.md, plus memory/YYYY-MM-DD.md daily logs, with Cypress Command’s friendly titles inside each document.

Rationale: instant legibility (these names are becoming the shared vocabulary of the personal-AI ecosystem, any modern tool recognizes them on sight); portability (the names are what assistants already look for, which makes the second-model portability test nearly trivial); and zero lock-in (plain markdown in standard locations survives every tool switch, price change, and vendor failure).

When to deviate: if the file names intimidate a non-technical participant, treat them as plumbing, keep the friendly title (“How I operate”) as the document’s visible heading and let the file name stay boring underneath. Do not deviate on structure: merging canonical pages into one mega-file, or moving canonical content into a proprietary tool’s database, is how vaults quietly become hostages.

Where documents live

• Working tier (the vault): the full markdown tree, appendices, logs, versions, daily memory, digital, version-controlled, portable. Source of truth.
• Canonical tier (the field guide): the 15 one-pagers, printed and bound, with write-in space. The physical graduation set; the object on the desk. Print is a rendering of the vault, re-renderable at any review.

The Foundation Protocols

The ten interviews build capabilities in sequence. Seven cross-cutting systems run underneath all of them. They are introduced here because Part II references them constantly.

6a. Module 0, Readiness Baseline

Before the first build interview, the participant completes a short self-assessment, ten minutes, run inside the workflow intake. It produces two things: a six-dimension radar score and a named binding constraint, the single dimension most limiting the participant’s results right now. The radar is scored again at graduation and at the day-90/180 reviews, which is what turns “the program helped” into a before/after picture.

The six dimensions and their indicators (0–4 scale each, where 0 = absent and 4 = operating reliably under test):

Scores are marked self-report unless interview evidence confirms them. The verdict is capped if Governance is weak, the same gating logic the security baseline applies at Expert. Scores are compared against this stated standard, never against invented peer benchmarks.

Confidence note: the radar format and gating logic are well-evidenced in the research behind this program. These specific six dimensions and eighteen indicators are a design proposal, calibrated for personal scale. They will be revised as cohort data accumulates. Treat the numbers as a mirror, not a rank.

6b. Session Protocol, the boot sequence

The single most repeated high-value pattern in practitioner systems: every AI session has a defined start and a defined end. Without it, captured inputs and stored memory have no consumer, they pile up.

BOOT (start of every working session):

1. Read identity: SOUL.md / persona and tone file.
2. Read user context: USER.md / the “How I operate” page.
3. Read recent memory: today’s and yesterday’s daily log, plus any flagged items.
4. Check the capture queue and open loops.
5. State the session’s task against the current-quarter page.

SHUTDOWN (end of every session):

1. Write a session summary to the daily log.
2. Record decisions made, with reasons, as proposed memory.
3. List open loops and next actions.
4. Log any failure or correction for the evidence log.

The protocol is installed at Intermediate (it needs capture and memory to exist) and becomes a required section of every bounded operator brief at Expert.

The weekly review is the standing ritual that consumes what the protocol collects. Five steps, twenty minutes, same time each week: summarize the week’s logs; review open loops; flag stale projects and stale sources; set next week’s priorities against the quarter page; write the review note to the vault. It begins at Intermediate and runs for the life of the system.

6c. Memory Hygiene

Markdown memory fails in predictable ways: old decisions treated as current, related material treated as an answer, contradictions accumulating silently, and auto-loaded files bloating until the model stops attending to them. The hygiene rules are the fix:

• Daily logs are the landing zone. Everything captured during sessions lands in memory/YYYY-MM-DD.md. Raw material lives there.
• Curated promotion. Entries graduate to durable MEMORY.md only through a human-confirmed promotion step, verified lessons and decisions, not everything that happened. Durable memory stays ≤ 200 lines.
• Validity metadata. Durable entries carry valid_from and, where relevant, valid_until and superseded_by. Superseded values are preserved as history, never silently overwritten.
• Contradiction audit. Monthly (and a standing agenda item at every operating review): scan durable memory for entries that conflict; resolve or expire them.
• Quarantine rule: agents read, humans write. AI working outputs, drafts, plans, summaries, live in a separate area from accepted human knowledge. Nothing AI-generated enters durable memory without human confirmation.

6d. Security Baseline, gating at Expert

Enterprise frameworks treat access hygiene as non-negotiable; the entire personal-AI category skips it. This program does not. The Security Baseline module has four parts:

1. Credential & API-key inventory. Every account, key, and connected tool the AI system touches: where the credential lives, who else holds it, when it was last rotated.
2. Least-privilege audit. Each tool and agent holds the narrowest sufficient access, nothing more, reviewed on a cadence.
3. Data classification. Sources and content sorted into sensitivity tiers, with a written “may never be pasted into an AI tool” list and retention rules.
4. Kill-switch / incident procedure. One paragraph, drilled: disable the agent, assess what it already did, roll back, notify. Tested live at Expert graduation, not described theoretically.

The module is gating. A participant cannot graduate Expert while any protected action lacks a real enforcement mechanism or a human gate, while the credential inventory is incomplete, or while the kill switch has never been drilled. This is not severity for its own sake: a bounded operator without an enforceable boundary is a liability with a run log.

6e. The Measurement Spine

The program’s measurement discipline rests on one artifact: the evidence log. One entry after every real use, date, workflow, artifact version, intended use, result, accepted-or-corrected, review time, errors, boundary issues, correction made, retest date, next use. Small enough to keep, complete enough to prove.

The metrics that matter, tracked baseline-vs-current from the intake forward:

• Repeated explanations eliminated, how many times per week you re-tell the AI something it should already know. Target: approaching zero.
• Hours returned, baseline effort per workflow (recorded at intake) vs. current effort.
• Review time, what it actually costs to check AI output, per artifact, trending down as procedures improve.
• Accepted-output rate, share of AI outputs accepted without material correction.
• Stale-source errors, incidents of the AI using an outdated record. Should fall to zero and stay there.
• Cost per workflow, total operating cost (tools, time, review) vs. value returned.

Review rules, kept from v1 because they are the spine’s vertebrae: a template is not evidence. A passed test is not the same as real use. Real use is not the same as continued reliance. A failure counts if it is recorded and used to improve the system. The program publishes its own standard: usage and reliance at 180 days, not completion certificates.

6f. The Reinforcement Runway

The highest-stakes fact in the training research: without reinforcement, most of what a program teaches is gone within a week, and less than half survives to six months. Habits take a median of about 66 days to become automatic. A ten-interview program spread over 12–14 weeks is already a habit-formation intervention by accident. The runway makes it one on purpose. Touchpoints are calendared during intake, before the first build interview:

Every touchpoint ends with the next one calendared. This runway is the program’s signature differentiator, and we name it as such: we stay until it’s a habit. Report-and-leave is the standard complaint about every adjacent category, courses, consultants, audits. The runway is the refusal.

6g. Graduation & the Executive Summary

Every level ends with a graduation, not an administrative stop. The remembered experience of a program is its peak and its ending, so both are designed.

The graduation ceremony, per level:

• Starter: the printed “How I operate” one-pager handed over, and the first real run shown completed in the evidence log.
• Intermediate: the day-30 mini-review, the system remembered, captured, and held the line for a month, and the record proves it.
• Expert: the kill-switch drill performed live, the backup restored to a separate location, the bounded operator’s run log reviewed.
• Frontier Operator: the full ceremony, the bound canonical field guide (15 one-pagers, write-in space), the completion map (every capability with its test evidence and dates), the before/after radar against the Module 0 baseline, the agent registry, and the day-66/90/180 reviews already on the calendar.

The executive summary is a one-page artifact addressed to whoever paid, a boss, a board, a spouse, a partner. In plain language: what was installed, what passed its tests, measured baselines vs. current, what it costs to run, and what happens in the next 90 days. It is produced at graduation and refreshed at every operating review. The payer and the participant are often different people; programs that produce only personal artifacts get quietly defunded. This page is the antidote.

The binder moment. The ceremony peaks when the participant holds the printed set, a system built in conversation, tested against reality, portable to any AI tool. The certificate, where offered, is framed as earned and as one artifact among several. The working system is the credential.

Implementation Intentions

Documents do not change behavior; triggered plans do. The strongest evidence-backed bridge between an artifact and its use is the implementation intention, a written if-then plan, rehearsed at least once. The effect across hundreds of studies is large; the cost is two sentences.

The rule: every artifact in this program ends with a written if-then plan in the form:

“When [trigger], I will [use this artifact in this way].”

Examples:

• “When I open my laptop on Monday morning, I will run the boot sequence before my first task.”
• “When a client request arrives by email, I will capture it through the intake route before replying.”
• “When an AI output touches a protected action, I will stop and check the action matrix before approving anything.”

Each plan is written in the participant’s own words, attached to the artifact it activates, and rehearsed once in-session, one imagined run of the trigger, spoken or typed, before the interview closes. Rehearsal is not garnish; the evidence says it is where much of the effect lives.

Part II applies this rule at the end of every interview. This section is the only explanation it will get: the rule is stated once, here, and enforced everywhere.

What We Deliberately Don't Do

The refuse list is part of the product. Each refusal corresponds to a documented failure mode in the market.

No tool-of-the-month training. Tool-specific tactics and prompt tricks have a shelf life of months. We install an operating system that survives the tools, and we test that survival explicitly.

No automation before proof. Nothing is automated until a workflow has run assisted, passed its tests, logged real cycles, and justified the switch with numbers. A documented decision to remain assisted is a valid, respected outcome, in writing.

No binder-without-cadence. A document set without scheduled reviews and a reinforcement runway is a deliverable, not a system. We do not deliver and disappear. The reviews are part of the product, calendared before the first build interview.

No generic flattery documents. Every material claim in every artifact traces to something the participant said, decided, or demonstrated. Every profile document contains at least one unflattering, concrete finding. If a paragraph could describe anyone, it is deleted or grounded. Polished-but-empty is the market’s most rewarded failure mode; we refuse it by rule.

No invented benchmarks and no single magic score. Readiness is a radar against a stated standard, never a number against fabricated peer averages.

No lock-in. No proprietary formats, no access-revocation mechanics, no artifacts hostage to a subscription. You can leave with everything, in plain markdown, on day one.

No sprint compression. We will not install “the whole OS in a weekend.” The program’s length is its scientific asset. One capability at a time, tested before the next.

Why now rather than later.

1. Every unmanaged task loses its learning. Complete a task without capturing the prompt, the context, and the correction, and most of what you learned is gone. The tenth occurrence is easy only if the first was recorded.
2. The valuable part takes time. The advantage is not the chatbot. It is your context, your workflows, your examples, your standards, your evidence log. Starting later means starting the accumulation later.
3. Tools change. Foundations do not. A task inventory, reusable instructions, documented procedures, curated knowledge, and a safety policy survive every tool switch. A person who waits for the final tool keeps resetting.
4. Early repetition builds judgment. Knowing what to delegate, what to verify, and where AI is unreliable comes from supervised practice, and practice is cheaper before the work is high-stakes.
5. Casual use is about to stop counting. The expectation shifts from using AI to documenting workflows, holding quality controls, and handling data responsibly. The playbook is that standard.
6. Bad habits harden. Pasting confidential data anywhere, accepting unverified claims, hiding AI involvement. Easier to prevent now than to fix after a serious mistake.
7. The cost starts today. Every week of waiting is a week of recurring work that could have been reduced, delegated, or redesigned.

Want it built with you?

The free audit is the only door. Start