daidocs

Two halves, one format: .dai for history, .cai for code

Most memory tools remember one thing. A code-graph tool knows your call graph but not the conversation where you decided how it should work. A chat-memory tool knows the decision but cannot tell you who calls the function you are about to change. This is both, in one plain-text, local-first layer, with a router that sends each question to the half that can answer it.

Both are plain text on your disk, both answer to grep and git, and both exist for the same reason: so a model reads a small, question-specific slice instead of the whole history or the whole repository. They also cross-link. A document that names a code symbol is linked to it both ways, so a single query can return the code and the prose that explains it. The ask router then decides which tier answers: code graph, documents, or past sessions. The code tier has its own guide in Kerneta-Cai/.

You do not have to take both. .dai on its own is a complete document-and-history memory; .cai on its own is a complete code graph. Install one, or install both and let the router join them.

.Cai for code: measured against Graphify

.Cai is a plain-text code graph. On real repositories it matches or beats Graphify on accuracy while putting a fraction of the tokens in front of the model. A few headline rows, all rebuilt from source offline (no API, XERJ not included):

At 35x scale (the CPython standard library, 7,469 symbols) the per-query cost stays flat: .Cai averages 69 tokens to Graphify's 178.

See the full results · reproduce them →

Language independent, model independent

A .dai file is three plain-text zones: a YAML header, a fenced JSON block, and the text. No binary, no database, no SDK required to read it.

• Any programming language. The reference engine is Node. A reader in Python, Rust or Go is an afternoon's work, and the spec is normative, written so that two independent implementations agree.
• Any model. The store is written once by a cheap observer model and read by whichever model answers. The same store measured with five answering models: 78% to 92%. Change the model, keep the memory.
• Any tool. grep, git log, diff, your editor, a shell script. Memory that answers to ordinary tools.

Build a reader in another language and open a PR: that is the contribution that matters most.

What is in this repository: the Kerneta Engine V4.4n that reads and writes .dai files, the MCP server that connects it to your assistants, the .cai code tier in Kerneta-Cai/ that builds and reads the code graph, and the complete evidence for every number quoted below: the benchmark run, the judge's verdict on each of the 500 questions, and the five-model comparison. Each evidence file is hashed in MANIFEST.sha256 so you can check that what is described is what was measured; how to do that is in docs/PROVENANCE.md.

Why this exists

Every memory product on the market keeps your history inside its own service and hands it back through its own API. .dai takes the opposite bet: memory is a file format, the way a photo is a JPEG. Three plain-text zones per conversation, a small derived index beside them, and any model, any tool, or grep can read it.