Personal project · Active foundation
Private repositoryAlanOS
A personal operating system built as a federation, not a single all-knowing assistant.
AlanOS is the shared architecture for a set of independent personal domains. Career owns professional knowledge. Health owns health knowledge. Finance and Work own their own concerns. Each domain keeps its evidence, policies, capabilities, and privacy boundary inside itself.
AlanOS does not store those domains and it does not implement their products. It defines how they describe themselves and how a future assistant may call them without becoming another source of personal truth.
Why I separated it
The idea began inside Career Intelligence. Once I started imagining health, finance, work, learning, and family systems, keeping the shared architecture inside the Career repository no longer made sense. Career would have become the accidental owner of every other domain’s rules.
I extracted AlanOS into its own repository so no domain owns the federation. That decision made the boundary clearer: domains own knowledge and useful capabilities; AlanOS owns the common language they use at their edges.
The system in plain English
Rendering diagram…
What exists today
AlanOS is a working standards repository. It is not yet an orchestrator or an application shell.
- A domain contract
- Version 1.1 defines the exterior every domain must describe: identity, knowledge, schemas, policies, read capabilities, provenance, interfaces, and privacy. Actions and artefacts remain domain-specific.
- One visibility language
- Public, personal, and confidential mean the same thing across domains. Filtering must be deterministic, default-private, and fail closed when a classification is absent or invalid.
- A machine-readable manifest
- Each domain publishes what it owns, which contract version it follows, which capabilities exist, and which interfaces may expose them—without revealing paths, databases, or credentials.
- Central conformance checks
- AlanOS validates domain manifests against one JSON Schema. Each domain separately checks that its own generated manifest is current, so the standard and the implementation can detect different kinds of drift.
How a domain joins the federation
A repository does not become part of AlanOS because it uses the name. It joins by making its responsibility, knowledge, privacy, and callable surface explicit.
- 01
Own one bounded responsibility
A domain defines what belongs inside it and, just as importantly, what belongs somewhere else.
- 02
Maintain durable knowledge
Every domain keeps citable knowledge with stable identities, schemas, visibility, and a generated index.
- 03
Declare the exterior
Its manifest names current and planned capabilities, evidence posture, interfaces, and privacy ceilings.
- 04
Enforce privacy in code
A model never decides whether something may leave a domain. Deterministic policies filter every exposed view.
- 05
Expose a read contract
Federation begins when another tool can call a bounded read capability without learning the domain’s storage layout.
Privacy is part of the contract
AlanOS uses three visibility levels: public, personal, and confidential. A domain may be stricter, but never looser. Missing or invalid visibility values fall back to a private tier, and confidential material never crosses domains automatically.
This cannot be delegated to a prompt. Every interface declares the most sensitive tier it may serve, and deterministic code removes knowledge and relationships that exceed that ceiling. Raw evidence stays behind the domain boundary even when a derived knowledge record is safe to expose.
Career Intelligence proved the pattern
Career Intelligence is the reference implementation. It has durable career knowledge, a generated index, deterministic visibility filters, a domain manifest, a command-line interface, and read-only local and remote Model Context Protocol surfaces.
That relationship runs in both directions. Career gives the shared contract something real to test; AlanOS prevents the Career implementation from becoming the standard by accident. Health, Work, and Finance can then adopt the same exterior while keeping entirely different interiors.
Where it goes next
Career is currently the only domain with a callable read interface. Health has read services behind its command-line interface, while Work and Finance remain at different stages of the same boundary. Wiring those domains is planned work.
A personal assistant comes after those contracts are real. Its role will be to route intent, request permission, and compose bounded answers. It should never read private repositories directly or accumulate its own copy of domain truth.
Technologies
- Standards
- JSON Schema, domain contracts, visibility policies
- Validation
- TypeScript, Node.js, Ajv, automated conformance checks
- Documentation
- Markdown, Mermaid, architecture decision records
- Delivery
- pnpm, GitHub Actions, version-controlled manifests
The useful part of a personal operating system is not one assistant that knows everything. It is a set of trustworthy domains that know exactly what they own—and what they may reveal.