One Container, One Scope
Every .omnidata container has exactly one scope. It might be a professional role, a project, a client engagement, or a personal domain. It is never “everything.”
Why not one big container?
- Data leakage: Searching for “revenue projections” surfaces both your client’s financials and your personal investment notes.
- Blast radius: A corrupted container affects only one scope. Isolated containers contain the damage.
- Portability: You can hand a client their
.omnidatabundle when an engagement ends. - Cognitive clarity: When you open
director-of-ai.omnidata, you know exactly what context you’re in.
How scope maps to ManyHats
In the ManyHats role management system, each hat gets its own .omnidata container:
| Hat | Container | Contains |
|---|---|---|
| Director of AI | director-of-ai.omnidata/ |
Work emails, tasks, architecture notes, meeting transcripts |
| Eidos | eidos.omnidata/ |
Research, code context, voice notes, design decisions |
| Health | health.omnidata/ |
Medical records, fitness logs, nutrition data |
| Financial Manager | financial-manager.omnidata/ |
Tax docs, investment research, account summaries |
When you manyhats wear director-of-ai, the runtime opens the director-of-ai.omnidata bundle. All captures, searches, and ingress flow into that container. Switch hats, switch knowledge.
Scope without ManyHats
ManyHats is not required. Any application can create .omnidata containers:
omnidata init --name "project-zeus"
omnidata init --name "greenmark-engagement"
omnidata init --name "ml-research"
The scope is whatever you decide. The format enforces isolation, not taxonomy.
Cross-scope search
Sometimes you need to search across scopes. This is the job of Meta-Omni — a future federation layer that searches multiple containers and fuses results. Each container remains independent; Meta-Omni reads them without modifying them.