1. Control surface
The desktop or local web application where you talk with the brain, inspect its work, review approvals, and see system status.
Easy Start Guide
Build Your Own Local Digital Brain
A practical guide for building a private, useful, and trustworthy AI partner around your knowledge, priorities, and rules.
Start small. Keep control. Build trust through evidence.
Why build a digital brain?
A digital brain is a private AI system designed around your work, knowledge, priorities, and rules. It helps you remember, organize, research, decide, draft, and eventually perform carefully bounded tasks. The goal is not a chatbot that knows everything. The goal is a trusted partner that knows what matters to you, shows its work, respects your limits, and remains under your control.
The central trust principle: Do not trust an AI system because it sounds confident. Trust it only to the degree that you can inspect its sources, understand its authority, observe its actions, stop it, and verify its results.
Architecture
The seven parts of a local digital brain
2. Local model
The language model performing reasoning and drafting on your device. Cloud routes, when used, should be explicit and approved.
3. Knowledge library
Your approved files, notes, policies, manuals, transcripts, and reference material.
4. Memory
A governed record of durable facts, preferences, decisions, and lessons. Memory is not the same as chat history.
5. Mission and workflow layer
The mechanism that converts a request into a bounded objective, plan, context package, work product, and outcome.
6. Tools and connectors
Optional capabilities such as file search, calendar reading, email drafting, and public-source research.
7. Trust and assurance
Identity, access limits, evidence, logs, approvals, stop controls, verification, and recovery.
Simple reference architecture
YOU
|
v
LOCAL APP / CONTROL SURFACE
|
+-- Mission definition and approval
v
LOCAL MODEL ROUTER
|
+-- Approved local model
+-- Optional approved cloud route
v
CONTEXT MANAGER
|
+-- Knowledge library
+-- Curated memory
+-- Current task context
v
WORKFLOW / TOOL LAYER
|
+-- Read-only tools first
+-- Draft actions second
+-- Approved external actions last
v
RECEIPTS, REVIEW, AND OWNER DECISION
Build sequence
The 10-step easy start build
Define one job
Pick a narrow first outcome: answer questions from your documents, draft a daily brief, or help manage one project.
Write your brain charter
State who owns the system, what it is for, what it may access, what it must never do, and which decisions remain human.
Prepare the local environment
Use an isolated workspace, full-disk encryption, current patches, least privilege, and encrypted backups.
Install one local model runtime
Record the model name, version, source, license, context window, and hardware requirements.
Install the control surface
Select an interface that supports local models, document collections, export, and visible configuration.
Create the knowledge library
Start with a small set of authoritative documents. Remove duplicates, label sensitivity, and record effective dates.
Create governed memory
Separate facts, preferences, decisions, lessons, assumptions, contradictions, and unresolved questions.
Add a mission workflow
Capture the objective, boundaries, allowed sources, expected output, risk if wrong, definition of done, and checkpoints.
Require receipts
Record the model, sources, tools, versions, omissions, recommendation, and final human decision.
Test before expanding
Run normal, wrong, ambiguous, adversarial, oversized, and unavailable-source cases before adding authority.
Foundation
Your one-page Digital Brain Charter
Complete these fields before connecting sensitive data or external tools.
| Field | Question |
|---|---|
| Owner | Who has final authority? |
| Purpose | What specific problems will it solve? |
| First use case | What is the first measurable outcome? |
| Authorized users | Who may use it? |
| Authorized data | Which folders, collections, or systems may it read? |
| Prohibited data | What must never enter the system? |
| Allowed actions | What may it do without asking? |
| Approval-required actions | What requires explicit human approval? |
| Prohibited actions | What must it never do? |
| Source standard | Which sources count as authoritative? |
| Retention | What is stored, for how long, and where? |
| Stop control | How is it immediately paused or disconnected? |
| Recovery | How are configuration, memory, and documents restored? |
| Success measure | How will you know the first release is useful and trustworthy? |
Memory
Build memory carefully
Do not blend chat history, retrieved documents, inferred preferences, and authoritative facts into one invisible memory.
Facts
Verified information with a source, owner, observed date, and confidence.
Preferences
How the owner prefers work to be performed or presented.
Decisions
What was decided, by whom, when, why, and what it superseded.
Lessons
Verified observations from completed work that may improve future performance.
Open items
Questions, contradictions, assumptions, and missing evidence that remain visible.
Memory rule: The model may propose a memory change. It should not silently convert an inference, preference guess, or temporary instruction into permanent truth.
memory_id
memory_type
statement
source_reference
created_at
approved_by
effective_date
confidence
sensitivity
supersedes
expiration_or_review_date
status
correction_history
Authority
The Trust Ladder
Capability should increase only after evidence supports the next level.
No tools. The system drafts and reasons from information you provide.
Read-only access to one approved knowledge collection.
The system retrieves approved memory and proposes changes for review.
Calendar, email, repositories, or public sources are read within explicit boundaries.
The system prepares messages, changes, reports, or code but does not execute them.
A human authorizes a specific action with a clear target, scope, evidence, and rollback.
A narrow, reversible, monitored workflow runs under budgets, stop controls, and periodic review.
Do not skip levels. Moving from a chat demonstration directly to autonomous email, deployment, purchases, public posting, or account administration creates an authority problem, not merely a technology problem.
First project
Build a local Daily Brief
A daily brief combines retrieval, organization, prioritization, and drafting without requiring autonomous external action.
Inputs
- Local task list
- Approved calendar export
- Current project status files
- Recent owner-approved notes
Output
- Top priorities
- Deadlines and conflicts
- Blocked items
- Risks and stale information
- Clearly labeled recommendations
Receipt
- Generation time and system version
- Model identity or model-free status
- Sources included and unavailable
- Omissions and assumptions
- System recommendation versus owner decision
Definition of done
For ten consecutive uses, the brief runs locally, cites approved inputs, exposes stale or missing information, takes no external action, and identifies at least one useful priority, conflict, or follow-up.
Assurance
Test the brain before you trust it
- Correct-source test
- Unsupported-answer test
- Contradiction test
- Stale-data test
- Prompt-injection test
- Oversized-context test
- Sensitive-data test
- Tool-denial test
- Stop-control test
- Recovery test
A/B verification
Verifier A confirms that the requested capability and requirements were implemented. Verifier B attempts to break the result, challenge assumptions, inspect negative evidence, and confirm that the exact candidate being approved is the one that was tested.
Execution
A practical 30-day roadmap
Week 1 - Foundation
- Write the charter and first use case
- Prepare the local environment and backup
- Install one runtime, model, and interface
- Record baseline versions
Week 2 - Knowledge
- Create one authoritative collection
- Add metadata and sensitivity labels
- Test retrieval and contradictions
- Remove duplicates
Week 3 - Memory and workflow
- Create the five memory classes
- Add memory approval
- Implement one mission template
- Produce source and omission receipts
Week 4 - Assurance
- Run the ten trust tests
- Document failures and corrections
- Perform A/B verification
- Approve one read-only next capability
Build trust in this order: Useful behavior → visible evidence → repeatable results → tested controls → bounded authority → monitored operation.
Lessons from Aegis
The language model is only one component.
- Owner intent should be a system object, not an implied conversational guess.
- Context must be purpose-bound.
- Unknown, stale, contradictory, or missing evidence must remain visible.
- Models, providers, routes, and tools need identities and versions.
- Receipts preserve sources, omissions, tests, reviewer findings, and decisions.
- Technical availability does not equal authority.
- Stop controls require observed proof.
- Requirements, architecture, implementation, testing, installation, deployment, and operation are different states.
The larger lesson: Build the brain as a governed system of memory, context, authority, evidence, and human decisions.