# The Home System > [!abstract] What this note is > There is a second vault. It is private and it stays private — it holds client work, contact details and money. This note describes its **shape**: how a working life is organised across one admin vault and many project repositories, and what that arrangement got right and wrong. The structure is the transferable part; the contents are nobody's business. ## The problem An assistant that forgets everything between conversations is a stranger every morning. You re-explain the clients, the deadlines, the history of an argument, who owes whom a reply. The re-explaining costs more than the help is worth. So the fix is not a better conversation. It is **a place that remembers**, structured well enough that a fresh reader — human or otherwise — can pick it up cold. ## Two layers **Durable facts** live one-per-file: one person, one project, one standing instruction. Each carries YAML frontmatter (`name`, `description`, a `type` of user / feedback / project / reference) and earns exactly one line in an index note that gets read at the start of every session. Atomic, boring, and stable. **Working documents** are the human-readable surface: today's page, the outbox of drafts, prep sheets, the cross-client board. > [!warning] The mistake worth copying down > The original design said the working documents were *generated views* of the durable facts — regenerable, disposable, safe to overwrite. **They never were.** No generator was ever written. Every one of those documents was typed by hand, and one of them was the only copy of a dozen unsent drafts. A design note describing a pipeline that doesn't exist is worse than no note, because it licenses destructive advice. > > If a document says something is generated, go and find the generator before you believe it. ## Hub and spoke One admin vault at the centre. Many project repositories around it, each with its own working context. ```mermaid flowchart TB subgraph PRIVATE ["Private"] direction LR F[("Durable facts")] H["Admin vault"] F <--> H end subgraph WORK ["Project repositories"] direction LR A["Project"] B["Project"] C["Project"] end H -- "handoff brief" --> WORK WORK -- "end-of-day report" --> H H -. "architecture only" .-> G{{"deny-list check"}} G -. "pass" .-> P["Public vault"] ``` Durable facts are one-per-file; the admin vault holds a single entry note. Two loops and one boundary — the loops carry everything, and the boundary lets almost nothing through: structure, never contents, and never without a check. - **Outbound**, the hub writes a *handoff* — a brief that gives a project session the background it needs. - **Inbound**, each project keeps a single end-of-day file at its root. One small shell command walks the list of projects, copies each of those files into the hub with the date in the filename, and appends that repo's commits since midnight. The result is that the hub always knows what every project said about itself last, without anyone summarising anything twice. A second command opens a session directly inside any project by name, so the two directions stay cheap. The important property is not the tooling. It is that **each project reports in its own words, and the hub never paraphrases**. The hub's summary is always behind the project's own files — so the standing rule is to open the project's current notes before offering advice about it. Guidance written from a stale summary reads like generic filler next to a verified to-do list already sitting on disk. ## One note at the root The root of the vault holds a single note. Everything else is in a folder named for its job. That note carries **today's work at the top and a map of the vault at the bottom**. Yesterday's copy is archived to a dated folder. Links are `[[wikilinks]]`, never file paths, so the graph and the backlinks pane do the navigation work that a folder tree does badly. This came from a complaint that is worth taking seriously: a system you have to *study* is not organised, it is merely tidy. If the entry point isn't obvious in the first second, the structure has failed regardless of how correct it is. ## The rules that made it useful 1. **Administration, not development.** The hub tracks, drafts, schedules and follows up. Technical work belongs in the project workspaces. An assistant that wanders into fixing the thing instead of managing the thing stops being useful at both. 2. **Read the source before advising.** Always. 3. **Parse, don't advise.** Surface and organise what is actually there. Recommendations when asked, not by default. 4. **Draft, never send.** Nothing outbound leaves without a human sending it. 5. **Refer to dates absolutely.** Never "today", never "last week". ## Public vault, private vault These two vaults are built on the same tools and hold opposite policies, and the difference is instructive. This vault publishes to the web. Every note, every log line, every frontmatter field is future public writing, so a linter runs over it looking for anything that resembles an email address, a phone number, or a key — and treats a hit as an error that blocks a commit. The private vault is the mirror image. **Client contact details are supposed to be in it.** That is the job. Pointing the same linter at it produces dozens of errors that are all correct behaviour being flagged as failure. > [!tip] Same word, opposite implementation > For a public vault, privacy means **the data is not there**. > For a private vault, privacy means **the data is not published** — enforced at the repository boundary with ignore rules, not at the file. > > Copying a privacy tool between them without re-deriving its purpose gives you a check that is loud, useless, and eventually ignored. The same reasoning retires most of the rest of the transplant. Continuous integration on a repository with no remote guards nothing. A template-rendering script exists here only because template code runs inside the app and nowhere else — a vault without templates does not need it. Machinery is worth copying only when the constraint that produced it also travels. ## How documentation rots Three failures found in one afternoon of auditing, all of them ordinary: - **A spec that was never built.** A design document for a small viewer application, written in earnest, never started — and still linked from the entry page as *how this works* a month later. The record of the decision was worth keeping. Presenting it as description was not. - **A layout that moved.** A getting-started note whose first instruction was to open a file that had been renamed. Everything after that instruction was unreachable. - **A rule with no consumer.** A convention documented, never enforced, never read. The common thread is that none of them were wrong when written. Documentation doesn't rot by being incorrect; it rots by staying still. The cheapest defence is to keep the count of documents small enough that they can all be re-read in one sitting — one file, at the root, that says what the system is and what it deliberately does not have. ## Related - [[Claude Code Integration]] — how *this* vault works as an AI project, and the machinery the private vault deliberately skips - [[Vault Schema]] — the blueprint pattern, applied here