Ax0s
Book a call

Under the hood · ax0s-memory 0.5.0

No magic.
Just records.

Most software asks you to trust a black box. This page opens ours. In ten minutes of reading you'll know what Ax0s Memory actually is — where your data physically lives, what happens when something gets written or corrected, who's allowed to touch what, and how we test it. Written for a curious owner, precise enough for their engineer.

Walk the stack ↓ Every claim's receipt →

Four layers, bottom to top

Where your data lives,
and what sits on top of it.

The store A database (LanceDB) running on your machines — a server in your office or a cloud account you control. Not our cloud. If you turned Ax0s off tomorrow, the files are still yours, still readable. This is what "self-hosted" means concretely: we never hold your data.
The records Everything is a record: a note, an email, a decision, a transaction. Each carries its source, its timestamp, and who or what wrote it. When a fact changes, the old record isn't deleted or overwritten — a new one supersedes it, and both stay addressable. That's why "what did we believe in March?" is answerable here and nowhere else.
The doors One service exposes three doors: a REST API at /api for software, and two MCP endpoints for AI assistants — the open standard Claude, ChatGPT and others speak. Same store behind all three, so a person, a script, and an assistant always see the same current answer.
The applications The CRM, the fleet console, and anything we build for you are interfaces over this same layer. They don't own the data — they read and write the shared records. Swap an app, keep the memory.

What happens when
a fact changes.

This is the mechanism the whole product hangs on, so here it is step by step. Ordinary databases update in place — the old value is simply gone, and with it the answer to "why did we think that?" Ax0s corrects by supersession instead.

A correction, step by step

Friday17:00 "Deploy window is Friday 5pm" is written. It becomes the current answer. Record one
Wednesday15:00 The plan changes. A new record lands and names the old one as superseded. Record two — now current
Any timelater Ask normally, you get Wednesday. Ask for history, you get both, dated — who changed it, and when. Nothing lost

Why not just edit the row?

edit      the past is destroyed
          disputes become memory
          contests — loudest wins

supersede the past is addressable
          "since when?" and "who
          decided?" have receipts

retained & addressable since 2026-04-04
round-trip verified on the register

The honest boundary: supersession records corrections — it does not automatically detect contradictions between sources and resolve them for you. When two records conflict, that's surfaced as a conflict for a human. We claim the mechanism, not mind-reading.

Who's allowed
to touch what.

Every person, script and assistant that connects is a named principal with its own token. Each principal gets explicit grants — which areas of memory it can see, whether it can write, when its access expires. The default answer is no: an unlisted request is denied, not shrugged through. Grants can be revoked in one move, and every access decision leaves an audit record, so "what did the assistant read last Tuesday" is a query, not a mystery.

Named principalsBuilt Your bookkeeper's login, your sales rep's assistant, the ingest script — each is its own identity with its own scope. No shared master key.
Default denyBuilt Access is what's granted, nothing more. Expiry and revocation are first-class; rate limits stop a runaway script from hammering the store.
Audit trailBuilt Reads and writes are logged per principal. The access system is itself on the record.
What it isn't yetStated Per-record permissions, hardened multi-tenant isolation, and externally validated identity are not claimed. The boundary is published on the register — we'd rather you read the limit here than discover it later.

How we know
it works.

Written testsDefinitions 48 cover the HTTP surface, 10 cover the audit helpers, and 245 cover the research engine — counts of written tests, not coverage scores.
Live drillsDated Bounded exercises such as the write–correct–recall round-trip, run on real infrastructure and filed with transcripts.
We run on itDogfood The least rigorous evidence and the hardest to fake: the whole company runs on this store daily — email, banking, contracts and this website.

And the things we haven't proven, we list: three claims sit at "re-run pending" on the register right now — two retrieval-quality evaluations and a provider-retention check — rather than quietly omitted. A proof page that only ever says yes isn't a proof page.

Trust what you can inspect.

Bring your technical person to the call — this page is the agenda. We'll go as deep as they want to go.

Bring your engineer to the call Read the register →

ax0s-memory 0.5.0 · self-hosted · every claim receipted