Continuity.
What survives over time, people, and failure. Two documents that make the foundation outlive the founder being busy, absent, or gone.
The ninety-day test
Here is the question this layer answers: if you disappeared for ninety days, would the system still behave like you built it? Would anyone know which files are doctrine, who inherits decision rights, how to stop the Operator, and what must be preserved if a platform dies?
Most AI setups fail this test on day one, because everything important lives in one person's head and one vendor's chat history. Continuity moves it into files — the same plain-text files that already run the system, plus explicit rules for succession, failure, and override.
The test: would this survive the founder being gone for ninety days? Not “could someone figure it out eventually” — would it keep running correctly without archaeology?
The two documents
Document 12: Continuity & Succession
01_Identity/Continuity.md
How the foundation survives people leaving and systems failing. It lives in the Identity folder on purpose: what survives you is part of who you are.
# Continuity & Succession
## Key context that must survive
- Identity Charter
- Decision Principles
- Authority Classification
- Current Strategic Priorities
- Critical operating files
## Succession rules
- Who inherits decision rights:
- How access is transferred:
- What must be reviewed before transfer:
## Failure & override
- How the system is stopped:
- Who has final override authority:
- What gets preserved during failure:How to write it well: use names, not roles-you-hope-to-hire. “My brother gets read access and my attorney gets the override call” is a real succession rule. Then test the boring parts: does the successor actually have the passwords, and do they know the vault exists?
Document 13: Session Notes
05_Working_Memory/Session_Notes.md
Temporary working memory, kept deliberately separate from doctrine. This is the file that stops two kinds of rot: losing decisions made mid-session, and letting session chatter quietly harden into policy.
# Session Notes
*Temporary working memory only. Clear or archive
at the end of major sessions.*
## Current session
- Date:
- Primary objective:
- Key decisions made:
- Open questions:
- Items requiring human input:How to write it well: the discipline is the clearing. At the end of a significant session, anything worth keeping gets promoted into a real document at a real authority level — and the notes get archived or wiped. Working memory that never gets cleared becomes a second, contradictory source of truth.
Platform independence is continuity
The quiet failure mode this layer prevents: your entire operating context trapped inside one vendor's chat history. The Groundwork answer is structural — everything that matters is markdown in a folder you control. Any platform can load it; no platform owns it.
- The vault is the source of truth. Chat sessions are disposable; the folder is not.
- Back the folder up like it is money. It is the operating system of the business now. Versioned cloud storage plus one offline copy is enough.
- Test a cold restore once. Open a brand-new AI account, load the package, run one real task. If quality holds, you are genuinely portable — and vendor pricing changes stop being emergencies.
You are done with Layer 4 when
- Both documents exist with real names in the succession and override lines
- The named successor can actually reach the vault and knows what it is
- There is a written way to stop the Operator, and the override holder knows it
- Session Notes get cleared or archived after major sessions — promoted, not hoarded
- You have done one cold restore on a fresh platform and quality held
Next: the foundation can survive. Now prove it is working. Measurement is the difference between a system you trust and a system you hope about.