Developer briefSystem state · 2026-08-28

A portable second brain with a governed memory layer.

AIOS keeps durable knowledge outside any one AI vendor, rebuilds context from a canonical manifest, scopes every production domain, and treats memory writes as authorized operations rather than incidental chat behavior.

Explore the architecture Compare Cloud Brain

Markdowndurable source

replaceable clientsgoverned writesrebuildable index

Durable by design

Human-readable Markdown owns the truth. Clients and indexes can be replaced.

Context on demand

A compact bootstrap routes the session before detailed memory is retrieved.

Policy before mutation

Every write is qualified, scoped, classified, authorized and verified.

Proven recovery

Restored Markdown is reindexed and queried in isolation—not merely unpacked.

01 · System map

Logical architecture

The durable brain, operational index, access connectors and recovery layer are separate components with explicit responsibilities.

Interface layerAI clientsChatGPT · OpenClaw/Minerva · future clients

Portability layerThin adaptersConnection + bootstrap pointer + client invocation

Access layerScoped MCPOne constrained connector per authorized domain

Operational layerBasic MemoryIndex · hybrid search · entities · relations · note operations

Canonical layerMarkdown projectsaios-core · CFN · future activated domains

Narrow control planeAdmin MCP

Status, registry, target validation, constraint checks and sanitized backup metadata.

Recovery planeOff-host snapshots

Versioned backup, isolated restore, hash/content checks, reindex and retrieval.

Derived state is disposable

The operational index can be rebuilt from restored Markdown.

Administration is not a shell

The control plane cannot read arbitrary files, delete projects or activate production.

02 · Session reconstruction

Bootstrap only what the session needs

Every authorized client begins with one canonical manifest, then moves from global rules to project context and finally to relevant durable memory.

Governance & security

Security invariants and mutation authority are guaranteed before a write.

Interaction profile

Stable communication, workflow, autonomy and memory preferences.

Domain routing index

Maps the subject to an authorized project without loading every domain.

Active project context

Current purpose, policy, authorization, constraints and priorities.

Durable memory on demand

Detailed history, entities, decisions and processes only when relevant.

Transient working context

Temporary logistics, brainstorming and unverified information stay in-session.

This prevents both “paste the entire second brain into every prompt” and “let the model guess what context matters.” Detailed memory remains retrieval-only until the routed task needs it.

03 · Governed mutation

A memory write is a decision pipeline

Conversation alone does not automatically become durable memory. The system selects the least destructive representation that policy permits.

Override & screen

Honor remember/temporary controls; block secrets and unauthorized classes.

Route & qualify

Resolve the owning project; decide whether the information is durable.

Classify & resolve

Assign a record class and find the existing canonical subject.

Assess

Evaluate significance, confidence, duplication and correction status.

Choose operation

Ignore, create, append, scoped update, merge, supersede, escalate or block.

Authorize

Apply project policy and GREEN, YELLOW or RED autonomy classification.

Mutate & verify

Confirm project, target, content, uniqueness, provenance and preserved history.

GREEN

Routine and low risk

Create, categorize, append compatible facts or add provenance when active automation policy permits.

YELLOW

Scoped and reversible

Correct, merge or reorganize only with an exact target, preserved history and post-write verification.

RED

Explicit authorization

Deletion, bulk rewrite, sensitive cross-project movement, new exposure or governance/security change.

04 · Production boundaries

Connectivity does not equal authorization

Production access is scoped by project, principal, client path, operation, data class and automation mode.

ClassContentCFN status

P0Public referenceAuthorized

P1Internal operationalAuthorized

P2.1Funding criteriaAuthorized with controls

P2.2Relationship termsAuthorized with controls

P2.3Strategy & plansAuthorized with controls

P2.4Non-sensitive workflow stateAuthorized with controls

P3Sensitive personal/financial/contractualNot authorized

P4Authentication & secretsProhibited

05 · Production readiness

A folder does not become production by existing

AIOS uses thirteen gates before a domain receives an explicit high-impact activation decision.

Establish canonical project identity.
Define routing, ownership, aliases and domain boundaries.
Define authorized and prohibited data classes.
Define authorized users, clients, services and operations.
Select and validate the automation mode.
Define memory, provenance, history and deletion rules.

First activated production domain

