Paths, entries, facts, and a state chain over a content-addressed cella.
metatheca is a path-and-fact layer over syntheca, the content-addressable storage substrate. It does one thing: it maps human-meaningful paths onto an immutable, content-addressed blob store (the syntheca cella it consumes), with extensible structured metadata recorded as facts and a single-pointer head model for state and history.
It is not a backup tool, a sync engine, a full-text search service, or a hosted product. Those are valid things to build on top of metatheca — and the ext/ extensions below are exactly that.
Specification at v0.2, covering Phase 1: identifiers, wire formats, the core fact namespaces, operations, fact queries over the generic fact log, the head pinax, vault layout, and the CLI surface. Early development — APIs are unstable until 1.0. The Rust reference implementation is metatheca-rs, published on crates.io as metatheca (binary metatheca, suggested alias mt).
Or jump to the changelog.
metatheca — Greek meta- (μετά, "above, beyond, with, after, change") + theca (θήκη, "case, repository"). A properly Greek compound, continuing the -theca family established by apotheca (the named write-once layer at the bottom) and syntheca (the content-addressable substrate metatheca consumes); each prefix names what kind of theca the layer is.
Three readings of meta- converge on the same structural fact about this layer: position ("above, beyond" — the storehouse above the content-addressed substrate), metadata ("data about data" — exactly what this layer contributes: the structured records that turn bytes into addressable, queryable entities), and transformation (metamorphosis, metabolism — metatheca transforms a content-addressable cella into a navigable, historied vault). Where apotheca is the put-away store and syntheca the together-named store, metatheca is the over-/about- store: the layer that lifts bytes into meaning.
Four concepts carry the layer:
Everything below — content addressing, integrity, backend composition, one-way sync — is the substrate's job (syntheca over apotheca). metatheca stores nothing outside its cella.
metatheca reserves the ext/ subtree of a vault for derived-view extensions. Each extension occupies its own dedicated syntheca cella under <vault>/ext/<name>/cella/, writes only to that cella, consumes metatheca read-only, and is fully reindexable from metatheca's cella. The metatheca spec defines only the reservation and its rules (SPEC §7); each extension carries its own specification:
lgops) — lexical search via BM25 over an inverted index. Tokenizes the corpus reachable from a metatheca state into a term dictionary and per-term posting lists; analyzer identity and BM25 parameters pinned at genesis. Structured boolean, phrase, and negation queries.smops) — semantic search via IVF-flat over fixed-dimension embeddings. Embedding model and distance metric pinned at genesis. Nearest-neighbor queries.txops) — typed predicate retrieval over a content-addressed index. Extracts (entry, predicate, typed value) tuples from the facts reachable from a metatheca state into ordered segments and hash-bucketed postings; extractor family and version pinned at genesis. Exact filter queries — equality, prefix, range — with optional ordered enumeration, against any historical index-state.dnops) — structural decomposition via a frozen segmenter pipeline, producing a content-addressed tree of sub-blobs per entry. Recursive structural diff, exact move detection, and partial-tree walk. Segmenters are consumer-supplied — the same machinery serves prose sentence-trees, markdown structure, filesystem trees, or any other deterministic decomposition.zet) — hybrid-query coordinator over the two search extensions. Pins a (semopsis-state, logopsis-state, fusion-config) triple and fuses their rankings; defines no new content of its own.metatheca consumes exactly one syntheca cella and inherits everything substrate-level from it: content addressing and dedup from syntheca, and below that apotheca's backend composition, write-once discipline, integrity, and the pinax compare-and-swap primitive on which the head pointer is built. A consumer that needs only content-addressed bytes uses syntheca directly; a consumer that needs named write-once storage uses apotheca. metatheca is for consumers that need identity, paths, structured metadata, and history.