NEXUS — the typed knowledge substrate that replaces the vector database

Typed entities, typed relations, human-editable, git-versioned, cited-by-default. Sub-5ms retrieval. Zero vendor lock-in.

NEXUS — the Native Entity eXtensible Universal Store — is AlifZetta's replacement for the vector database. It is a typed knowledge substrate where every fact is a named entity, every relation is a typed edge, and every entry is stored as human-editable DTL under git. There are no embeddings. There is no similarity search. There is no vector-database vendor bill. Retrieval is sub-five-millisecond against ninety-thousand-plus typed entries via a compiled inverted index. If you can read a text file and you can walk a graph, you can debug, extend, and audit NEXUS end-to-end. That is why we picked it. This page explains what NEXUS is, why it out-competes vector databases on the metrics that matter for enterprise deployment, and how you can inspect a live NEXUS substrate right now at demo.axz.si.

What is a vector database, and why is it the wrong abstraction for grounded intelligence?

A vector database is a beautiful piece of engineering for a specific problem — nearest-neighbour search in high-dimensional space. Pinecone, Weaviate, Qdrant — the category is well-executed. But the problem it solves is only tangentially related to the problem enterprise buyers actually have. Enterprise buyers do not need approximate nearest neighbours. They need cited, verifiable, auditable facts. A vector is a lossy compressed fingerprint of text. When your top-k retrieves the wrong chunk, you cannot ask the vector why. When compliance asks 'why did the model tell that patient to take this dose?', pointing at a cosine score does not satisfy an auditor. NEXUS was designed backwards from that failure mode.

NEXUS vs vector database — the point-by-point comparison

How to inspect a live NEXUS substrate right now

Every NEXUS entity on our production substrate is human-readable at axz.si/substrate/. Open kb_finance_predictive_v1.dtl, kb_healthcare_predictive_v1.dtl, or any of the forty-six domain KBs — you will see plain-text DTL entries with @fact, @predicts_next, @leading_indicators, @confidence, @horizon, and @evidence fields. Every line is diffable in git. Every claim is human-editable. Every citation is a URL you can click. That is what a typed knowledge substrate feels like from the outside.

Frequently asked

Is NEXUS just a fancy grep?

No. NEXUS is a compiled inverted index over typed entities with typed relations. The retrieval path is: token-level lookup → posting list → TF-IDF-like ranking → typed-entity return. Grep is O(N) linear scan. NEXUS retrieval is O(k) where k is the number of terms in your query, with sub-5ms latency at 90k+ entries. But — and this is the load-bearing point — you can grep the NEXUS files as a fallback debug tool, because they are plain text. That optionality is exactly what a vector database denies you.

Does NEXUS work for non-English?

Yes, natively. The tokenizer keeps Devanagari runs as first-class tokens alongside Latin. NEXUS in production at answers bilingual English + Nepali queries against the same substrate, same query path, sub-5ms. No separate embedding model. No re-ranker. No language-specific hyperparameters.

Can I run NEXUS air-gapped?

Yes. That is the whole point. NEXUS has no cloud dependency, no external LLM call, no vector-DB SaaS bill. You run it on your own hardware. This is why NEXUS is deployable inside government, healthcare, defence, and finance — the four verticals where the frontier-lab stack cannot go.