Profile the person and the machine
We inventory the work, accounts, storage, source systems, recovery needs, and the level of support the operator actually wants.
Notion OS for a new machine
Lose the machine. Keep the way you work.
Machine Hydrate rebuilds a founder's working environment from a clean, versioned baseline: tools, skills, repositories, Notion, backups, and a recovery path that is tested before it is trusted.
What transfers
The operating method, not someone else's life.
Rules, skills, setup recipes, folder conventions, agent instructions, and validation can travel. Personal files, secrets, absolute paths, tenant IDs, paid-account assumptions, and invisible dependencies cannot.
Identity
Your Apple, GitHub, Notion, storage, and AI accounts.
Data
Your business context stays in your workspace and approved storage.
Secrets
Your vault and device keychain. Never committed to the baseline.
Exit
Export, restore, update, or remove Tolowa access without breaking the system.
One URL to begin
The page can be the intake document.
Point a compatible agent at the canonical ingest URL. It receives the safety boundaries, discovery questions, Machine Profile schema, approval gates, acceptance tests, and completion contract before it is allowed to change the Mac.
Agent ingest
pilot-0.2 · pre-release
https://tolowastudio.com/machine-hydrate/ingest
Read
Agent loads the current safety and intake contract, and refuses a version it does not expect.
Profile
Agent asks the recovery questions and produces a data-free Machine Profile. An unanswered question blocks the build rather than being defaulted.
Dry run
Agent shows every package, connection, permission, test, and rollback before applying.
Toolkit
You clone github.com/tolowa-studio/machine-hydrate (private — access by arrangement), run the intake, and the generator builds YOUR payload on YOUR machine from YOUR answers. It scans its own output and destroys it rather than ship one carrying anyone else’s identity. Nothing tenant-specific is ever transmitted.
The hydrate sequence
A rebuild is only useful if it can be repeated.
Create a clean ownership boundary
The client creates and owns the identities, repositories, Notion workspace, vault, backups, and remote-access policy before private context is connected.
Apply the portable baseline
A generator reads the approved profile and emits the tools, rules, skills, repository conventions, and agent configuration. Tenant bindings are generated from schemas — never copied — and the payload is scanned before it is handed over.
Connect the operating library
Notion becomes the visible library. A local Git mirror gives agents fast, inspectable context. Neither one is allowed to become the only copy.
Prove recovery before handoff
We run a real task, revoke Tolowa access, restore from backup, test a failed dependency, and verify that the client can operate without us.
The runbook
Twelve steps, in this order.
The order is not a preference. Steps 02, 05, 07 and 09 carry hard constraints, and each one says what breaks if it moves. Everything here is what an operator and their agent actually run.
- 01
Prove what is actually lost
Before anything else
Do not confuse data missing from the new machine with data proven lost. Notion, Drive, GitHub, iCloud, email and vendor accounts survive a wipe. If the machine is still with a repair shop, ask whether it has been erased yet — a screen repair and an OS downgrade are separable, and that window closes for good.
- 02
Confirm Notion workspace ownership
HARD BLOCKER — do this second, not last
Creating a Notion integration is Workspace-Owner-only. Settings → Members. If the operator is not an Owner, every Notion step below is blocked and the profile will refuse to build. Finding this out now costs ten seconds; finding it out at step 09 costs the session.
- 03
Run the intake
Produces tenant.yml
The agent asks, one question at a time: harness, storage, mail, secrets, backup, AI accounts, projects, protected data, and the one real workflow that will prove the system. Nothing is guessed. An unanswered question stays "unresolved" and blocks the build rather than being defaulted to whatever the author happened to run.
- 04
Bring up the machine
Nothing agent-specific yet
Xcode Command Line Tools, Homebrew, node, git, gh. Then the harness the operator actually uses — Codex or Claude Code, whichever the intake said. Do not assume; the answer decides where the skills install.
- 05
Generate the payload
The gate that fails closed
The generator reads the profile, emits the skills and configuration, then scans its OWN output and destroys the payload rather than emit one carrying anyone else’s identity — including account ids, database ids and home paths that carry no brand name at all. A build that fails here is the system working.
- 06
Install skills and AGENTS.md
Skills into the harness directory the profile named. AGENTS.md is not a readme — Codex has no memory of its own, so that file IS the memory system. It is what tells the agent to read the index at session start and write facts back.
- 07
Create the memory repo, and push it
BEFORE anything writes to it
git init, first commit, create an empty private repo, push. Do this before the first agent session, not after — the whole point is that memory survives the machine. Committing is not saving. A memory that only exists on this disk is the same mistake that started this.
- 08
Make the hub page and the integration
Needs step 02 to have passed
Create one page in Notion named for the operator — “Josh OS”, not the vendor’s product name; it lives in their sidebar, among their pages. Then Settings → My integrations → New integration, and share the page with it. Export the token; never paste it into a chat.
- 09
Create the spine from schema
Dry run first
Two databases — Projects and Documents — created UNDER that one page, with Documents relating back to Projects. Both under one parent on purpose: Notion breaks a relation pointing outside the shared tree when a page is duplicated, and keeping them together is what lets this shape be handed to the next person in one click. The ids are generated in the operator’s workspace. None are copied.
- 10
Mirror Notion locally
One-way, always
The mirror gives the agent instant offline recall and gives the operator a second copy of the one asset that survived. Notion stays the source of truth; the mirror is overwritten on every run. It lives inside the git-backed memory repo, so the backup is a side effect of the design rather than a chore.
- 11
Do the one real workflow
Not a demo
The thing the intake named — a live deal, a real deadline, a real deliverable. A demo proves nothing and the operator will know it. This is the step that decides whether any of the previous ten mattered.
- 12
Prove the exit
The completion event IS the revocation event
Restore a real folder from backup, break a dependency on purpose and confirm the failure is loud, then revoke Tolowa access and have the operator repeat the workflow alone. The hydrate is not done when it works. It is done when it works without us.
Step 12 is the one that matters. The hydrate is not done when it works — it is done when it works without us.
Proof before handoff
The demo is not the test. Recovery is the test.
A successful install proves almost nothing. The pilot passes only when the environment survives failure, revocation, update rollback, and restoration on a second clean system.
Unknown and ambiguous health signals fail closed
Clean-room install
A fresh Mac reaches the declared state from the generated payload and one client-owned profile. Not yet run on a clean machine — this gate is open.
No private residue
A build gate scans the generated payload and destroys it rather than ship one carrying Tolowa credentials, tenant IDs, personal paths, or client data — including identity-shaped values that carry no brand name and that a keyword search cannot see.
Agent containment
A hostile test skill cannot read protected credentials or publish data outside its approved scope.
Notion disconnect
The local method and runbooks remain usable when Notion is unavailable; writes fail visibly and safely.
Recovery drill
A selected business folder and the machine profile are restored onto a separate clean environment.
Owner detachment
Tolowa access is revoked and the client completes the first real workflow independently.
What this is not
No magic. No borrowed brain. No permanent tether.
This is configuration, operating knowledge, access control, and recovery engineering. It will not recover files that were never backed up, replace the owner's judgment, or make unreliable third-party services reliable.
The promise is a head start with an exit ramp.
If the client cannot understand ownership, restore the work, revoke support, and continue without Tolowa, the hydrate is not complete.
FAQ
Is this a copy of Jeramey’s computer?
No. A personal machine contains private data, credentials, paths, and years of accidental coupling. Machine Hydrate starts from a sanitized method layer and generates client-owned configuration at install time.
Does Tolowa manage the computer forever?
No. The default handoff removes Tolowa access. Optional support uses explicit, revocable access with a written scope and an audit trail.
Does it require Notion?
The first release is Notion-centered because that is the visible operating library we are testing. The manifest, local mirror, backups, and exports are designed so Notion is not the only copy or the only recovery path.
Can it restore a lost machine automatically?
It can rebuild the declared environment and reconnect approved sources. It cannot recover files that were never backed up. The system is not accepted until a real backup and restore drill passes.
Design-partner pilot
Start with one real machine and one real recovery drill.
We are proving the baseline with a founder who already runs his world in Notion. General availability comes after the clean-room and detachment gates pass.