Working Theory · Rachel McBride

← Working frames

A verifiable core for one

The Verifiable Core is a design principle for firms. This is that same principle, run for one person: me.

All of the firm-scale ideas apply. I work every day from a small set of files: who I am, how I write, the IP, the live state of a dozen projects. The broader system answers one question: how to give the machine enough of the right context to be useful, without drowning it in everything.

I've written elsewhere about the Verifiable Core: raw at the core, intelligence on top, the human owning both ends. My own record is the core, owned and curated and checkable. The AI is the intelligence layer over it, swappable, holding no irreplaceable state of its own. I own both ends: what goes in, and what gets acted on.

This is tool-agnostic. The same structure runs through both Codex and Claude Code, different projects on each.

The structure

The owned core

My OS live

Two tiers: a small always-loaded identity layer, and a deeper load-on-demand context layer.

A handful of files load every session: who I am, how I write, what I won't write, what's protected, what I refuse. A larger set the system pulls in only when the task calls for it: the IP, project state, the people. The always-loaded part stays short on purpose, because everything in it is a tax on every answer. This is the core the rest of the system sits on. It's mine, and portable, which is exactly what lets the tool over it be swappable.

The rule: separate always-loaded from load-on-demand. If a fact doesn't change most answers, it doesn't belong in the part that loads every time.
The split

Work and life live

One core underneath, split into a root for work and a root for the rest of life.

I don't run a second system for the parts of life outside work. There's one core, with a personal structure sitting under it that covers anything that isn't work. A rule keeps the two apart, so what's in the personal side stays out of what I publish or send from work.

The rule: split the core by domain. The wall between work and life is a rule the system runs, not a second account.
The reflexes

Three hooks live

Scripts the system runs on its own, every time, without being told.

One loads the right context at the start of a session. One reflects at the end: it scans for anything durable, files it, and commits the day's changes to the core's own history. The third stands at the boundary: it refuses to push my private OS anywhere, and it stops to ask before anything goes public, so I commit and only I publish. Two of them make the system learn. The third keeps the human owning both ends, and makes that a rule the machine runs, not a thing I have to remember.

The rule: anything that has to happen every time is a reflex, not a reminder.
On-demand expertise

My skill library live

Around a dozen procedures that load only when their task comes up.

How I draft an email, scope a proposal, design a teaching session, write a thesis piece, plan a day, run an admin audit. My voice and my methods, packaged. None of it clutters an ordinary conversation. Each appears when its task does and stays out of the way otherwise, so the expertise is there without being weight.

The rule: package recurring expertise as on-demand procedures, not as more text in the part that always loads.
The specialists

My agent library live

Separate instances I call by hand for specific jobs.

A reviewer that checks anything before it ships. A sparring partner that stress-tests a decision. A financial view. A panel that vets a claim for rigour before I build on it. A researcher that synthesises and fact-checks. A flat library: I orchestrate them, no router sits between me and them. Each declares what it is (reviewer, sparring partner, verifier) before what it does.

The rule: keep specialists flat and human-orchestrated. A router optimises for throughput; judgement work optimises for not losing the judgement.
The journal

My capture layer live

A daily note and a running log, plus a signal inbox and a jobs list.

The reflexes need something real to reflect on. Through the day, observations, decisions and loose ends land in a journal and a small set of inboxes. Nothing durable is left to live only inside a chat that disappears. This is the raw material the end-of-session reflection reads, and the reason the system gets sharper over time instead of starting fresh each morning.

The rule: give the loop something real to reflect on. A system that learns needs a record to learn from.
Where the work lives

My connections live

Notion, mail and calendar, the books, the domains, the live sites.

The links that let the system reach where the work already is, so it isn't working blind from a copy. I wired these last, not first. A connection amplifies a good setup and amplifies a bad one just as fast, so the core and the reflexes had to be right before any of it went in.

The rule: wire to where the work lives, but last, not first.
The artefact

Websites, not documents live

What the system produces comes out as a site, routed by who should see it.

The default output isn't a file in someone's inbox. It's a page: owned, addressable, version-stamped, routed by sensitivity from fully public down to gated. The thinking stays in chat; the artefact lands on a site I control. This page is an instance of it.

The rule: the artefact is owned and addressable, not a document that gets lost in a thread.
Keeping it true

Overwrite on canonise live

