The first version of a second brain is a folder. The useful version is a maintenance system.
I keep the architecture simple: approved raw sources, compiled knowledge, a schema that explains the domain, and a small set of repeatable operations. The exact installer commands and supported agent clients change with releases, so the current NicholasSpisak second-brain repository is the source of truth for setup.
The setup chain
Start with the runtime you already use and verify it can read and write the target repository. Then install only the second-brain tooling documented for that runtime. Do not copy an old command from a post and assume it still matches the current release.
The generated structure should make four boundaries visible:
raw/for source material with provenance;wiki/for reviewed, compiled knowledge;- a schema or operating guide for organization rules;
- a log or inbox for new research and unresolved conflicts.
Keep the first vault small enough to inspect. Claims that setup always takes a fixed number of seconds or processes a fixed number of pages are not useful guarantees. Corpus size, source quality, model access, and review time all vary.
The four operations
Research. Collect an approved source, record its URL or file origin, date it, and preserve enough context to audit later. Research should never silently cross into private systems or bypass access controls.
Compile. Turn raw notes into structured pages. Merge duplicates, retain citations, distinguish fact from observation, and surface contradictions instead of choosing the most confident sentence.
Query. Ask questions against the compiled wiki. Good answers link back to source pages and admit when the vault does not contain enough evidence.
Maintain. Run health checks for broken links, orphaned notes, stale claims, duplicated concepts, missing provenance, and instructions that no longer match the repository.
These operations can be packaged as skills. A skill may include instructions, scripts, templates, and references. Each should define inputs, allowed paths, approval boundaries, and proof of completion.
Why focused vaults beat one giant brain
I prefer a dedicated second brain for each important domain: a business, product, client, content operation, or trading system. The boundary reduces accidental cross-contamination and makes access control understandable.
A business-operations vault may contain SOPs and decision logs. A customer-research vault may contain interviews and consent restrictions. A content vault may contain published material and positioning rules. Combining all of them into one undifferentiated folder makes retrieval noisier and permissions harder to reason about.
Focused does not mean isolated forever. A top-level index can point to the right vault without copying all of its contents.
Five practical starting points
- Your company: products, positioning, offers, processes, and decisions.
- A client: discovery, deliverables, approvals, and source evidence.
- A product: requirements, incidents, release notes, and customer feedback.
- A research domain: papers, claims, experiments, and open questions.
- Your content system: published work, source material, brand rules, and performance notes.
Choose the one where missing context currently wastes the most time.
The compounding trick
Value does not grow automatically with file count. It grows when every real project returns reviewed knowledge to the system.
After a project, I capture what changed, which assumption failed, what evidence decided the issue, and which instruction should be reused. Then I run maintenance before treating that lesson as truth.
That loop—use, review, update, verify—is the second brain. The installer only gives it somewhere to live.
