01 · Memory
Institutional recall
Preserve people, projects, experiments, decisions, relationships, evidence and historical context so nothing important disappears into inboxes, chats or individual recollection.
In active development
How we work · DOS
DOS: the memory MNEOS runs on.
Most organizations forget. Context, provenance, evidence and the reasons behind decisions leak away with every project. DOS is being built so MNEOS never does: a memory for human and artificial minds working together, capability by capability.
Capability-specific development · updated September 28, 2026 Built in the open: each capability below carries its own scope, stage and date.
Where DOS stands
In daily use, and growing capability by capability
In use today. The founder works with AI collaborators every day through DOS: authorized connectors bring in mail and documents, decision records and project notes live as versioned text in private stores, a retrieval service is in development, and snapshots run on a schedule.
Being built now. Retrieval that always returns its source, relationship mapping, task verification and proven restore. Each is listed below with its real scope and date, and each advances as its evidence does.
DOS is not a product for sale. It is the operating memory of MNEOS, and it is being built in the open.
Capability inventory
Eight capabilities, scoped and dated
Every row names the real scope, the evidence that exists, and what still has to be earned.
| Capability | Scope | Stage | Evidence record | Last verified | Limitation |
|---|---|---|---|---|---|
| Source ingestion | Documents, notes and session records from the founder's projects | Development | Working in the founder's daily workflow for text sources; evidence review of a public example pending | September 28, 2026 | Text and Markdown sources only; no automatic capture of private messaging |
| Retrieval with citations | Answer a question and point to the record it came from | Development | A retrieval service exists; keyword ranking is the validated lane, hybrid ranking is not yet validated | September 28, 2026 | Readiness checks that exercise retrieval are still being added; a green health check does not prove retrieval works |
| Decision and version history | Keep why a decision was made and how it was later revised | Development | Decision records are kept as versioned text in private Git-backed stores | September 28, 2026 | End-to-end review of a decision-to-revision chain is pending; see the illustrative example below |
| Communications and attachment ingestion | Bring email and attachments into the record with consent and scope | Development | Email triage runs through authorized connectors in the founder's workflow | September 28, 2026 | Message-capture bridges for other channels are not operational; no LinkedIn or iMessage capture is claimed |
| Relationship mapping | Map people, organizations and projects to the evidence that connects them | Development; evidence review pending | A graph component exists in development | September 28, 2026 | Graph ranking is not validated; no public relationship graph is exposed |
| Task execution verification | Distinguish a completed task from a plausible report of completion | Design | Scheduled checks currently verify transport and process health as separate signals | September 28, 2026 | Outcome verification is designed, not demonstrated |
| Permission boundaries | Who may know, decide, disclose, approve or act | Design | Roles and disclosure classes are documented in the institutional architecture | September 28, 2026 | Enforcement inside the software is pending |
| Backup and restore | Recover the record after loss | Development | Automated snapshots to private repositories run on a schedule | September 28, 2026 | Restore drills have not consistently passed as of September 2026; snapshots are not treated as proof of recoverability |
Worked example
What a checked memory looks like
Illustrative example
One record: source, conclusion, decision, new evidence, revision
- Source
- A supplier datasheet for a candidate bench sensor, filed with its retrieval date.
- Tentative conclusion
- The sensor's stated response time appears adequate for the planned measurement window.
- Decision
- Include the sensor in the first bench configuration; record the assumption that the datasheet figure holds at bench conditions.
- New evidence
- A published characterization note reports slower response at the relevant operating temperature.
- Revision
- The assumption is marked superseded, the decision is reopened, and a bench timing test is added to the characterization plan. Both the original and revised records remain readable, with dates and the person responsible.
Illustrative record built from the kind of decision the bench work involves. No private correspondence, relationship data or security configuration is shown; this is not a live query.
Functions
Seven functions in the long-term architecture
02 · Structured intent
From language to action
Translate ambiguous human language into explicit objectives, constraints, permissions, dependencies and action objects.
In active development
03 · Evidence and provenance
Every claim to a source
Keep claims connected to sources, tests, models, authorship, confidence and uncertainty.
In active development
04 · Governance
Explicit authority
Represent who is allowed to know, decide, disclose, approve or act.
Intended architecture
05 · Reasoning orchestration
Many models, one system
Allow multiple models, tools, simulations and experts to contribute without giving any one system uncontrolled authority.
Intended architecture
06 · Execution
Intent to action
Connect approved intent to tools, workflows, experiments, equipment, documents and actions.
In active development
07 · Verification
Closing the loop
Determine whether work was completed, whether evidence supports the result and whether the institution learned from it.
Intended architecture
Doctrine and boundary
Public doctrine
The interface is language. The substrate is not. Natural language is the human intent interface, not the execution substrate. AI systems may reason, draft, simulate, critique and propose. Governed structured systems determine what is authorized, what is recorded and what is executed.
Public boundary
Public descriptions of DOS are intentionally architectural. Security-sensitive implementation details, private data structures, controlled program information, personal correspondence, actual relationship graphs and internal governance configurations are not disclosed through the public website.
Architecture · The method · Open problem: memory that can be checked