Creative Funding Northwest

Active for P0, P1 and approved P2.1–P2.4 through one constrained ChatGPT connector; automatic capture remains disabled.

06 · Continuity

Recovery includes behavior, not only files

The acceptance test proves a restored system can reconstruct governed context from the canonical source.

01Snapshot

Versioned off-host Restic backup

02Restore

Temporary isolated recovery root

03Verify

Required files, hashes and content markers

04Reindex

Separate Basic Memory state

05Retrieve

Bootstrap, policy and validation records

06Recheck

Live system remains unchanged and healthy

“The database is operational state. The brain survives if the human-readable source can be restored, reindexed and understood by a fresh authorized client.”

07 · Build retrospective

Authority was added only after each invariant passed

The implementation grew from an isolated write/search proof into a governed production domain through validated stages.

Baseline

Markdown canonical, clients replaceable, loopback-only service, no production data.

Memory proof

Write, index, search, read, scoped update, no-overwrite and duplicate controls.

Recovery proof

Off-host backup, secret exclusions, isolated restore and semantic rebuild.

Portable governance

Canonical manifest, context tiers, domain routing and memory decision engine.

Narrow administration

Allowlisted Admin MCP, synthetic tests and explicit negative capabilities.

Production activation

Dedicated CFN connector, 13 gates, RED approval and verified post-change backup.

08 · Reference comparison

Shared philosophy, different product layers

Cloud Brain’s public page emphasizes a managed collaboration product. AIOS currently emphasizes owner control, policy and recoverability.

Cloud Brainpublic product description

AIOScurrent verified architecture

Core promisePersistent memory across MCP clientsPersistent memory across replaceable AI clients

Canonical layerPublic page emphasizes a cloud knowledge graphHuman-readable Markdown; index is derived

SearchHybrid full-text + semanticFull-text, semantic/hybrid + entity/relation context

HostingManaged cloud productSelf-hosted and owner-controlled

IsolationPostgres RLS + folder grantsProject roots + constrained connectors + fail-closed routing

Team modelFolder-scoped collaborator accessProject isolation; general team-sharing layer not yet documented

BootstrapAutomatic shared-brain accessCanonical manifest with Tier 0–5 reconstruction

Write governanceNot detailed publiclyQualification, autonomy, authorization and post-write verification

RecoveryNot detailed publiclyOff-host snapshot + isolated restore + reindex + retrieval test

Cloud Brain appears product-first: managed hosting, OAuth, browser UI, multi-user folder grants and database-enforced tenancy.

AIOS is architecture-first: canonical files, explicit bootstrap, domain connectors, mutation governance, activation gates and tested restoration.

Open reference site

09 · Honest assessment

Current constraints and next engineering moves

The system is operational within a narrow production boundary. The next work is about consistency, scale and usability—not hiding the remaining gaps.

State consistency

Generate or lint status blocks so older context cannot contradict newer activation records.

Policy as code

Turn the documented memory schema and data-class rules into deterministic preflight checks.

Team authorization

Add scoped collaboration without weakening project or semantic-traversal isolation.

Memory operations UI

Expose provenance, supersession, recent writes and pending RED actions clearly.

Bounded automation

Validate classification, rollback, duplication and P3/P4 blocking before enabling capture.

Schema quality

Require provenance and as-of dates; flag stale or structurally incomplete records.

10 · Peer discussion

Questions worth comparing under the hood

These move the conversation beyond features and into source-of-truth, policy, isolation and recovery semantics.

12 architecture questions

What is the true canonical source: database rows, documents, an event log, or something else?
Can semantic/vector state be rebuilt entirely from the canonical representation?
What context does a fresh AI session receive, and how is token cost controlled?
How are conflicting facts, supersession, deduplication and provenance represented?
Does a write pass a policy layer, or is successful API authentication sufficient authority?
How are AI inference and user-asserted facts distinguished?
Are access grants enforced for every semantic and relation traversal path?
Can a connected MCP client be restricted by both data class and operation?
How are destructive actions, bulk rewrites and cross-scope moves approved?
Has recovery been tested by restoring in isolation and bootstrapping a fresh AI client?
Is there one client-neutral bootstrap contract, or does every client carry its own policy copy?
What audit trail exists for AI-created, AI-edited and user-edited memory?