Field notes · build log 01
The git-backed system of record.
The essays on this estate argue that a knowledge operation should be governed, inspectable, and boring. Arguing is cheap. This is the first of three build logs walking through the system I actually run — starting with the record itself. Every exhibit below is real: real files, real commits, real screenshots, one redaction.
Why the record is a git repository
The operating model puts one requirement above the rest: nothing probabilistic writes to the record ungated. That sentence, taken seriously, is a systems specification. The record must be plain files a human can read, every change must be attributable to an actor and a moment, and the whole history must survive any particular tool dying. That is a description of a version-controlled repository.
So my system of record — the reference implementation of the framework, running as a subsystem of a home-lab agent stack on a Raspberry Pi 5 called the-bakery — is a git repository. Its README states the contract:
"This repository is the system of record: a git-backed store of human-validated knowledge objects. The AI layer … is disposable; this repo is not."
The AI layer — a vector projection of the store plus routed model calls — can be deleted and rebuilt from the repo at any time. The reverse is not true, and that asymmetry is the whole design.
One object, end to end
Here is a real knowledge object from the store, exactly as it lives on disk — front matter, then body. The only edit for publication is the source: identifier, masked because it points into a private workspace.
--- id: KO-000029 type: note title: "Ontology vs Taxonomy" domain: knowledge-ops status: validated owner: owner volatility: evergreen version: 1 created: 2026-08-14 last_validated: 2026-08-14 source: forest-import:<notion-page-id> confidence: 0.5 tags: [knowledge-management] ---
## Context Both ontology and taxonomy are used to organize knowledge, but they differ in their structure and expressiveness. ## Insight Taxonomy is hierarchical, organizing knowledge into parent-child relationships. Ontology, on the other hand, defines entities, properties, and relationships between them. ## Implication (not recorded in the original note)
Two details carry the doctrine. The front matter is machine addressing — status, volatility, freshness dates, a confidence score the retrieval layer can filter on. And the last line is a small act of honesty: the system records what it knows it doesn't know, rather than letting a model invent an implication later.
Because the record is git, the object's provenance is not a claim — it's a query:
$ git log --oneline --follow -- store/knowledge-ops/KO-000029.md 3e4dfcc 2026-08-14 Gate: validate KO-000029 (console) d65f6b4 2026-08-14 Forest import: 41 objects filed as drafts
Two commits. It arrived in a bulk import as a draft; a human validated it at the gate. Nothing else has ever touched it, and the repository can prove that for every object in the store.
The gate writes the history
No object enters, changes, or leaves the store by hand. The gate console — the one approval surface for everything the system captures — performs each action as a commit. Accept files a draft. Validate puts it on the record. Archive is terminal. Reject requires a reason code. The git log is therefore not documentation of the process; it is the process:
19d374a Gate: accept CAND-20260907-031058 -> KO-000167 (console) 94762e8 Gate: accept CAND-20260907-031058-2 -> KO-000163 (console) 514b84e Gate: accept CAND-20260906-031059-4 -> KO-000158 (console) 40c9f9d Gate: validate KO-000158 (console) 3f909cd Gate: validate KO-000162 (console) 7040be3 Gate: archive KO-000161 (console)
Candidate IDs carry their capture timestamps and graduate into object numbers. An accept is nothing more mysterious than a file materializing under version control:
$ git show --stat 19d374a
19d374a 2026-09-07 Gate: accept CAND-20260907-031058 -> KO-000167 (console)
store/knowledge-ops/KO-000167.md | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
The record, by the numbers
None of these figures were typed from memory; each is the output of a command against the repository, captured the night of publication:
store/build 96 objects store/craft 11 store/endpoint-support 15 (the frozen reference corpus) store/knowledge-ops 32 store/learnings 10 store/life 3 ───────────────────────────── 167 objects · 6 domains 308 commits since 2026-08-09 · 268 of them gate actions 388 capture signals logged · 8 drafts in the queue tonight (3 captured at 02:20, 5 at 03:10 — while nobody was at the keyboard)
A month of running, and the shape of the numbers is the argument: two hundred and sixty-eight of three hundred and eight commits are gate actions. The record grows almost entirely through governance, which is exactly what the doctrine asks of it.
And this is what the record is for. The disposable layer answers questions from validated knowledge only — citing the objects it drew from, scoring its own confidence against a floor, refusing below it:
the instrument this post exercises
Governance Pack — the probabilistic-write rule, ready to ratify
Four ratifiable policies with a fully-worked ratified example. The content-standards policy carries the rule this post is built on — nothing probabilistic writes to the record ungated — as text a support leader can put in front of a governance board, not a slogan.
Credited in full toward the $299 toolkit within 14 days — the same window as the refund. Written and maintained by the author of this post; dogfooded in the toolkit's own source repo. Single-organization license.
Next in the build log: the validation gate in action — what the gate checks, what a rejection looks like, and why reject codes beat silent edits. Back to the reading room.