Build your own portable intelligence repository in a weekend

Not the whole methodology. Five folders, a status word for each file, and a habit repeated past the point where it feels pointless.

People occasionally ask what it would take to build something like this for themselves. Not Editorial Intelligence specifically — the underlying thing, a body of work that AI can retrieve from and build on instead of starting cold every session.

The honest answer is that the structure takes a weekend. The habit takes longer, and the habit is the part that actually matters. This is the version I’d build if I were starting from nothing today, stripped down to what’s load-bearing.

What you’re actually building

Why every company needs a GitHub for knowledge makes the underlying case: a body of work benefits from one source of truth, visible history, reviewed change and connection between its parts, whether or not you ever touch Git directly. The workflow should outlive the model makes the other half of it: whatever you build shouldn’t live inside ChatGPT, Claude, or whichever tool you’re using this year, because the tool is the part guaranteed to change.

So the target is narrower than “a knowledge base.” It’s somewhere durable that holds five things, structured well enough that an AI tool can read it cold and actually use it — not just search it.

The five things worth capturing

1. What you believe. Your actual working positions, not aspirations. If you don’t have any yet, this section stays thin, and that’s accurate information, not a failure.
2. What evidence supports it. The specific thing that happened, the number, the source, the conversation that changed your mind. A belief without this attached is an opinion wearing a belief’s clothes.
3. What you’re still uncertain about. The open questions. This is the section people skip and the one that makes the rest of it usable, because it tells a reader — human or AI — where not to treat your own material as settled.
4. What you’ve already decided or built. A running record, so you stop re-deciding things you decided in March.
5. What you learned from doing it. Not the plan. What actually happened when you tried it, including the parts that didn’t work.

Five folders, or five files if you’d rather start smaller: beliefs/, evidence/, questions.md, decisions.md, learning-log.md. The names don’t matter. The separation does — the moment “what I believe” and “what I’m not sure about” live in the same undifferentiated pile, you’ve rebuilt a notes app with extra steps.

Give everything a status, in three words

The single most useful convention in my own repository is also the cheapest to copy: every substantial file states whether it’s draft, working, or settled.

Draft means you’re still finding out if it’s true. Working means you use it, but you’d revise it on decent evidence. Settled means it’s held up enough that changing it should require a reason, not a mood. That’s it — three words, one line at the top of a file. It’s a smaller version of the governance my own repository runs, and the smaller version is the right size for one person.

The reason this matters more than folder structure: without it, everything you’ve ever written looks equally authoritative to whoever — or whatever — reads it next. An AI tool handed an unmarked pile of notes will cite your six-month-old guess with the same confidence as the thing you’ve tested five times. The status line is what lets it, and you, tell the difference.

The weekend, in order

1. Create the repository. GitHub if you want AI tools to work against it directly later; a plain folder with git init if you just want version history for now. The tool matters less than doing it somewhere durable and outside any single AI product.
2. Create the five things, even if four of them start almost empty.
3. Write one real belief, with real evidence, honestly. Not the impressive one — the true one. A single genuine entry is worth more than ten aspirational ones, and it gives you something to test the rest of this against.
4. Add the status line to everything you just wrote.
5. Write a short file at the root explaining how to use the repository — addressed to an AI assistant, not to you. What this place is, what the five things mean, what the status words mean, what you want help with. This is the single highest-leverage file in the whole exercise, because it’s the difference between an AI searching your notes and an AI actually working from them.
6. Test it. Open a fresh AI conversation, point it at the repository or paste in the root file plus one real entry, and ask it a genuine question you don’t know the answer to. Not “summarise this” — something closer to “does this contradict anything else in here” or “what’s the weakest evidence I have for this belief.” The first answer will probably be underwhelming. That’s expected — there’s almost nothing in there yet, and an empty repository can’t do work an empty folder couldn’t.

The part that isn’t a weekend

The structure is the easy half. What makes it worth having is a habit repeated well past the point it feels justified by what’s accumulated so far.

Mine is close to what I described in Daily OS: a durable place to capture something the moment it happens, and a standing weekly question — does this new thing extend something I already believe, correct it, turn out to be a repeat of it, or is it genuinely new? That’s a smaller version of the same test I run on this site before anything gets published, described in the Continuous publishing experiment. You don’t need the five-way version. You need to ask it at all, on a schedule you’ll actually keep.

Expect the first few weeks to feel like you’re filing things into folders nobody will ever read. That’s the cold-start problem, and there’s no way around it except through it — a repository with three weeks of entries genuinely cannot do what one with three months of entries can, and no amount of better structure closes that gap. Structure only determines whether the three months, once you have them, are usable.

The caution nobody asks for

Once this starts working, it will generate more ideas than you have time to act on. Every belief exposes a gap. Every gap suggests something worth checking. Every open question implies research you don’t have time to do. That’s not a malfunction — it’s what a working system does — but it means the bottleneck stops being ideas and starts being your own judgement about which ones are worth the time. Budget for that before you start, or the repository turns into an elaborate machine for generating your own guilt.

If this starter version holds up and you want to turn the repository into an actual multi-model workflow, the advanced companion is Build an AI editorial operating system with ChatGPT, Claude and GitHub. It includes the root operating contract, NOW.md, CURRENT-WORK.md, file schemas, model handoffs, review gates, state transitions, Git workflow, editorial tests and a bootstrap prompt you can give directly to an AI to build your own version.

If you build this and it holds up past the first month, A diary that answers back shows what it looks like once an AI is genuinely working from the accumulated context rather than filed alongside it, and The second model is not a proofreader covers what to do once one AI tool checking your own thinking isn’t enough. And if you’d rather have this built with you than build it alone, that’s what working together actually looks like.