--- title: A verifiable core for one subtitle: The Verifiable Core is a design principle for firms. This is that same principle, run for one person: me. author: Rachel McBride collection: Working Theory source: https://ip.rowanadvisory.co.nz/verifiable-core-for-one/ version: v2.7 · 4 Jul 2026 as_of: 4 July 2026 --- # 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** ([ip.rowanadvisory.co.nz/verifiable-core/](https://ip.rowanadvisory.co.nz/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: [Rowan Starter](https://ip.rowanadvisory.co.nz/rowan-starter/). > **The rule:** when a setup works, package it. Tribal knowledge doesn't scale; a plugin does. ## Where to start Take this page as Markdown, paste it into your own AI, and ask it to score your setup against the nine checks below: where you sit on each, and what to build next. No install, no kit, whatever tool you already use. The evaluation is the starting move; your own AI tells you the next rung. 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](https://ip.rowanadvisory.co.nz/rowan-starter/) bundles the lean core and the reflexes as a Claude Code plugin. --- *A working frame on running the Verifiable Core at the scale of one person. The frames are mine; the thinking's in the open. Lift any of it. Get in touch: [rachel@rowanadvisory.co.nz](mailto:rachel@rowanadvisory.co.nz).* --- *Working Theory · v2.7 · 4 Jul 2026 · ip.rowanadvisory.co.nz/verifiable-core-for-one/*