Detailed content
🔒 Local models for sensitive data
Freedom OS handles passports, residences, birth certificates—things you no wants to run in the context of a cloud model. The author's answer is to run local models for the most sensitive domains. That's why he invested heavily in hardware before memory prices surged: analysis of private data that never leaves your machine.
🌱 New here?
One local model runs on your own computer—the data isn't sent to a third-party server. PII (personally identifiable information) is any data that identifies you: CPF, passport, address. Hardware here it's a machine with a GPU/memory powerful enough to run the model locally.
✓ Local makes sense when…
- ✓The data contains a lot of PII (documents, health, personal finances).
- ✓The leak would be irreversible.
- ✓You’re willing to invest in hardware for privacy.
✗ Don’t put it in the cloud
- ✗Birth certificate in the context of a cloud chat.
- ✗Passport in a prompt that goes up to a server.
- ✗Trust that “it won’t leak” in a scenario of constant leaks.
Why learn
Because the domain’s sensitivity determines the architecture. For most OSs, the cloud is great; for the Freedom OS, it isn’t. Knowing to choose a local model when data can’t be recovered is what separates convenience from recklessness—and protects what you can’t reissue.
Key concepts
⚖️ Closed vs. open vs. hybrid
Model choice isn’t one-size-fits-all across OSs. Some OSs mainly use models closed source (closed, in the cloud); others, local/open source; and some are hybrids — the local model handles sensitive content, the closed model does the heavy lifting on non-sensitive content. The guiding rule: the domain determines the mix.
🌱 New here?
Closed source = a proprietary model you access through a cloud API (more powerful, but the data leaves your machine). Open source = an open model you can download and run locally. Hybrid = use both depending on the task, routing sensitive data locally.
Cloud-based, powerful. For what isn't sensitive.
Runs on your machine. Stops PII and secrets.
Route sensitive work locally, everything else to the cloud.
💡 The rule of thumb
Don't ask "what's the best model?" — ask "How sensitive is this domain?". Tax OS and Freedom OS lean toward local/hybrid; Content OS and Sales OS work well in the cloud. The architecture follows the data, not the hype around this week’s model.
Why learn
Because it frees you from the “one model for everything” mindset. Each OS can take a different approach, and hybrid is often the sweet spot: you don’t give up power where you can use the cloud or privacy where the data is sacred. It’s an architecture decision, not a brand decision.
Key concepts
💾 Backup across 3 fronts
Every OS that matters has a copy in three fronts: a repository private on GitHub, one Local SSD e a cloud. The detail that protects you: a .gitignore that keeps sensitive information off GitHub — you don't upload your passport to a repository, however private it may be, especially with leaks happening all the time.
🌱 New here?
One repository (repo) is the folder versioned in Git/GitHub. Private = only you can access it. SSD is a local physical disk. The .gitignore is a file that lists what Git should ignore — what goes in it never goes up to GitHub. It’s your safety fence against uploading anything confidential.
How to read: three copies = no single failure can take you down. The .gitignore is the gate: confidential material (in red) goes to the SSD/private cloud, but never into GitHub.
Why learn
Because your OS becomes a critical asset: losing the folders means losing months of cultivation. Three fronts ensure that no single failure (a hard drive dying, an account being suspended) wipes everything out—and .gitignore ensures that redundancy doesn’t become a way for confidential information to leak.
Key concepts
🍂 Context rot — the cutoff point by domain
All context decays—but at different rates. The production question is: what goes stale fastest in this domain?. Tax law changes over months, not overnight; identity tends to be static; content trends shift in days. For each domain, you define a cutoff point: how often that context needs to be updated.
🌱 New here?
Context rot (context degradation) is the substrate aging: what was true becomes outdated. The cutoff point is the update cadence you set for each domain — like an expiration date. Without it, the OS confidently answers using old data.
How to read: the bar is the "validity" of each context. Identity hardly ever decays; a trend decays quickly. The cutoff point is where you schedule the ↻ — updating too early is wasteful; too late, and you make a confident mistake.
Why learn
Because it’s what keeps the OS reliable over time. An OS that seems smart but runs on rotten context is dangerous: it’s just as confident when it’s wrong as when it’s right. Defining the cutoff point by domain means treating maintenance as part of the design—not a post-launch detail.
Key concepts
📝 /tldr — post-session summary
The habit that makes the OS self-improving: a slash command of a post-session summary. The /tldr saves a summary of what happened e proposes updates to the CLAUDE.md and the rules over time. It’s self-improvement with a human in the loop: AI suggests the diff, but only you apply it.
🌱 New here?
One slash command is a shortcut you call by typing /nome in Claude Code — it lives as a file in .claude/commands/. O frontmatter is the header between --- with metadata. Human in the loop means the machine suggests, but the final decision is yours.
🎯 Copy-run objective
Create the slash command /tldr that, at the end of a session, generates the summary, distills nuggets, and proposes updates to the as a diff for you to approve CLAUDE.md and the rules.
--- description: Resume a sessão e propõe updates ao CLAUDE.md e às regras --- Você é o arquivista deste OS. A sessão acabou. Faça, nesta ordem: 1. RESUMO: escreva até 8 bullets do que decidimos / fizemos hoje, sem floreio. Salve em substrate/sessions/<AAAA-MM-DD>.md (o raw da sessão). 2. NUGGETS: extraia só o que tem valor durável (uma preferência minha, um fato do domínio, um atalho que funcionou) e acrescente ao substrate/compendium.md. 3. PROPOSTAS DE REGRA: se algo deu errado hoje, proponha 1 never-rule para rules/never.md e, se for inegociável, 1 reflexo (hook). NÃO edite rules/ sozinho — liste as mudanças como diff e PERGUNTE antes de aplicar. 4. CLAUDE.md: se surgiu um fato estável sobre mim ou o negócio, proponha a linha exata a adicionar / trocar — de novo, como diff para eu aprovar. 5. Nunca grave dado marcado como sensível: use um identificador, não o valor real. Termine com "onde paramos" + o próximo passo para a próxima sessão.
The parts in <...> are filled in on the spot (the date). After creating the file, run /tldr at the end of every session.
✅ How to verify
- ✓The file appeared substrate/sessions/<data>.md with the summary in bullets.
- ✓New nuggets went into the compendium.md (and only what’s durable).
- ✓The changes in rules/ e CLAUDE.md came as proposed diff, waiting for your approval — not applied on their own.
- ✓No sensitive value appears in plain text (only identifiers).
Why learn
Because it’s the engine behind the “cultivate, don’t install” philosophy. Without /tldr, what you learn in each session evaporates. With it, the OS gets better with every use—capturing preferences and correcting rules—without ever editing itself in the dark: you stay in control of what goes into the soul file.
Key concepts
⏰ Weekly synthesis cron jobs
The /tldr handles each session; the weekly cron takes care of everything. It's a scheduled task that distills all the conversations every week into synthesized nuggets — the same raw → distilled pattern that repeats across every domain, now automated. If a task runs 100% of the time without your input, it should become a cron job, not a skill.
🌱 New here?
One cron is a task that runs automatically on a schedule (e.g., every Sunday at 3 a.m.). Synthesize is summarizing raw material into a few useful nuggets. The difference from a skill: you call a skill when you want to; the cron runs on its own, without you asking.
The synthesis cycle—raw material that turns into distillate, all by itself
cron semanal (domingo, sem você pedir) │ ├── varre substrate/sessions/*.md # o raw da semana ├── destila com um modelo workhorse # barato + esperto └── grava substrate/compendium.md # só os nuggets
🔎 Skill or cron?
The test is simple: if you always runs the task the same way every time, without judgment, it's a candidate for cron (or a deterministic script). If it still depends on a decision from you each time, it stays a skill. The weekly synthesis is the classic case for cron—repetitive and requires no choices.
Why learn
Because it’s what keeps the substrate fresh without effort on your part. Conversations pile up; without synthesis, they become a dead archive no one reads. The cron turns raw history into distilled knowledge every week—the OS learns from its own use while you sleep.
Key concepts
🌱 Cultivating in production
We end where the course began: cultivate, don't install. A production OS is kept alive through daily use—you observe where it gets stuck and find the "disfluencies" (the points where the conversation gets stuck) and adjusts. Backups, context rot, /tldr, and crons aren’t one-off tasks: they’re the habits that keep the garden alive after it has grown.
The production maintenance loop
Use daily
Real use is the “trial by fire.” Only by using it do the failures surface—no desk audit will find them.
Find the disfluencies
Where did you have to explain it again? Where did the OS hesitate? Every stumble is a clue about what's missing in some layer.
Adjust and audit
Fix the right layer (the /tldr helps) and run /os-coach audit to score the OS against the goal again.
✓ Who cultivates
- ✓Go back, use it, and adjust the right layer.
- ✓Run /tldr and audit the OS against the objective.
- ✓Build an OS that gets better every month.
✗ Who installs it and disappears
- ✗Builds everything in a weekend and never comes back.
- ✗Let context rot without a cutoff point.
- ✗Trust an OS that has quietly grown outdated.
💡 The course wrap-up
You already have everything: the 6 layers, the step-by-step guide with the /os-coach, the 6 domains and now the production patterns. What's missing isn't more theory — it's cultivation. Choose a domain, build, use it, and come back to audit.
Why learn
Because it’s what separates a weekend experiment from a system you can trust for years. Production isn’t a state you reach and forget—it’s a loop of using, spotting the rough edges, adjusting, and auditing. Those who cultivate reap an OS that improves; those who install and abandon it reap one that rots.
Key concepts
🎉 You’ve reached the end
End of Track 5—and of the course:
You’ve completed all 5 tracks. Now choose a domain, build your OS, and run /os-coach audit to score it against your goal.