When something sharpens, I overwrite the live source instead of stacking a new copy on the old.

The core is under version control, so when a fact changes I rewrite the one true file and let the history hold what it used to say. There's never a stale second copy left quietly steering the work. It's the same move the frontier AI tools make when they read the live source instead of a frozen index, turned on myself: work from what's true now, not a copy of how things used to be.

The rule: canonise by overwriting, not stacking. One live source, history for provenance, no stale copy.
The handover

"Rowan Starter" seed

The lean-core pattern, the reflexes, and a setup skill, packaged to pass on.

A version of the structure someone else can inherit on day one: the shape of the method, not my personal voice skills. I see it as version one. I believe this is how we collectively get better, by building our own basics, comparing them, and lifting what works from someone else's. Very much in development. Take it, free and in the open →

The rule: when a setup works, package it. Tribal knowledge doesn't scale; a plugin does.

Where to start

Copy this page into any AI and it scores your setup against the nine checks below and tells you what to build first.

Then paste it into Claude, ChatGPT, or whatever you use, and hit send.

1. Two-tier core. A small always-loaded identity layer, separate from a deeper load-on-demand layer, with the always-loaded part kept genuinely lean?

2. Domain split. One core covering everything, with your domains (work, life) walled by a rule rather than fragmented across separate systems?

3. Reflexes. A start hook that loads context, a reflect hook that files what's durable, and a boundary guard that asks before anything publishes?

4. Skill library. Your recurring moves packaged as on-demand procedures, not retyped each time or stuffed into what always loads?

5. Agent library. Specialists as separate instances you call by hand, flat, with no router sitting between you and them?

6. Capture layer. A journal the reflexes reflect on, so nothing durable lives only inside a chat that disappears?

7. Connections. Wired to where the work already lives, and wired last, after the core was right?

8. Artefact. Output landing as owned, addressable, version-stamped pages rather than files in an inbox?

9. Canonise. When a fact sharpens, you overwrite the one live source and leave no stale second copy?

The tenth check isn't here, because nobody's finished it: the discipline of the core itself.

Prefer to start from a working scaffold? The free Rowan Starter kit bundles the lean core and the reflexes as a Claude Code plugin.

As of

Last true: 4 July 2026

v2.7 · One-click on-ramp: added a "Copy this page for your AI" button at Where-to-start. It copies the page (with a short instruction preamble) straight to the clipboard, so the starting move is copy → paste, not "find the Markdown link, select all, copy". Removes the plugin as a prerequisite to begin. v2.6 · Removed the "open edge" closer; page now ends on the checklist and the scaffold line (contact stays in the footer). v2.5 · Rewrote the intro to lead flat-declarative ("All of the firm-scale ideas apply"), with the firms→one-person framing now carried by the subtitle; intro is tool-agnostic and a paragraph shorter. Cut the four-step "Where to start" list: the self-evaluation is now the single starting move (paste the Markdown, get scored, your own AI tells you the next rung). Rowan Starter trimmed to a one-line scaffold option; page now closes on the open edge. v2.4 · Promoted the Markdown self-audit as the lead way in: paste the page into your own AI, score against the nine checks, no install needed. The Rowan Starter kit is now the secondary "if you'd rather start from a scaffold" path. Removed the frontier-tools convergence call-out box. v2.3 · Added "Evaluate your own setup": a nine-check rubric, so the page and its Markdown twin double as a self-audit, not just a description. v2.2 · Added "The split · work and life": one core, partitioned into work and life roots, walled by a rule rather than a second account. Install line now points to the plugin-install commands, not "drop it into your terminal". Rowan Starter links repointed to its new ip. home (moved off share.). v2.1 · Tightened: dropped the agent count, folded the live-source point into the convergence call-out and cut its heading, trimmed the where-to-start and open-edge closers. v2.0 · Rebuilt to describe my own operating structure rather than translate an engineering guide. Now reflects the full system: three hooks (the third a boundary guard), five agents, the capture/journal layer the reflexes run on, and websites-as-artefacts as the output. Tool-agnostic across Codex and Claude Code. The convergence point (frontier tools independently landing on the Verifiable Core) kept and reframed off the tool reference. v1.1 · Voice pass: cut the borrowed-superlative and false-emphasis lines (now on the writing blacklist). v1.0 · First public version, adapted from a private working note shared with peers.