What happened

The occasion is their tool for microfinance banks in Nigeria. When the system flags a suspicious transaction or a loan application, “the model thinks this is risky” is not enough. You need the edition of the rule the decision leaned on, which historical pattern matched, and how the data was processed. Vector search over the text and numbers of an application finds similar cases fast. For a later audit it does not keep a lineage: there is no stable pointer to the rule version or to the source record.

They show the substrate with a SQL-like query. By decision id it selects the regulation version, the source-data id, and the hash of the embedding that took part in retrieval. That query does not make the model more accurate. It makes the decision inspectable after the fact: an auditor opens a row instead of re-running search and hoping for the same neighbors.

Then a hybrid, not a replacement. The vector database stays the first step: it is fast and it is the right tool for finding similar documents. What was retrieved moves into the substrate, where version and governance appear. The author is plain about the cost: more storage, a stricter schema, stricter versions. In Nigerian microfinance, he argues, a misclassification or a decision with no trail costs more than that overhead. Ahead they want auditing closer to real time, and a trail that people without an engineering background can read — the trail exists, and the people who sign the decision still have to be able to see it.

Why it matters

In conversations about semantic search, a vector store is often called “the database for the model”, as if similarity were the same thing as an audit trail. For an internal draft that is enough. For a bank, where a flag on a transaction must point at a rule, similarity without a version is a hole. The substrate does not make the model more accurate. It answers a different question: on what basis was this said on that day.

The hybrid is useful as a boundary. Search lives where you need speed and nearness. The trail lives where you need to check again. Folding both into one “smart database” either slows search with heavy bookkeeping or pretends that yesterday’s embedding hash and today’s are the same thing after the rule has already changed.

In practice

The piece is short and describes one product, with no public bake-off of stores. The query with decision, rule version, source, and hash is a sketch, not a finished schema. Its value is the set of fields: if your answer row has no rule version and no pointer to the record, it is early to argue about which vector database to buy.

A trail that only an engineer can see does not help the person who signs. The author leaves that as the next question, not as a solved task.

1. Separate “find something similar” from “explain what the decision stood on”. Those are different stores and different lifetimes.
2. On the decision row, keep the rule version, the source id, and the embedding hash — not only the answer text.
3. Do not promise that a fresh search will return the same neighbors. An audit needs a stored pointer, not a new query.
4. Price the storage, the schema, and the versions up front. A hybrid costs more than a pure vector database, and that price is reasonable only where a trail is mandatory.
5. Show the trail to the person who signs the decision, not only to the team that writes the query.

Takeaway

Apex Grid does not retire vector search. They put it in front of a layer that remembers the rule and the source. For a regulated task that is more convincing than another argument for “vectors only” or “tables only”. Carry the idea over as trail fields, not as a slogan about substrates.