Same kernel, three very different shapes

The same eight ideas that run my power-user setup also run a system for someone who never wants to see a file path - and a knowledge base a team governs like production code. One kernel, three shapes. That is the whole thing I want to show you in this post.

Part 1 was the confession: I built the same Markdown-memory system four times by hand, swore I would not turn it into a framework, then turned it into a framework. It also gave you the split the whole thing hangs on - a kernel that never moves, and presets where that kernel meets an actual human's situation. This post is about the presets. Specifically, about how far apart two of them can sit while still running the exact same core.

First, the constant, because the whole point only lands if you trust that it really is constant. The kernel is eight invariants. I am not going to walk you through all eight - that is what the kernel folder is for - but the shape of them is: plain files you own, one boot file that is a map and not the ruleset, a layered memory, propose-before-you-write, a safety kernel you never soften, voice kept separate from style, append-only logs, and a system that gardens its own memory. Those eight do not change. Not for the non-technical person, not for the team, not for me. If something moves when the audience changes, it was never kernel - it was preset wearing a kernel's clothes. So everything interesting in this post happens in the presets, and it clusters on a small, nameable set of axes: who it is for, what it has to sync, and how strict the governance has to be. Everything else is shared.

Let me take the two ends, because the middle one - my own multi-device setup - was the whole July 25 post and I would just be repeating myself.

The person who never wants to see a file path. This is the one I built sitting next to someone who does not write code and never will. The interesting move here is not what it adds. It is what it removes. No git. No sync layer. No scratchpad split between "durable" and "fast" memory. One person on one laptop has nothing to sync and no second committer to coordinate with, so every piece of machinery that exists to solve those problems is just weight - and weight, for a non-technical user, is the thing that quietly kills the habit before it forms.

What it adds instead is an opinion about pace. There is a three-phase model - Base, then Everyday, then Build - that deliberately refuses to construct everything on day one. You get a working base, you live in it until it is a habit, and only then do you start bolting on the clever stuff. The line I keep coming back to is that a stable habit is worth more than ten features. Willingness is a resource, and you spend it once - so spend it on the habit, not on an afternoon of setup that leaves the person exhausted before the system has done a single useful thing.

Two more postures make this preset what it is. The first is that the agent never opens with a blank page. It does not ask "how would you like to organize this?" - which is a perfectly reasonable question that also happens to be paralyzing for someone who does not yet know what the options even are. It opens with a proposal, or a specific question, and lets the person react. Reacting is easy. Starting is hard. The second is a plain-language "how it works" note written for the human, not for the agent - four things they can rely on, in ordinary words: it never deletes, it moves things to a trash folder instead; it asks before changing a note you already have but creates new ones freely; it keeps a log; and all of it is just ordinary files. That note is not documentation. It is a design feature. A non-technical person who understands their own system trusts it, and a person who trusts their system actually uses it.

The team knowledge base. Now flip the move. This one is defined by everything it adds, and it earns every piece.

Here git is not an optional convenience - git is the sync. Nothing lands in the shared base by someone typing into main. A contribution goes onto a branch, becomes a pull request, runs through a validator, and gets read by a human before it merges. No self-merge. If that sounds like how you would ship code, that is the point - the base is treated like production, because a wrong fact in a shared knowledge base is not a small mess, it is a mess that quietly spreads to everyone who trusts the base.

Two more things carry this preset. Every non-trivial fact is sourced - there is a ledger of where things came from, with the date each one was ingested. And every fact carries a confidence tier. Three of them: authoritative, for official docs and artifacts; corroborated, for a claim that has a document standing behind it; and reported, for a claim that nobody has backed with a document yet. A reported fact is never allowed to wear the confidence of an authoritative one. The principle underneath all of that ceremony is a one-way street, and it is the sentence I would keep if I had to throw the rest away: a flagged gap is a contribution, a confident wrong answer is a liability. An agent that says "I could not source this, so I am marking it reported and flagging it in the pull request" did its job well. An agent that smoothed over the gap with a confident guess damaged the base, even if it happened to be right. This preset is barely an assistant at all - it is closer to a library, and more often than not it gets read by a power-user setup querying it as a read-only source.

So: one preset earns its keep by taking machinery out, the other by putting machinery in. Which brings me to the rule that keeps the whole thing honest, and it is almost embarrassingly simple. A preset carries only what its situation needs. That is it. Do not import the sourcing ledger into the solo system "to be safe." Do not skip the pull-request flow on the team base because it feels heavy. Unused machinery is not a safety margin - it is friction, and friction is what talks people out of keeping the system at all. You add the scratchpad the day you get the second device. You add sourcing the day you have a fact that genuinely has to be sourced. Not before. The three axes that actually differ are audience, sync scope, and governance strictness. Everything else was the kernel the whole time.

The usual caveat still stands from Part 1: this is a playground, not a product to swallow whole. The value is in seeing three worked examples, not in copying one of them and hoping it fits a life it was not shaped for.

Next in the series: the installer - how you get from an empty folder to working memory in roughly one prompt, without having to understand any of this first.

Markdown Mind Part Two