Humans capture, AI curates. That split is easy to agree with. What's harder to trust is the mechanism: what actually happens between a note landing in the vault and it becoming something you'd rely on.
Notes as source
Software engineers already have a working model for this. They just haven't pointed it at their own notes.
A compiler doesn't store your program. It takes source code, parses it, builds an intermediate representation, optimises it, and produces a binary you run instead of reading. Nobody keeps the binary as the record of truth, the source is. If the compiler has a bug, you fix the compiler and rebuild. You don't hand edit the binary.
The same shape applies to notes. Capture notes are the source. Extraction pulls entities out of them. Entity resolution decides which mentions refer to the same person, project, or fact. A knowledge graph holds the relationships. Derived profiles, summaries, at a glance views, get generated from the graph.
Nothing in that pipeline is precious except the source. Everything downstream can be thrown away and regenerated, the same way you'd delete a build folder without worry.
Evidence, not facts
This reframes what a "fact" is. Current understanding isn't something you wrote down once. It's a function of every piece of evidence up to now.
Current knowledge at time t equals a function of all evidence up to t. Not the last note you wrote about someone, the sum of every note you've ever written about them, reduced.
Event sourcing systems already work this way: never overwrite state, append evidence, recompute the current view whenever you need it. A database update destroys the fact that came before it. An event log keeps it and derives the present from all of it. Personal notes deserve the same treatment. The messy, chronological, contradictory version of what I wrote in March shouldn't be lost just because I wrote something cleaner in November. Both are evidence. Understanding is the reduction, not the last line.
Why git and markdown
Once evidence and derived knowledge are separate concepts, the storage format stops being a branding decision.
Git already refuses to guess. Two branches touch the same line, it stops and asks you to resolve it. It doesn't average the two versions or pick the one that looks more confident. That's the correct default for identity resolution too. If a system can't tell whether "Alex" in one note and "Alex" in another are the same person, the right move is to leave that unresolved, not to guess and quietly merge two people into one.
Markdown holds up because it's read twice, by two different readers, and neither reading dominates. A human reads the paragraph. A model reads the structure: headings, frontmatter, whatever YAML sits at the top of the file. One document, two interfaces, no format war.
Git as the database follows the same logic. History isn't a feature bolted on afterwards. It's the actual source of truth, and the working tree is just the latest compiled view of it.
Living with ambiguity
The uncomfortable part is accepting that some things stay unresolved indefinitely.
The right question is never "is this true." It's "why does the system believe this," and if the system can't answer that, it shouldn't be asserting it. Provenance replaces confidence as the thing that matters. A summary with a traceable source is trustworthy in a way a confident sounding sentence with no origin isn't.
That also means no big migration, ever. My Obsidian migration stalled partly because I treated it as an event: convert everything now, or the project stalls. Evidence based curation doesn't have a "now." It converges, note by note, for as long as the vault exists.
Open questions
I don't think this is a solved problem, and the parts I'd get wrong on a first attempt are worth naming rather than papering over.
- How conflicting evidence should actually be represented, not just tolerated
- Whether derived summaries should be editable directly, or only regenerated
- Whether provenance can fully replace an explicit confidence score, or whether both are needed
- When the system should refuse to merge two entities rather than guess
- Whether more than one AI agent can curate the same repository without one undoing the other's work
None of that stops the architecture from being worth building. It just means I'd treat it the way I'd treat any early system: useful before it's finished, and probably still shaped wrong in places I haven't hit yet.