varshith17

I've published a paper on a fundamental problem in AI systems that I believe has significant implications for our work: "Valori: A Deterministic Memory Substrate for AI Systems." [https://arxiv.org/pdf/2512.22280]

THE PROBLEM :

AI systems have unreliable memory.

When you run the same AI agent twice with the same input, it can give you different answers not because the AI is "thinking differently," but because the underlying memory system is non-deterministic.

In simple terms, the math used in building current vector databases (FAISS, Qdrant, Milvus, Pinecone, etc.) is floating-point arithmetic, which behaves differently across CPUs (x86, ARM, Mac, Windows). This is a universal problem acknowledged by industry leaders, including the FAISS team: https://github.com/facebookresearch/faiss/issues/4739

THE SOLUTION (What I Built) :

Valori: A deterministic memory substrate for AI systems.

In simple terms, I replaced floating-point math with fixed-point arithmetic (Q16.16) and built the memory engine using Rust (no_std).

Traditional systems store state (the answer). Valori stores events (how we got the answer).

This means you can:

Replay any decision exactly, Debug across different machines, Audit with mathematical certainty, Prove compliance to regulators

USE CASES (Where This Matters) Simply put, wherever we need bit-level replay, Valori can be applied:

Compliance & Audit (Financial Services), Incident Investigation (SRE/DevOps), Multi-Agent Systems (Autonomous Operations), Quantitative Finance (Hedge Funds), AI Safety & Alignment (Research), Healthcare AI (Medical Decisions)

I'd be happy to discuss this further and explore potential applications. Open to answer any doubts, questions, Criticism and Feedback

We talk a lot about shipping features, but I want to hear the war stories.

I spent almost a month chasing a silent data corruption issue that turned out to be floating-point non-determinism between x86 and ARM chips. It completely changed how I look at "reliable" memory.

What was your "white whale" bug of the year?

I spent the last week chasing a "ghost" in a RAG pipeline and I think I’ve found something that the industry is collectively ignoring.

We assume that if we generate an embedding and store it, the "memory" is stable. But I found that f32 distance calculations (the backbone of FAISS, Chroma, etc.) act as a "Forking Path."

If you run the exact same insertion sequence on an x86 server (AVX-512) and an ARM MacBook (NEON), the memory states diverge at the bit level. It’s not just "floating point noise" it’s a deterministic drift caused by FMA (Fused Multiply-Add) instruction differences.

I wrote a script to inspect the raw bits of a sentence-transformers vector across my M3 Max and a Xeon instance. Semantic similarity was 0.9999, but the raw storage was different

For a regulated AI agent (Finance/Healthcare), this is a nightmare. It means your audit trail is technically hallucinating depending on which server processed the query. You cannot have "Write Once, Run Anywhere" index portability.

The Fix (Going no_std) I got so frustrated that I bypassed the standard libraries and wrote a custom kernel (Valori) in Rust using Q16.16 Fixed-Point Arithmetic. By strictly enforcing integer associativity, I got 100% bit-identical snapshots across x86, ARM, and WASM.

Recall Loss: Negligible (99.8% Recall@10 vs standard f32).

Performance: < 500µs latency (comparable to unoptimized f32).

The Ask / Paper I’ve written a formal preprint analyzing this "Forking Path" problem and the Q16.16 proofs. I am currently trying to submit it to arXiv (Distributed Computing / cs.DC) but I'm stuck in the endorsement queue.

If you want to tear apart my Rust code: https://github.com/varshith-Git/Valori-Kernel

If you are an arXiv endorser for cs.DC (or cs.DB) and want to see the draft, I’d love to send it to you.

Am I the only one worried about building "reliable" agents on such shaky numerical foundations?