Patents

Family Four: Self-verifying vector and GPU retrieval substrate

Same data, same result, verifiable at every step: every index proves it was built from the database it serves.

Inference Fabric vector storeRelational system of recordGPU retrieval
Same data, same result, verifiable at every step five copies, five questionssource database? which version?vector store? matches the source?index files? corrupted?GPU memory? stale?query results? trustworthy?one authority, derived shardsrelational databasethe only authorityshard 1shard 2shard 3shard 4each carries references back
  • 8properties bound into every index's attestation
  • 4checks: build, persist, publish and load
  • ≤ 1active generation per index at any moment
  • 1 → 2one GPU read per member vector, two computations from it

Methods and Systems for a Self-Verifying Deterministic Vector Index and GPU Retrieval Substrate Materialized From a Relational System of Record. U.S. Provisional Patent Application No. 64/148,001 (patent pending). Embodied in the vector store of the Inference Fabric.

One authoritative source

Traditional vector pipelines create multiple copies of data, a source database, a vector store, index files, GPU memory, with no provable link between them. Data can drift, go stale or be corrupted, and nobody can prove what produced a result. Here the relational database is the only authority. Vectors are exported deterministically into memory-mapped shards that serve reads and carry references back to the database; they are serving representations, never another authoritative copy.

system of recorddeterministicbinary exportmemory-mapped shardsderived, serving onlyreferences back to the rows

Deterministic construction

Index construction is deterministic: given the same inputs, parameters, seed, format and implementation, the index body is byte-identical. That makes index artifacts repeatable and checkable rather than one-off files.

build 1inputsparamsseedformatimplbuild 2inputsparamsseedformatimplindex body: byte-identicalthe same five inputs
Identical bodies give identical hashes, so an index can be rebuilt and compared.

Source-bound attestation

Every index is cryptographically bound to its source data and build conditions. A binding hash ties the full input identity, the build parameters, the format version and the index body together.

shard identifiersgenerationsrow countscontent hashesjournal positionsbuild parametersformat versionindex body digestsealone binding hash
Change any one of the eight and the seal no longer matches: the index is a provable derived artifact, not a file.

Refuse rather than trust

Artifacts are checked at build, at persist and at load time, and publishing is allowed only when what reached the disk matches what was built in memory. A mismatch is a refusal, never a warning.

an artifact that matchesbuildpersistpublishloadservedan artifact that drifted on diskbuildpersistpublishrefused
A mismatch is never a warning. No silent failures, no stale indexes, no unverified data on the GPU.

Verified generations

All artifacts of a generation, centroids, members and derived data, are verified together before the generation is activated, so readers never see a torn set.

one generationcentroids · g41members · g41derived · g41activateda torn setcentroids · g42members · g41derived · g42rejected: never activatedat most one generation is active for an index at a time
Generation numbers illustrative. Readers never observe a partially updated index.

Journal-bound windows

Data windows are sealed with a content hash and a journal sequence, and consumers re-verify them before use.

journal, append-onlysealed window: content hash + journal sequenceafter transfer, re-hashedmatch: usedmismatch: refused
The payload rows, their identifiers and the journal entries must all line up before the seal is made.

One GPU read, two computations

The retrieval does two computations from one read: each member vector is read from GPU memory once and feeds both the similarity score and the cluster-health metrics.

two readsread vectorsimilarity scoreread vector againcluster healthone readread vector oncesimilarity scorecentroid distanceone read per member vector
The health side band is reduced on the device.

Cluster health beside every result

The health metrics are the mean distance to the centroid, the mean squared distance, and two bounded health scores derived from them, so results carry both what is closest and how coherent the region was.

health, bounded between 0 and 1: falls as mean distance and mean squared distance to the centroid grow
A result says what is closest and how coherent the region was.

Lineage that survives partial failure

Results and health metrics carry the same lineage even when one component fails, so the relationship between a result and its health computation is never lost.

retrieval resultLhealth resultfailedLsame lineage on both, even when one part fails

Residency keyed by generation

GPU memory tracks which data generations it holds and evicts only the artifacts a change affected, never the whole cache.

GPU memoryindex A · gen 17index A · gen 17index B · gen 5index A · gen 17index C · gen 12index B · gen 5index C · gen 12index A · gen 17index B · gen 5index C · gen 12index A · gen 17index C · gen 12generation 17 superseded: only its keys are evicted, the rest stays resident
Index letters and generation numbers illustrative. Keys carry catalog identity, so a lifecycle change invalidates exactly the state it changed.

From an authoritative source through deterministic materialisation and attestable indexes to GPU retrieval with provenance, the same data gives the same result along a path that can be checked from source to answer.

Every boundary is identifiable, verifiable, or refused.