The Journey

Five nodes. One obsession with determinism, followed through sorting, storage, and search.

Nov 2025 – Jan 2026

The Sorting Obsession

  1. Work begins
  2. v-alpha · PCMP prototype
  3. Version 1

It started with a simple, stubborn question: can the theoretical floor of O(n log n) be broken?

I spent weeks in the trenches of sorting algorithms. When I finally broke past the standard comparison-based limits, I didn’t stop. A new question took over: what if the data could compress while it sorted? Not as a separate step after the fact, but as an integrated part of the ordering process.

And then came the idea that most engineers would call impossible: unsort.

If I take an array, sort it, and compress it, can I perfectly reconstruct the original array, byte for byte? Not a lossy approximation. The exact original sequence.

By December 2025, I had a working prototype. I called it PCMP (Predictive Canonical Monotonic Permutation). It did all three: sort, compress, and perfectly unsort.

But when I started stress-testing it against chaotic, real-world data, I hit the edges of IEEE-754 floating-point math. I discovered that NaNs and signed zeros behave inconsistently across different hardware architectures. A file that worked on my local machine produced a different cryptographic hash on a remote server. If the math couldn’t be trusted to produce the exact same bits everywhere, the “perfect reconstruction” guarantee was useless.

So I designed a strict version: SPCMP.

I forced the edge cases into fixed canonical states. All NaN payloads collapsed into a single quiet NaN. Negative zero collapsed into positive zero. Suddenly, the chaos was gone.

I didn’t just have a fast sorting algorithm anymore. I had a float32 container that was cryptographically verifiable across any hardware. It was no longer just about speed. It was about absolute, mathematical truth.

Mar 2026 – early Apr 2026

The Zero-Trust Cloud

I didn’t just want a place to store files. I wanted to build a system where the server itself couldn’t lie to you.

I built Samayuktam Cloud as a completely tamper-evident archival platform. Every file uploaded was chunked, hashed, and bound to a Merkle tree. If even a single byte of the file was altered on the server, the Merkle root would break, and the verification would fail.

But the real breakthrough was the cryptographic deduplication. If User A uploaded a file, and User B tried to upload the exact same file under a different name, the system caught it immediately. The hashes matched. The file was stored once, and the Merkle proofs guaranteed it was identical.

The platform ran live on Hugging Face Spaces until a change in their Docker hosting policies forced the servers offline. The code, the specs, and the cryptographic verifiers still exist in the repository, waiting for the right infrastructure to be redeployed.

Even the admin couldn’t alter a file without breaking the proof. The math was the ultimate authority.

Login
01Login
Admin interface
02Admin interface
What you share
03What you share
Viewing display
04Viewing display
File security and trace log
05File security and trace log
Feb – Mar 2026

Deterministic Search

Traditional AI search is probabilistic. You ask a question, and the system uses Approximate Nearest Neighbor (ANN) algorithms to find the “closest” match. Run the same query twice, and the order of the results might shuffle slightly because the floating-point math underneath shifted. In enterprise systems, “approximate” is not good enough.

I built a Deterministic Semantic Search Engine to prove that AI could be auditable.

It used text embeddings to understand the meaning of a query, but the retrieval was entirely deterministic. It relied on strict canonical float ordering, cache-stable binary search windows, and cryptographic hashing to guarantee that the same query against the same index would return the exact same results, every single time.

I ran a replay harness of 30,000 unique queries across independent process invocations. Zero result-hash mismatches.

I didn’t just build a search engine. I built a system that could hand you a cryptographic Merkle proof alongside the search results, proving mathematically that the output you received was the exact same computation the system performed.

FADS page
Citing sources of a search
Apr – May 2026

CAGM

Building the search engine taught me a hard truth about modern AI: if the underlying floating-point math drifts across hardware, the AI is fundamentally unauditable.

I realized the same problem that plagued search was quietly destroying machine learning. When you train a model, the exact order of floating-point operations depends on the hardware it runs on. Train the same model on an NVIDIA GPU and an AMD CPU, and you get slightly different weights.

For a recommendation algorithm, a tiny drift doesn’t matter. But for medical diagnostics, flight simulation, or safety-critical systems, it is a disaster. If the model trained in the cloud says 94% and the model on the physical hardware says 91%, which one do you trust? How do you prove they are the same model?

I built CAGM to solve this.

CAGM is a fixed-point integer ML classifier. There is no floating-point math anywhere in the training loop. The weights, the gradients, the activations, and the optimizer are all strictly integer-based.

Because of this, CAGM doesn’t just train a model. It emits a 64-character SHA-256 proof of the entire training trajectory. Every epoch, every gradient update is cryptographically bound into a Merkle tree.

If you train the exact same dataset on different hardware, the output is bit-identical. The 64-character proof string will match perfectly on an Intel CPU, an AMD CPU, an NVIDIA GPU, and a Google TPU.

CAGM makes machine learning not only deterministic but cryptographically auditable. It proves exactly how a model was trained, without ever exposing the underlying data or the model weights.

CAGM Cross-Device Benchmark Report: accuracy and proof hashes identical across four machines
mid Aug 2026 – early Sep 2026

The Vendor Trail

I stopped trying to pitch individuals and went straight to the source. I filed a float32 divergence finding, with a public reproducer, directly with the security and engineering divisions of the world’s largest hardware vendors. The CPU result in that reproducer was later retracted after I found a fault in my own harness. The vendor positions below concern floating-point behavior in general, not that result.

The responses were consistent.

Vendor / ChannelResponse
NVIDIABug Triage

Reviewed the CUDA reproducer and replied that the differences come from different execution paths, such as FMA versus non-FMA and fast versus accurate math functions. These are expected, and not an NVIDIA SDK defect. NVIDIA declined to certify the results and pointed to its documentation.

MicrosoftMSRC

Closed the report as a non-MSRC case.

AMDPSIRT

Treated the report as outside security triage.

IntelPSIRT

Treated the report as outside security triage.

What this evidence is worth

NVIDIA’s documentation explicitly states that IEEE 754 does not guarantee bit-identical results across platforms. The other vendors treated the report as outside their security triage. The problem spans silicon, compilers, and math libraries, so no single vendor controls all of it.

That is the opening for a vendor-neutral canonicalization layer.

That is what Samayuktam provides.