Knowledge Inbox OS

Most people have the same problem with their own important information: it's scattered. Some in email, some in Word documents, some in PDFs, some in letters. When you need an answer — what was agreed, what's been tried, what happened when — you go digging across all of it by hand.

Over a few days I built a system that fixes that for any pile of documents you point it at. You ask it a plain-English question and it answers from your material — not generic internet advice — and shows you the source it drew from. You can also ask it to draft a message, and it writes a first version grounded in your actual history, in your own voice. It runs on my own laptop.

The part worth your attention isn't that it works. It's two decisions that shaped it: I built it to be reused across completely different sets of documents, and I designed the privacy boundary before I wrote the feature code. I then proved both by running the same system over two unrelated collections — one highly sensitive, one not — without changing a line of the core code.

I'm not a software engineer. My background is commercial and web. What follows was built by combining AI-first tooling with a working method — and the method is the real object on display.

How I worked

Four patterns drove the work. Each is named, with the proof.

Design the privacy boundary first, not last

The first collection I pointed it at was a private, highly sensitive personal archive. That made one rule non-negotiable from the start: none of that material, and nothing the system generates from it, may ever leave the laptop. Not to GitHub, not to any cloud, not anywhere.

I designed for that before building the features. Three things make it real rather than a promise:

• The private details — whose records these are, which organisations are involved — live in a single configuration file excluded from version control. The code contains none of it.
• The search index and the cleaned-up copies all sit in a local folder that is never committed. The local-only rule is enforced in code, not just by convention.
• Because the code is free of any specific personal detail, I could publish it to GitHub tomorrow and nothing private would go with it.

This is the discipline that lets the same tool be safe for sensitive material and shareable as a product. The boundary was the design, not a feature bolted on at the end.

Reuse the proven engine; build only what's genuinely new

The underlying search engine — breaking files into pieces, understanding them, ranking them against a question — already existed and was tested from an earlier build. I ported it across unchanged and spent effort only on the genuinely new layers: reading the different file formats, the read-only email connection, and the drafting step.

That's a deliberate trade. It's tempting to rebuild from scratch and feel productive. Reusing a proven component is less satisfying and far more sensible — I inherited the earlier work's measured confidence instead of starting from zero.

Connect to the source of the mess — safely

New material keeps arriving by email, and filing it is manual. So I gave the system a read-only connection to a labelled slice of my email. It can read those messages and file them in — but it physically cannot send, delete, or change anything. The access granted is read-only, by design.

The proof: in one pass it scanned a year of correspondence, worked out which threads mattered, pulled in the ones that did along with their attachments, and filed all of it into the local archive automatically — for a few pence of processing cost.

Build to be reused from day one — then actually reuse it

I built this as a module, not a one-off — configurable to point at any collection, with two storage modes designed in from the start: fully-local for sensitive material, or backed by a private repository for material that isn't.

The honest test of "reusable" is whether you can actually reuse it. So a couple of days later I pointed the exact same system at a completely different, non-sensitive pile — my own learning notes and a reference library — in the repository-backed mode. Same engine, different collection, different storage rule, no change to the core code. One build, proven across two unrelated bodies of material.

What this says about how I work

The most commercially relevant part is the privacy discipline. A lot of the genuinely useful information inside a business is sensitive — client records, contracts, correspondence, internal decisions. The reason people hesitate to put AI near it is, reasonably, that they don't trust where it goes. A system designed so the sensitive material physically cannot leave the building, where the code holds no secrets and could be shared openly, is the difference between a clever demo and something an operator would actually allow near their real information.

The two collections this one runs over are mine. The same approach can be applied to others — including the parts you'd never put in the cloud.