Build a memory that cites its sources
Keep useful facts organised by subject, with a source you can check for every one.
What you need
A folder for source files, somewhere to write notes by subject, and a simple list of processed files. A wiki is just a collection of linked pages. Plain documents can work too.
The method
Collect source files in a known location. Keep the originals unchanged. Read each file and extract useful facts. Flag anything uncertain instead of guessing. Organise those facts by subject, such as a person, project or client. Keep a source reference with each fact: a file link and the relevant page or passage. Record which files have been processed, including those with nothing useful to add.
Try the trail
Pick a fact in your notes. Can you open its source and find the passage that supports it? If not, the fact is not ready to rely on. You can do this by hand. Automation needs access to the files, instructions for filing and a way to record progress; a command alone does not provide that setup.
How we use it at Pitch
At Pitch, the board is our shared work log. An assistant is software that follows our instructions with access to agreed tools. A watcher checks for changes and reports them; a worker runs a configured routine. Those roles need explicit instructions, access and permissions. Context and boundaries The wiki is where the business keeps its memory: one page for every client, person and project, every fact citing the file it came from. It is how we know what a contract said without opening it again, and what our briefings and invoices read from. What stays ours is when to file and what is worth keeping; noticing new files and writing them up is done by a watcher and an assistant . The setup A folder per part of the business, each with an inbox where files arrive. The wiki itself, organised by client, person and project and written only by the assistant, with a log of every file filed. The watcher's morning check and the assistant's ingest skill. The same memory does other work: we ask it questions and get answers with their sources, the morning briefing reads its client pages, and every invoice updates one. And one design choice that makes it trustworthy: the original files are read-only and every fact cites one, so an unsourced fact is flagged instead of filed, and any page can be rebuilt from the files. Our sequence Files land in the shared folder. Each morning the watcher logs every new file as a row on the board. When we're ready, we say "ingest". The assistant reads each file and writes its facts onto the page for that client, person or project. It closes each row against the page it updated, or with a reason when the file needed nothing. The principle Every fact keeps a pointer to the file it came from. Then any page can be thrown away and rebuilt, and nobody has to trust memory. What stays with a person We still decide when to file, and we still read what matters. Noticing new files and writing up what they say stopped being ours. What it took us The folder layout and the rules came first, in writing. Filing is still started by us rather than on a schedule; running it unattended is on the list, not built. How the process began Files would land in the shared folder: contracts, statements, notes, plans. We'd notice them when we went looking. Open each one and work out which client, person or project it was about. Copy what mattered into our notes, when there was time. Months later, try to remember where a fact had come from.