Reference.

You store documents. Everything else is derived, lives in the same file, and is removed with the document it came from. The one exception is the audit log, which is kept beside the file on purpose.

Chunking is deterministic: the same text always produces the same chunks, so the same query returns the same result. Deleting a document removes its chunks, index entries, vectors, and edges in one transaction, so nothing derived outlives the document.

Note what deletion does not promise. The freed space returns to the file's free list and is reused, but the old bytes are not overwritten. If the content has to be unrecoverable from the file itself, encrypt the disk.

Not available yet. The package is not on PyPI, so pip install hadano-ai-cabinet fails today. This reference describes the tools as implemented; it is not something you can install right now. See /facts.json (installable: false).

Not connected in this version. It was built against the storage layer that has since been replaced. Setting HADANO_EMBEDDINGS to anything but off is refused when the server starts, with the reason, rather than accepted and quietly ignored.

The settings below are what it is fixed to when it returns. They are listed because they are not configurable and never were — changing any of them would invalidate every stored vector. On the layer where it was measured, it installed 25 more packages, downloaded a 240 MB model, and took resident memory from 22 MB to 604 MB. Keyword and graph search never touched a vector.

These are fixed by the specification and not configurable, because changing them changes correctness rather than preference.

Most single-file databases leave two extra files sitting next to the main one for as long as anything is connected. This one does not, and the difference changes what you have to copy and what a crash leaves behind.

A write-ahead log buys one thing above all: readers keep reading the last committed state while a write is in flight. That is the right trade for a database several processes share.

This one is held by a single process at a time. The file takes an exclusive lock when it opens, and tool calls are serialised behind it. There is no second reader for a log to protect, so the payment for one would be pure overhead: a shared-memory index next to the file, snapshot bookkeeping so readers know where a log ends, and a checkpoint step to fold it back in — usually on a background thread. Three moving parts, bought for a guarantee this design already gives away on purpose.

Saving the old bytes instead costs one file that exists only mid-write, and it keeps a claim on the front page literally true: the file is the database. With a log, the newest data lives outside the main file until a checkpoint, so “copy the file” quietly means “copy the file and hope”.

The bill for that comes due in the last row of the table above, and it is not small: a reader waits for the writer. Storing a one megabyte document blocks queries for the duration. Concurrent readers do not scale, because there are none. If several people or processes need the same knowledge base at once, this is the constraint that says use something else — or wait for the hosted tier, which exists to move the file behind one process rather than to share it.

Exceeding any of these is E_TOO_LARGE. The set is closed — no other size check raises it.

Five entry points today. None needs the MCP server to be running. Snapshot and JSONL export are being rebuilt for the current storage engine.

hcserve is the shared-access path: one resident process owns the database file and answers HTTP requests from many clients. A request needs an API key, which the server stores only as a hash; permissions are default-deny and granted per verb (read, write, delete, admin) and scope (everything, a tag, or one document); every request leaves one audit line; each key has a per-minute limit. It binds the loopback address unless a private address is named, and refuses a public address unless a TLS terminator in front of it is declared. Issuing, revoking and granting keys happen only on the machine that runs it, never over HTTP.

hadano.reset removes the database file, its journal, and its audit-log directory — by deleting the files, never by opening the engine. By default it only lists what would go; deleting requires --apply plus the database's file name typed again as a confirmation, so it stays a deliberate human act. It refuses symlinks, junctions, zero-byte files, files that are not a Hadano database, and paths inside synced folders.

Stated plainly, because the opposite would be false: reset does not touch hadano-*.db backup copies (it cannot tell which database they belong to — it lists them instead), cannot reach JSONL exports, synced copies, or shadow copies, and deleting a file does not scrub the bytes from the storage device — full-disk encryption is the layer for that. One audit line recording the reset itself is written afterwards.

Being rebuilt. The dump and restore commands were written for the storage layer this project has since replaced, and they do not work against a current database file. The behavior below is the design they are being rebuilt to; until that lands, a backup is a copy of the file. This rebuild is planned.

The behaviour above is fixed by a specification that pins every value range, SQL statement, error code, and acceptance test, so it can be rebuilt from the document alone. If something here disagrees with what the software does, the software is wrong.