-
Notifications
You must be signed in to change notification settings - Fork 2
The Deterministic Memory Problem
Valori originated from a simple experiment.
A Python-based vector engine was run on:
- macOS ARM (Apple Silicon)
- Linux x86
The same:
- embeddings
- vectors
- code
- model
- seed
And yet — the output diverged.
The divergence did not appear during retrieval or indexing.
It appeared at ingestion.
At the moment embeddings touched the substrate, the memory world-line split.
Memory state is not only a data structure —
it is an artifact of the substrate it runs on.
Floating-point behavior varies with:
- instruction pipelines
- fused-multiply-add rules
- rounding modes
- register widths
- reduction order
Two executions that appear “identical” do not evolve the same state.
This breaks:
- deterministic replay
- compliance verification
- safety analysis
- cross-hardware reproducibility
- forensic traceability
In regulated computing environments, that is unacceptable.
Valori was built to constrain the substrate.
Valori Kernel — Deterministic Substrate Execution Layer
This project focuses on:
- deterministic ingestion
- replayable state evolution
- cross-substrate execution invariance
The kernel is provided as an open research foundation. Application-layer evaluators are developed separately.
If you are evaluating Valori for:
- research
- safety audits
- compliance replay
- deterministic analytics
- embedded or robotics compute
we encourage you to reach out or open a discussion.
Research Paper: https://arxiv.org/abs/2512.22280
- Valori Kernel — Project Overview
- The Deterministic Memory Problem
- Why Fixed‐Point Arithmetic
- Kernel Architecture
-
Project Repository
https://github.com/varshith-Git/Valori-Kernel -
Research Paper (arXiv)
https://arxiv.org/abs/2512.22280 -
HuggingFace https://huggingface.co/papers/2512.22280
- Issues & Discussions
https://github.com/varshith-Git/Valori-Kernel/issues