How It Works

Ask → Route → Authorize → Retrieve → Respond / Update → Verify

Every request — from a hosted assistant, a local model, or a developer tool — moves through the same governed path. Here's what happens at each step, in plain language, with a developer note underneath for anyone who wants the mechanism.

1. Durable knowledge

Useful facts, decisions, project state, and preferences are written down in human-readable form — the same kind of notes a competent assistant would keep for you, not a raw log of chat messages.

Developer noteCanonical durable knowledge is stored as human-readable Markdown. Indexes, embeddings, and search structures are derived from it and are treated as replaceable, not authoritative.

2. Project boundaries

Your knowledge lives inside separate projects — personal, work, a business, research — so context from one doesn't bleed into another.

Developer noteEach project is an isolated domain with its own scoped knowledge. Project existence and client authorization for that project are tracked as two separate facts.

3. Layered context (bootstrap)

Rather than loading everything at once, AIOS reconstructs context in layers — starting with governance and security, then narrowing down to the specific project and the memory relevant to the current question.

Developer noteSee the tier stack below: Tier 0 Governance & Security → Tier 1 User Interaction Profile → Tier 2 Organization/Domain Index → Tier 3 Active Project Context → Tier 4 Durable Retrieval Memory → Tier 5 Working Context.

4. Project resolution (routing)

The system figures out which project a request actually belongs to, based on its subject — not based on which project happens to be open or convenient.

Developer noteRouting is deterministic and server-controlled. A client hint can suggest a project but cannot expand what it's authorized to access. Ambiguous routing fails closed rather than guessing.

5. Authorization

Being able to see that a project exists is not the same as being allowed to read or write it. Every request is checked against what the requesting client is actually permitted to do.

Developer noteConnectivity and authorization are distinct. Read and write permissions are tracked separately per project per client. Authorization failures fail closed.

6. Retrieval

Only the relevant, authorized knowledge for the current project is pulled in to answer the question — not the entire second brain.

Developer noteSearch and exact-read retrieval are scoped to the authorized project boundary, with provenance carried alongside each result.

7. Governed updates

When something genuinely new or changed needs to be remembered, it's created, appended, or corrected under policy — not silently overwritten and not written to the wrong project.

Developer noteMutation supports create, append, and correct operations, preserves prior information where appropriate, and validates the intended durable result. See the governed-memory decision flow on Security & Governance.

8. Verification

The result — an answer or a durable update — is checked against what was actually intended before it's treated as final.

Developer noteVerification closes the loop on a mutation: the written result is checked against the intended durable state rather than assumed correct.

9. Recovery

Because the underlying knowledge is human-readable, it can be recovered and the systems around it rebuilt — the knowledge doesn't depend on any one index, connector, or client surviving.

Developer noteSee Ownership & Recovery for the backup, reconstruction, and validated-recovery model in full.
Layered bootstrap

Context is reconstructed in layers, not loaded all at once

Select a tier to see what it contributes before the system ever reaches your actual question.

Policy, authorization rules, and fail-closed behavior are established before anything project-specific is loaded. Nothing downstream can override this layer.

Want the conceptual system map?

The Architecture page lays out how AI clients, adapters, the project-aware gateway, and durable canonical knowledge fit together as layers.

See the Architecture →