Learning Log · Owner's Manual
The Owner's Manual for Your Second Brain
You own a system that remembers, researches, and drafts alongside you. This is how it works, why it's built the way it is, and which rules are yours to bend — in plain English, ninety seconds a section.
What you actually own
Three things, with a wall and a gate between them.
Your personal brain
Your thinking space and research engine — goals, reading, journal, everything you collect. Nothing leaves unless you deliberately send it.
Your business brain
The company's trusted knowledge: what's true, approved, and safe for the team to rely on. Things get in only by passing review.
The crew
AI agents and workflows operating over both brains. Knowing and acting are separate permissions — always.
Both brains are the same machine inside — same engine, different rules. Yours answers to you alone; the company's answers to review.
How a thought becomes knowledge
Everything you toss in follows one path — and there's a human standing at the important door.
Nothing becomes “true” silently. An AI can fetch, sort, and propose all day — only a person promotes.
That gate is why you can trust an answer from your business brain: whatever it stands on was approved by someone, on a date, with a receipt. It's also why research never vanishes — the registry remembers everything you saved, even the ideas that were rejected, so nothing gets rediscovered and re-argued six months later.
The three copies
Syncing is not backing up. Delete a file and the cloud faithfully deletes it everywhere in seconds — sync keeps every copy identical, including identically damaged.
Version control is for the brain; full-folder backup is for the body. Version control is the rewindable change history that tracks your written notes — every edit, undoable. Your big files are too large for it, so your backups are their only other copies. If one is deleted and the trash emptied, a backup is the only way back. That's the whole reason the archive exists.
And one law with no exceptions: no automatic backups until one restore has been tested and logged. First backup by hand. Pull files back out. Confirm they open. Write it down. Then automate. An untested backup is a hope with a folder icon.
The key
Your backup is locked, and there is no locksmith. Not us, not Microsoft, nobody — that's not a policy, it's how the math works. It's also exactly why nobody else can open it.
So the passphrase needs three properties at once: you can always reach it, it isn't stored inside the thing it locks, and someone you trust can reach it if you can't. That's a password manager entry with emergency access set up — created before the first backup runs.
Never a lone key file. Never on the machine being backed up. And never shared — not with us, and not typed into any AI tool, including the one helping you run this system. It's yours alone; that's the point of it.
Why files sometimes “go missing”
Some day — after a restore, or on a new computer — your system may announce it can't find your source files. Nothing is broken, and nothing is lost.
One small settings file says “on this computer, the library lives here.” It's machine-specific by design — it never travels through version history, and even a copy pulled back from a backup points at places that no longer exist. So after any move it's missing or wrong until rebuilt, which takes one command your assistant already knows.
Expected behavior. Boring cause. One-command fix. Now it will never scare you.
Defaults and laws
Every rule in your system is one of exactly two kinds — and knowing which is which tells you what you're allowed to change.
Defaults
yours to override, by choice
- Where your personal brain lives
- How often backups run
- How each type of big file is handled
- Whether personal research ever suggests business ideas
The deal: we explain the trade-off in plain English, you decide, and the decision gets written into your registry — so the system treats it as settled and stops asking.
Laws
the short list that doesn't move
- No secrets or passwords in version control, chat, or any AI tool
- No backup automation before a logged restore test
- Nothing private crosses into company knowledge without a deliberate handoff and receipt
- The passphrase is never shared
- Nothing gets deleted or overwritten without your explicit go-ahead, each time
Ask your system to break one and it will explain and offer the nearest lawful path. That's it working, not it being difficult.
It's your system. Defaults bend to you — laws are why it stays trustworthy while they do.
How to ask
Every important folder in a system we build carries a file called _PLAIN_ENGLISH.md: what this is, why it's there, what usually goes wrong, and what you're allowed to change. Your assistant is instructed to answer your questions from those files first — plain language, our voice — and to bring out the technical version only when you ask for it.
“Why won't it just schedule my backup?”
→ “Because no restore has been tested yet — the rule is proof before autopilot. It's a ten-minute fix: we run one backup by hand, pull a few files back out, log it, and then the schedule turns on.”
That's the answer you should always get: what's happening, why, and what to do — never a wall of file paths. If you ever get jargon instead, say “explain it in plain English” — and if your system can't, tell us, because that's a page this manual is missing.
This manual ships inside every system we build and is kept current with it. The rules here were learned on real builds — including the mistakes. When your system politely refuses to skip a step, somewhere behind that refusal is a day someone lost work so you don't have to.