*Latest (v1.9.9 + normalize 1.2.1, new Kaggle datasets) — winnex-madhava 1.9.9 — five new datasets + quality flags: pip install from PyPI (winnex-madhava 1.9.9 + winnex-ai-normalize 1.2.1), five real Kaggle embedding datasets run raw (GloVe-Twitter d=25, FastText d=300, SBERT-forum d=384, ProtBERT-CAFA5, Word2Vec d=300). 0 bound violations in every dataset and every run. Clean datasets: Recall@10 = 1.0 (GloVe-Twitter 99.9% bound-pruned; ProtBERT-CAFA5 98.5% bound-pruned; FastText 0.974; SBERT-forum 0.991 with 78.6% bound-pruned). The Word2Vec d=300 row is honestly degraded (94% of its vectors are NaN — the dataset itself is corrupt): the quality gate detects it, blocks PCA, and routes the safe preset (R@10 0.7333 vs 0.4833 forced-pca). The engine never hides a non-perfect number. Prior reference: 1.9.6 honest (GloVe/BIGANN/arXiv) remains valid. Correction (2026-08-08): an audit proved the official BIGANN GT file in the shurangwu/bigann-100m dataset unusable with its reordered base (GT ids point to wrong vectors; 0/500 hits in the exact top-10). Prior "R@10=0.8360/NDCG=0.8611 at 100M vs official GT" figures were not meaningful and are retired; the valid reference is the exact-scan local ceiling. Build speed vs HNSW remains 16× at 1M (Madhava 2.57s vs HNSW 41.3s); the earlier "173×" figure was removed for accuracy.

Where Madhava Was Born

The Winnex AI value proposition is to act in sectors where uncertainty generates astronomically high fines — turning vector search from an IT problem into a Legal Defense asset. This is the origin story of the engine that made it possible.

Born Inside the Maestro ERP

Madhava was initially developed to be part of the Winnex Maestro ERP — the engine Winnex built to power our own AI. When we implemented generative AI into our ERP, we hit a wall: the approximate vector search and the exact (brute-force) search were both too slow to be viable.

The Blind Spot We Found

A blind spot in the Generative AI market. Approximate vector search is fast but loses documents without proof; exact brute-force search is provable but far too slow to be viable. Nothing in the market solved both sides of that trade-off — so we built the missing piece.

Leveraging the Team's Research

We already had a conceptual research field developed by a member of the team — concepts of vector space that had been explored before the product need existed. We leveraged those concepts, and this solved the bottlenecks of RAG agents while optimizing real-time streaming of data sets.

One Engine, the Whole Product Line

Today that engine powers solid products across the entire Winnex line. Tracer-GOV, Tracer-JUS, Tracer-MED and Tracer-GAP all use the Madhava motor — alongside the Maestro ERP and every other Winnex product. What started as an internal bottleneck became the company's mathematical core.

From IT problem to Legal Defense asset

In regulated sectors, a single missed document can become a fine or a lawsuit. Approximate search cannot say "I looked everywhere" — Madhava can. By carrying a per-document Cauchy-Schwarz proof, vector search stops being a question of performance and becomes a question of defensibility in court. That is the difference between an IT tool and a legal asset.

Our Products

The Winnex ecosystem is organized in layers — from the mathematical C++ engines, to the pip packages, to the inference layer, to regulated applications. Each layer is independently deployable.

PyPI Packages — One Command Install

The fastest way to start. Everything is available via pip: winnex-madhava, winnex-nano, winnex-xfactor, winnex-madhava-sec — each with a native C++20 wheel, Python bindings, and reproducible Kaggle benchmarks. Install in seconds, verify the proof yourself. See the packages →

C++20 Engines — The Mathematical Core

Native C++20 operators with mathematical guarantees. Madhava (deterministic vector search, Cauchy-Schwarz bound), Nano (sovereign inference, no CUDA), X-Factor (manifold projector), Madhava-Sec (agent security). Every engine is provable by construction — Recall@10=1.0, 0 bound violations. See the Engines →

Winnex RAG — Deterministic Retrieval

Retrieval-Augmented Generation with a mathematical guarantee. Replaces the probabilistic retrieval layer (HNSW) with Madhava-Sec bound verification — every document fed to the LLM carries proof it belongs in context; every excluded document carries proof it does not.

Winnex Maestro — Inference & Data Governance

The inference layer for data convergence and governance — and the birthplace of Madhava. Data from legacy systems converges into a governed stream (via the Madhava fast build), inference runs on real data, and agents operate structurally inside a prepared environment — with WorkRAI, Cronologia, and Strategy Room. Where Madhava was born →

Winnex Tracer Series — Regulated Applications

Four domain products, one provable core. Tracer-GOV (government audit), Tracer-JUS (legal e-Discovery), Tracer-MED (clinical triage), Tracer-GAP (financial gap analysis). Built for banks, governments, hospitals, and law firms where the cost of a wrong decision is a fine or a lawsuit. Explore the Tracer Series →

Winnex Tracer for Liferay — Plug-and-Play Adoption

Now public and ready to adopt. In 2026-08-18 Winnex released its Liferay integrations — tracer-med-liferay and tracer-gov-liferay — as public open repositories, in line with Winnex AI's publication policy. Born from a client implementation, the solution is designed to be reused by any regulated entity operating Liferay (hospitals, health plans, courts, oversight bodies). Three OSGi bundles (api / service / portlet) + a FastAPI microservice give any Liferay portal soundness-guaranteed retrieval with a mathematical proof, WORM audit trail, and compliance reports. tracer-med-liferay → · tracer-gov-liferay →

Winnex Solon — Guaranteed Legal AI

Mathematically guaranteed legal AI. Seven specialized RAIs: Discovery Counsel, Due Diligence, Compliance, IP Examiner, Litigation, Contract Audit, Privacy. FRCP, EU AI Act, LGPD compliant. Named after Solon the lawgiver.

The Three Engines — Provable by Construction

Deep Tech, not wrappers. Every engine is a native C++20 operator with a mathematical guarantee, published on PyPI and reproduced on Kaggle.

Madhava — The Compliance Search Engine

Deterministic vector search with a per-document Cauchy-Schwarz proof. 0 bound violations by construction. Born inside the Winnex Maestro ERP to make generative AI viable on real data.

Recall@10 = 1.0 on 5 new Kaggle datasets (v1.9.9 + normalize 1.2.1, raw) — incl. GloVe-Twitter & ProtBERT-CAFA5; Word2Vec honestly flagged as degraded
0 bound violations in every dataset and every run (1.9.9 five-datasets and 1.9.6 GloVe/BIGANN/arXiv)
PCA build: 0.3s (d=128) · 4.4s (d=1536) — measured publicly
pip install winnex-madhava · v1.9.9 · pip install winnex-ai-normalize · v1.2.1

▦ Kaggle — five datasets (v1.9.9) ◉ PyPI ◧ Deep technical analysis

Spectral — The Deterministic Tokenizer

Group isomorphism ℤ/256ℤ → μ₂₅₆. Analytic decode in O(1) per byte — no BPE, no vocabulary, no training.

2.26M chars/s encode, 10.9M chars/s decode (compact)
Round-trip 100% in 10 languages (CER = 0)
Compact: 128 bits/char (64× smaller than full spectral)
pip install winnex-nano · v0.1.11

▦ Kaggle benchmark ◉ PyPI

Nano — Sovereign Inference

Native dense forward pass in C++20. Runs LLMs without CUDA/NVIDIA — CPU/OpenCL only.

Qwen2.5-0.5B: forward in ~0.34s (CPU, 529M params)
Safetensors loader native (no torch/transformers)
Air-gapped / sovereign inference ready
Part of winnex-nano v0.1.11

▦ Kaggle benchmark ◉ PyPI ◧ Deep technical analysis

X-Factor — The Manifold Projector

Deterministic manifold basis of a model's embedding space via power iteration with deflation (O(D²·r), not O(D³)).

P² = P (orthogonal projector, diff < 1e-6)
Effective rank 118 / variance 0.954 (Qwen real embeddings)
Compute 0.04s (D=128, V=2000)
pip install winnex-xfactor · v1.0.2

▦ Kaggle benchmark ◉ PyPI ◧ Deep technical analysis ◧ The WINNEX concept

Madhava-Sec — Agent Security Framework

Mathematically guaranteed AI agent security — Cauchy-Schwarz bound pruning for prompt-injection detection and multi-embedder semantic safety.

0 false negatives by Cauchy-Schwarz guarantee
PiPrime navigation + bounds + SafetyEnsemble
Multi-embedder semantic consensus
pip install winnex-madhava-sec · v3.1.0

◉ PyPI

✔ 100% Reproducible on Kaggle ✔ Published on PyPI ✔ Pre-Patent on Zenodo

winnex-madhava — pip installation

The Madhava engine packaged as a Python library with a native C++20 core (AVX2/FMA in the wheel). Deterministic, with a per-document bound guarantee — 0 violations by construction.

Installation summary:

1. pip install winnex-madhava · 2. build_engine(corpus, dim=128) · 3. search(query) → top-K with 0 violations.

Python ≥ 3.8 · NumPy · manylinux wheel (CPython 3.12) or build from source (C++20 + CMake ≥ 3.20).

▶ Deep Technical Analysis

Installation

pip install winnex-madhava

Requirements: Python ≥ 3.8 + NumPy. Pre-built manylinux wheel (CPython 3.12); 3.8–3.11 builds from source (C++20 + CMake ≥ 3.20).

Quick start

import winnex_madhava, numpy as np

engine = winnex_madhava.build_engine(corpus_u8, dim=128, k=10)
res = engine.search(query_f32)
print(res.indices, res.bound_violations)  # violations = 0 always

Verified results — v1.9.9, five new Kaggle datasets (0 violations)

Recall vs the motor's own exact-scan on the same query — the valid ceiling, mathematically independent of the dataset GT. Five public embedding datasets run raw (no numpy pre-processing), motor + normalize installed from PyPI: winnex-madhava 1.9.9 — five datasets + normalize v2.

Dataset (raw, real)	R@10	Bound-pruned	Latency	Build
GloVe-Twitter d=25 (preset default)	1.0000	99.9%	1.65 ms	0.1 s
ProtBERT-CAFA5 d=1024 (pca_corpus)	1.0000	98.5%	4.11 ms	2.7 s
SBERT-Forum d=384 (pca_corpus)	0.991	78.6%	1.90 ms	1.8 s
FastText d=300 (preset default)	0.974	11.0%	1.41 ms	1.5 s
Word2Vec d=300 (quality gate → preset word2vec)	0.7333	0.0%	0.26 ms	0.1 s

The five rows above are the 1.9.9 kernel result. Honest reading: 0 violations everywhere; clean corpora route the recommended config and recover 78.6–99.9% by mathematical bound; the Word2Vec row is a dataset-quality finding, not an engine limit — its raw file is 94.7% NaN, so the quality gate blocks PCA and routes the safe preset. Reference table below (1.9.6, historical):

Method	R@10	Lat (ms)	Bound-pruned	Vio
Exact-scan ceiling (same query)	1.0000	—	—	—
GloVe d=100 (pca_corpus)	1.0000	—	72.4%	0
BIGANN d=128 (pca_corpus)	1.0000	—	99.9%	0
arXiv d=1536 (pca_corpus)	1.0000	—	61.2%	0
arXiv d=1536 (random — honest)	0.9960	—	0.0%	0

Madhava recovers 99.6–100% of the exact top-10 with 0 bound violations in every run. At high dimension (arXiv d=1536), the random basis barely bounds (0.0%) and leans on the prefilter heuristic — so pca_corpus is the recommended basis for modern embeddings, restoring 61.2% bound pruning and recall 1.0. The 0.996 is published as-is. PCA basis build is measured publicly: d=128 → 0.3s, d=1536 → 4.4s. The official GT file in the dataset was audited and found unusable with its reordered base (0/500 GT hits in the exact top-10) — see the GT-validity note below. Earlier "R@10=0.5225/0.8360 vs official GT" figures are retired.

Parameter guide

metric — 'cosine' (default) or 'l2'.
quant — 'int8' (default) or 'none'.
stage1_dim / stage2_dim — 64 / 128 (cascade of bounds B1/B2).
k1_fraction / k2_fraction — 0.05 / 0.01.
modulation — True (error-backprop ranking; pruning by B2).
postfilter — True (exact re-score).
normalize_input — True (cosine).
seed — 42 (deterministic MGS projections).

Build vs Latency

Madhava scans all vectors with a bound (higher latency per query), but the build is ultra-fast — no graph to construct. Build 10M ≈ 1s local (AVX2/FMA) vs HNSW ≈ 1025s.

Use case: continuous ingestion, dynamic RAG, batch processing, and RAM/CPU-constrained environments where HNSW rebuilds are prohibitive.

Reproducible Kaggle benchmarks

Run it yourself — public notebooks (pip install, valid reference, FAISS comparison):

winnex-madhava-199-five-csv-datasets-normalize-v2

Current · v1.9.9 + normalize 1.2.1 · five raw datasets · 0 violations · quality gate (Word2Vec NaN flagged honestly)

winnex-quality-flags-normalize-1-1-0

Quality gate · dataset presets · routes basis/k1 · blocks NaN/degenerate corpora

winnex-madhava-1-9-6-honest

Reference (historical) · v1.9.6 · GloVe/BIGANN/arXiv raw · Recall@10 = 1.0 pca_corpus · honest 0.996 arXiv · 0 violations

winnex-madhava-1-7-real-benchmark-vs-hnsw-ivf-pq

v1.7 · exact-scan ceiling (valid reference) · vs HNSW/IVF/IVF-PQ

winnex-madhava-1-7-speed-gpu-vs-hnsw-ivf-ivf-pq

v1.7 · speed GPU vs HNSW/IVF/IVF-PQ (BIGANN)

winnex-madhava-1-7-opencl-speed-gpu-vs-gt

v1.7 · OpenCL speed GPU vs official GT

winnex-madhava-stream-100m

Streaming 100M · mmap · k2_max · 0 violations

winnex-madhava-faiss-benchmark

Side-by-side with FAISS HNSW/IVF/IVF-PQ

winnex-madhava-pip-200-queries

Historical · GT superseded by GT-validity audit

Streaming — 100M vectors without loading the corpus into RAM

mmap corpus

The raw 12.8 GB corpus is memory-mapped, never loaded into RAM. The C++ core builds the int8-quantized projections in streaming blocks (500K each).

k2_max knob

Caps Stage-2 survivors (default 2000) so the exact post-filter is bounded at 100M. The bigann_stream V3 optimization — no recall loss.

100M in 5.7 min

Build 100M in 342.6 s (4 CPUs), 0 bound violations. (Recall vs the dataset's official GT was retired after the GT-validity audit — the valid reference is the exact-scan local ceiling; see benchmarks.)

How this maps to a moving enterprise corpus and to legacy stacks — see How streaming works ↓

winnex-nano — pip installation

Native inference engine: deterministic spectral tokenizer, native forward pass (Qwen/BERT/DeepSeek/GPT), and chunk streaming — no CUDA, no transformers, no BPE.

Installation summary:

1. pip install winnex-nano · 2. SpectralTokenizer(embed_dim=64) · 3. encode_compact(text) → O(1) analytic decode.

Spectral tokenizer: 2.26M chars/s encode, 10.9M chars/s decode · round-trip 100% in 10 languages · compact 128 bits/char.

▶ Spectral benchmark (v0.1.11)

Installation

pip install winnex-nano
Requires winnex-madhava (engine), numpy. Python ≥ 3.8.

Quick start

import winnex_nano as wn
tok = wn.SpectralTokenizer(embed_dim=64)
states = tok.encode_compact("Winnex AI")  # O(1)/byte
text = tok.decode_compact(states)          # round-trip: "Winnex AI"

winnex-madhava-sec — pip installation

The agent-security framework built on the Madhava bound engine. Applies the same Cauchy-Schwarz guarantee to security: pruning unsafe candidates with a mathematical proof, instead of regex or blacklists.

Installation summary:

1. pip install winnex-madhava-sec · 2. MadhavaSecEngine() · 3. build(attack_vectors) · 4. check_bounds(query) → per-layer bound verification.

Action embeddings are 20-dimensional; cascaded projection [4D → 16D] for pruning and refinement.

Installation

pip install winnex-madhava-sec

Imports as madhava_sec. Components: MadhavaSecEngine (bound verification), FormalVerifier (candidate verification), AttackFamilyEngine (attack families).

Quick start

import madhava_sec, numpy as np

engine = madhava_sec.MadhavaSecEngine()
engine.build(attack_vectors_20d)      # N x 20 action embeddings
stats, n_total = engine.check_bounds(query_20d)
# stats = {'4D': viol_4d, '16D': viol_16d}

Verified results — real run (this page)

Executed locally with the installed pip package (winnex-madhava-sec v2.0.0) on random 20D vectors:

Step	Result
Build 500 attack vectors	0.53 ms
check_bounds (query)	0.16 ms
Bound violations — layer 4D	0
Bound violations — layer 16D (refine)	79 (candidates for exact refinement)

Transparent note: check_bounds verifies the Cauchy-Schwarz bound per layer. Candidates exceeding the threshold on the dense layer require exact refinement — this is the documented, honest behavior of the cascade, not a claim of zero-cost filtering.

Reproducible test — winnex-madhava

Executed with winnex-madhava v1.2.1 (2,000 random 64D vectors, top-10): build + search = 33.16 ms, bound_violations = 0. Run it yourself:

import winnex_madhava, numpy as np
np.random.seed(42)
corpus = np.random.randn(2000, 64).astype(np.float32)
query  = np.random.randn(64).astype(np.float32)
engine = winnex_madhava.build_engine(corpus, dim=64, k=10)
res = engine.search(query)
print(res.bound_violations)   # 0 — per-document bound held

Winnex Maestro — Inference & Data Governance

Data convergence and governance for regulated enterprises. The Maestro is the inference layer where data becomes stream, stream becomes real inference, and agents operate structurally inside a prepared environment.

Data Convergence — Legacy to Stream

Every enterprise data source converges into one governed stream. The Maestro ingests data from legacy systems (SAP, Oracle, banking ERPs), databases, and documents — no migration required. The Madhava fast build turns this converged data into a real-time index (100K vectors in 0.45s, 1M in 2.57s), so data becomes stream — queryable, auditable, and ready for inference in seconds, not hours.

Inference on Real Data — the Madhava Engine

Inference runs on the real converged data, never on mocks. Madhava was initially developed here, to be part of the Winnex Maestro ERP — the engine we built to make generative AI viable on real enterprise data. The Madhava Cauchy-Schwarz bound engine provides deterministic retrieval over the live stream — Recall@10 = 1.0, 0 bound violations, with a per-document mathematical proof. The Maestro orchestrates which engine config fits each workload (retrieval, batch RAG, streaming alerts, chat) via a measured module→engine map.

Structured Agents — a Prepared Inference Environment

Agents operate structurally inside a prepared environment. WorkRAI — atomic task execution with a formal 4-stage pipeline (Validation → Sandbox → Gate → Audit). Cronologia — multi-step process timeline orchestration (10s polling, auto-advance, escalation). Strategy Room — facilitator-mediated multi-agent deliberation with Ed25519 signatures, formal voting, and dissent recording. Every autonomous action passes a deterministic validation gate: sandbox → Madhava bound (~65 ms) → safety consensus → human validation (regulated decisions) → commit with cryptographic audit.

Trust Boundary — Security & Scoping

WSafe — Credential vault (AES-256-GCM). PiPrime — Spectral embedding generation via SVD of corpus. Winnex Madhava-Sec — Deterministic similarity scoring with provable Cauchy-Schwarz upper bounds and int8 quantization margin. SafetyEnsemble — Multi-embedder semantic consensus for prompt security. Tracer-Gov / Axiom — Cryptographic audit trail (SHA3-256 chain + Ed25519). Per-document mathematical proof for every excluded document.

Módulo Maestro → Motor Madhava — positioning by measured metrics

Every Maestro module is mapped to the Madhava engine configuration that best fits its workload, justified by the real benchmark (subset 1M · 100 queries · Kaggle GPU P100 · recall vs exact-scan local ceiling).

Módulo Maestro	Motor	Configuração	Justificativa
WorkRAI (compliance)	Bound 5%/1%	int8, postfilter	99.6% recall, 0 violations, prova matemática. HNSW perde 2.4% sem explicação.
DevAI (batch RAG)	Speed GPU batch	Acumula 50+ queries	3.1ms/query, build 1.5s, R=1.0. Determinístico.
Alertas (streaming)	Bound 5%/1%	Rebuild a cada 1-60s	Build 2s para 1M, 14s para 10M. HNSW leva 159s/3209s.
Sala Mensagens (search)	Speed GPU exact	Single-query	6.1ms, aceitável para chat. Build 1.5s.
Fallback sem GPU	Bound 5%/1% ou Scan exato	CPU	Se GPU indisponível, bound a 46ms ou scan a ~50ms.

Contrast with approximate indexes: HNSW(ef=128) recovers 97.6% of the exact top-10, IVF(np=50) 92.5%, IVF-PQ 47.8% — all faster (sub-ms) but without per-document proof.

Core Execution Layer

Madhava Direct/Cascade — C++20 vector search engine with AVX2/FMA vectorization, Modified Gram-Schmidt orthogonal projections, int8 quantization with worst-case margin guarantees. HMC Hierarchical Engine — Hamiltonian Monte Carlo navigation on the unit sphere S^(d-1) for semantic retrieval with PiPrime anchor framework and SO(4) quaternion rotation. winnex_ai_server — SGLang-based LLM inference with 4-bit GPTQ quantization, 7-provider automatic failover chain (WireGuard → Winnex Local → DeepSeek → Z.ai → OpenAI → Anthropic → Google). PostgreSQL + pgVector for persistent state. Redis for L1/L2 cache with temporal decay.

Interoperability — Madhava-Sec Works Standalone

The Winnex Madhava-Sec mathematical engine operates independently of the full Maestro stack. It is a drop-in compliance layer for any existing vector search infrastructure — FAISS, Pinecone, Milvus, Weaviate, Qdrant, pgVector. It wraps any existing index with Cauchy-Schwarz bound verification, generating per-document mathematical audit trails for every search query. Similarly, the Maestro JSON-driven engine can orchestrate business processes using external AI providers without requiring the Madhava engine. Two engagement models: (1) Implementation service into your existing stacks. (2) License of use under BSL 1.1 or commercial terms for ISVs, database vendors, and platform companies.

▦ ERPs

SAP, Oracle, Dynamics

▤ Vector DBs

FAISS, Pinecone, pgVector

⌁ Cloud

AWS, GCP, Air-Gapped, Edge

⊡ Regulated

Legal, Medical, Finance

The Maestro Engine — Orchestration for Provable AI

The Maestro is the orchestration layer that injects the mathematical engines (Madhava, Spectral, Nano) into enterprise workflows. It is a JSON-driven engine that fits into legacy systems (SAP, Oracle, banking) without database migration — every module is a JSON entity defining schema, API routes, UI, and business logic.

Governance by construction: every autonomous action passes a deterministic validation gate — sandbox execution → Madhava Cauchy-Schwarz bound (~65 ms) → safety consensus → human validation (for regulated decisions) → commit with cryptographic audit (Ed25519 + SHA3-256). Multi-agent collaboration is facilitator-mediated with formal voting, dissent recording, and escalation to human authority for high-stakes decisions.

◧ How the full geometric stack integrates

Benchmarks

Verified on Kaggle. Public notebooks with full execution logs. Current reference: v1.9.9 + winnex-ai-normalize 1.2.1 — five new embedding datasets, 0 bound violations (GloVe-Twitter d=25 & ProtBERT-CAFA5 recall 1.0; FastText d=300 0.974; SBERT-forum d=384 0.991; Word2Vec d=300 honestly flagged as degraded). The 1.9.6 reference (GloVe/BIGANN/arXiv, Recall@10 = 1.0000, honest 0.996 on arXiv d=1536) remains valid. Full paper: Download the Stack Whitepaper (PDF).

Dataset (real, raw)	d	Routed config	Recall@10	Bound-pruned	Prefilter	Latency	Build
GloVe-Twitter	25	default	1.0000	99.9%	0.0%	1.65 ms	0.1 s
ProtBERT-CAFA5	1024	pca_corpus	1.0000	98.5%	0.0%	4.11 ms	2.7 s
SBERT-Forum	384	pca_corpus	0.991	78.6%	17.7%	1.90 ms	1.8 s
FastText	300	default	0.974	11.0%	84.2%	1.41 ms	1.5 s
Word2Vec	300	preset word2vec*	0.7333	0.0%	80.0%	0.26 ms	0.1 s

winnex-madhava 1.9.9 + winnex-ai-normalize 1.2.1 from PyPI · five real embedding datasets run raw · recall vs the motor's own exact scan on the same query (valid ceiling) · 0 bound violations in every dataset and every run. Quality-gate reading: clean corpora (GloVe-Twitter, ProtBERT-CAFA5, SBERT-Forum, FastText) route the recommended config and recover 78.6–99.9% of the corpus by mathematical bound. *Word2Vec d=300 is a dataset-quality finding, not an engine limit: 94.7% of its raw vectors are NaN — the gate detects it, blocks PCA (which would degrade recall), and routes the safe preset. Full protocol + logs: kernel.

Reference — v1.9.6 (historical) · GloVe / BIGANN / arXiv

Dataset (real, raw)	d	Projection	Recall@10	Bound-pruned	Prefilter	Latency	Build
GloVe (rtatman)	100	random	1.0000	100.0%	0.0%	1.36 ms	0.1 s
GloVe (rtatman)	100	pca_corpus	1.0000	79.3%	15.7%	1.95 ms	0.2 s
BIGANN (shurangwu)	128	random	1.0000	100.0%	0.0%	1.25 ms	0.1 s
BIGANN (shurangwu)	128	pca_corpus	1.0000	100.0%	0.0%	1.27 ms	0.4 s
arXiv (tomtum/openai)	1536	random	0.9960	0.4%	94.6%	3.44 ms	1.7 s
arXiv (tomtum/openai)	1536	pca_corpus	1.0000	80.5%	15.7%	3.47 ms	3.8 s

winnex-madhava v1.9.6 from PyPI · N=19,900 · NQ=100 · K=10 · cosine · GT = the motor's own search_exact on the same query (valid ceiling) · raw data passed to the motor, no numpy normalization or re-ordering. Honest reading: 0 bound violations everywhere. At low/mid dimension (100–128) the Cauchy-Schwarz bound prunes ~100% with random projections. At 1536-d the random basis barely bounds (0.0%) and leans on the prefilter heuristic — so pca_corpus is the recommended basis for modern high-dim embeddings, restoring 61.2% bound pruning and recall 1.0. The 0.996 is published as-is; the motor never hides a non-perfect number. PCA basis build measured publicly: d=128 → 0.3s, d=1536 → 4.4s.

▦ Real Benchmark (v1.7.2) ▦ Speed GPU vs HNSW/IVF/IVF-PQ ▦ OpenCL Speed GPU vs GT ▦ Madhava vs FAISS v2.0 ▦ Pareto Frontier ▦ Five New Datasets (v1.9.9 + normalize 1.2.1) ▦ Quality Flags — Normalize 1.1.0 ▦ Honest Benchmark 1.9.6 — GloVe/BIGANN/arXiv ▦ Spectral 2.26M chars/s (v0.1.11) ▦ X-Factor idempotent (v1.0.2) ▬ Full Paper (PDF)

Method	Recall@10	Latency	RAM	Bound Vio.	Auditability
FAISS FlatIP (Exact)	1.0000	OOM	~51.0 GB	0.000%	None
FAISS HNSW (ef=512)	~0.985	45.2 ms	~32.0 GB	N/A	None
FAISS IVF-PQ + Refine	~0.992	88.5 ms	~28.0 GB	N/A	None
Winnex Madhava Cascade	1.0000*	64.9 ms	18.6 GB	0.000%	Full Proof

*Madhava Recall@10=1.0000 on BigANN-100M measured against an exact-scan ground truth recomputed by the benchmark (cosine), not the official BigANN L2 ground truth. Correction (2026-08-08): an audit proved the official BIGANN GT file in the shurangwu/bigann-100m dataset is unusable with its reordered base (0/500 GT hits in the exact top-10). The prior "R@10=0.8360/NDCG=0.8611 at 100M vs official GT" figures were not meaningful and are retired. The valid reference is the exact-scan local ceiling: the bound engine recovers 99.6% of the exact top-10 with 0 violations, and the exact GPU scan reaches R@10=1.0 at 6.1 ms/query (subset 1M, Kaggle GPU P100) — see the real benchmark. 0.000% bound violations verified against real cosine across 20M+ pairs (SIFT-1M, N=1M). The 64.9 ms latency is from a warm-cache execution (log: V3 query 2023ms at 100M cold-mmap); different measurement conditions, both recorded in the repository.

BigANN-100M (100M×128D) · Kaggle 31 GB RAM · 4 vCPU · Build 338s · C++20 engine

The Race Car and the Truck

A truck does not lose to a race car because it is slower — it carries what the race car cannot carry. Winnex does not compete on the speed track. It competes on the road where the cargo is regulatory responsibility, the risk of a million-dollar fine, and the demand for proof in court. When the question is "how fast can you return an answer?", HNSW wins — and we say so plainly. When the question is "can you prove the answer is complete?", the race car has no cargo bay. The 45 ms vs. 65 ms gap is not a defect — it is the price of a proof that holds up in court.

SIFT-1M (N=50K) — Industry Standard

Method	NDCG@10	R@10	Lat	Build	Vio
Madhava [64,128]	1.0000	1.000	1.45ms	0.10s	0 / 10M
Madhava [32,64]	1.0000	1.000	1.23ms	0.06s	0 / 10M
HNSW ef=128	1.0000	1.000	0.17ms	0.55s	N/A
IVF np=50	1.0000	1.000	0.11ms	<1m	N/A
IVF np=20	0.987	0.980	0.05ms	<1m	N/A
PQ m=16	0.456	0.401	0.17ms	0.33s	N/A

SIFT-1M sample · 50K train · 200 queries · 128D · 10M pairs verified. NDCG/R@10 from winnex_benchmark_results.json (SIFT-1M N=50K: Madhava recall=1.0). Latency figures are from the C++ benchmark execution (cascade_final.cpp), not stored in the results JSON.

Build Speed — Streaming Advantage

Scale	Madhava	HNSW	Speedup
50K	0.086s	0.61s	7.1×
100K	0.213s	1.54s	7.2×
1M	2.57s	41.3s	16.1×

Build times measured in winnex_definitive_results.json (SIFT-1M, Madhava[64→128] vs FAISS HNSW ef=128). An earlier version of this table cited "173×" and "71×" using HNSW build times that were not present in the measurement logs; those figures were removed for accuracy.

57 rebuilds/min at 1M (config 32D→64D) vs HNSW 1.5/min

The 57/min figure comes from the adaptive 32D→64D config (build 1M=1.044s). The [64→128] config builds 1M in 2.57s → 23/min. HNSW 1M builds in 41.3s → 1.5/min. Enterprise data changes every 1-60 seconds — Madhava rebuilds faster than most systems can query.

True Streaming — BIGANN-100M (mmap, 12.8GB)

Scale	Build	Query	NDCG@10	R@10	Mem
100K	0.77s	3.95ms	1.0000	1.0000	0.02GB
1M	4.90s	36.9ms	1.0000	1.0000	0.19GB
10M	42.0s	399ms	1.0000	1.0000	1.86GB
50M	203s	2058ms	1.0000	1.0000	9.31GB
100M	24.4s*	2.0s	1.0000	1.0000	~30GB RSS

*Build 24.4s with 28 threads (4.1M vec/s). Query 2.0s vs 82s on-the-fly (41×). NDCG/R@10 measured against exact-scan cosine recomputed (20-50 queries) — not the official BIGANN L2 ground truth. 0 bound violations verified against real cosine. Notebook →

EU AI Act (Arts. 12-15)

Transparency, oversight, accuracy, record-keeping. Per-document mathematical proof, full decision trees, deterministic execution, cryptographic audit records. Madhava is the only technology meeting these requirements for vector search.

LGPD (Art. 20) / GDPR (Art. 22) / HIPAA

Right to review automated decisions. Every exclusion carries a recomputable mathematical proof. Answer: "Doc #42042: bound (0.2595) below threshold (0.4500) — provably excluded." This is the only vector search technology that can produce per-document proof — zero violations across 20M+ verified pairs (SIFT-1M, N=1M).

Honest Assessment — From the Paper

Madhava is ~20 ms slower than HNSW at high-recall on 100M (64.9ms vs 45.2ms). This is a deliberate architectural investment in mathematical certainty — not a bug. In regulated environments, this trade-off is a compliance requirement. For pure-speed workloads without compliance needs, FAISS HNSW is the appropriate tool. Madhava is not a universal FAISS replacement — it complements FAISS for regulated use cases where mathematical proof is required.

Winnex Tracer Series

Mathematical-proof retrieval for regulated domains — four products, one provable core. Built on the Winnex Madhava engine and the shared Winnex tracer-gov audit framework. Pre-patent technical specification published on Zenodo (v4, 2026-08-06).

Tracer-GOV — Government Audit

Audited vector search for public-sector bodies. Proves that no record within the proven similarity bound was missed in oversight (TCU, CGU), transparency (LAI), and data-protection (LGPD) workflows. ICP-Brasil / Ed25519 signatures, retention policies, 8 jurisdictions. Repository private, source-available under BSL 1.1.

LGPD Art. 20LAITCU/CGUGDPR

▦ Kaggle benchmark

Tracer-JUS — Legal e-Discovery

e-Discovery and legal research with a soundness guarantee. No document within the proven similarity bound is lost in triage. WORM chain of custody, case metadata (docket, court, judge, parties), compliance reports attachable to a brief. Repository private, source-available under BSL 1.1.

LGPDLAIGDPRFRCP

▦ Kaggle benchmark

Tracer-MED — Clinical Triage

Clinical triage and research with a soundness guarantee. No clinical record within the proven similarity bound is lost. Biomedical embeddings (BlueBERT), structured metadata (CID-10, pseudonymized patient), HL7 FHIR interoperability. Repository private, source-available under BSL 1.1.

LGPD healthGDPR Art. 9HIPAAFHIR

▦ Kaggle benchmark

Tracer-GAP — Financial Gap Identification

Gap identification in financial documents with proof. Insurance, banking, and capital markets. SEC EDGAR 10-K loader, structured metadata (sector, instrument, CIK, period, risk category), SOX/SEC/CVM reports. Repository private, source-available under BSL 1.1.

SOXSECCVMLGPD

▦ Kaggle benchmark

Product	Dataset (real)	Corpus	recall@10	Bound pairs	ms/query
Tracer-GOV	AG News (384d)	2,000	1.0000	200,000	0.14
Tracer-JUS	Indian Supreme Court (512d)	2,000	1.0000	100,000	0.23
Tracer-MED	MTSamples (BlueBERT 768d)	2,000	1.0000	100,000	0.20
Tracer-GAP	SEC 10-K (512d)	187	1.0000	9,350	0.08

Honest reading of the Tracer benchmarks

The Tracer benchmarks use small corpora (187–2,000 documents) by design — chosen for transparency and easy reproducibility on public Kaggle notebooks. At this scale, recall@10 = 1.0000 and 0 violations are equivalent to a linear scan with per-document bounds; they demonstrate correctness and auditability, not search speed. The Winnex Madhava engine itself operates on gigantic datasets — as demonstrated on BIGANN-100M (100 million vectors) at winnex-madhava-1-7-real-benchmark-vs-hnsw-ivf-pq. The GOV/JUS/MED/GAP tests can be run on larger corpora by swapping the dataset in the public notebooks.

Precise scope of the guarantee

The Cauchy-Schwarz bound proves exclusion from the top-K by vector similarity — it does not prove domain relevance. Ranking quality remains a function of the embedding model. Numerical rigor in float32 is handled by efficient filters — the engine calibrates bounds with an ε-slack (ε=1e-5) to stay rigorous against rounding. The Winnex stack also operates on real-time streaming data through Madhava Stream (mmap-based, processes 100M vectors in blocks). The evidence chain is tamper-evident, not tamper-proof against a root-capable attacker or HMAC-key compromise (external timestamping / public anchoring is on the roadmap). BSL 1.1 is source-available, not OSI open-source. These details are stated fully in the Zenodo specification.

Now Public — Tracer for Liferay (2026-08-18)

Winnex released its Liferay integrations as public open repositories, in line with its publication policy. What began as a client implementation is now a reusable solution: any hospital, health plan, court, or oversight body running Liferay can adopt soundness-guaranteed retrieval without building the proof engine from scratch. Each integration ships as three OSGi bundles (api / service / portlet) plus a FastAPI microservice, with API-key security, a WORM audit trail, and compliance reports out of the box.

tracer-med-liferaytracer-gov-liferayOSGiPublic

tracer-med-liferay (GitHub) tracer-gov-liferay (GitHub)

Updated — Per-Document Certificate is now a Witness (winnex-madhava 1.9.1)

Your audit trail now records the decision the engine actually made — at the exact moment it made it. In 1.9.1 the per-document Cauchy-Schwarz certificate was re-architected from "recompute after the search" to "capture at the moment of pruning": the search engine itself records each excluded document's bound, residual, and threshold. The certificate you hand to a regulator is byte-for-byte identical to the engine's real decision — not a second, independent calculation that could drift. For regulated Liferay deployments this means a compliance record that is both more trustworthy (matches the actual retrieval exactly) and simpler to defend in an audit.

Honest note. The change was driven by a real defect the public benchmark exposed: the 1.9.0 certificate produced 462–973 false "excluded" records on arXiv embeddings (d=1536) — documents marked excluded that were actually in the true top-K. The 1.9.1 witness architecture fixes this at the root, and the follow-up benchmark shows 0 certificate violations and 100% consistency across GloVe, BIGANN, and arXiv. We publish both the bug and the fix because your trust depends on it.

search_auditedwitness certificate1.9.1

▦ winnex-madhava-1-9-1-honest (validated) ▦ 1-9-0-honest (bug exposed)

▣ Zenodo Specification (v4) ▦ Madhava at 100M vectors (BIGANN) ▦ Tracer-GOV Kaggle ▦ Tracer-JUS Kaggle ▦ Tracer-MED Kaggle ▦ Tracer-GAP Kaggle

Licensing & Engagement

Winnex AI is a Brazilian research-driven startup (Goiânia, GO) commercializing mathematical trust infrastructure. Standalone implementation or integrated into the Maestro stack.

Implementation Service

We integrate the Winnex Madhava core into your existing infrastructure. Deploy the bound verification layer, set up Tracer-Gov audit logging, validate against your datasets. FAISS, Pinecone, Milvus, pgVector — we add the proof. Includes training, compliance documentation (EU AI Act, LGPD, HIPAA), and ongoing support. POC available.

License of Use

Embed the C++20 native engine into your product. Full Madhava cascade, int8 quantizer, bound verifier, Tracer-Gov audit API. Python bindings and REST API. BSL 1.1 (open for inspection) with commercial terms for production. For ISVs, database vendors, and platform companies.

Whitepaper

Full technical whitepaper (PDF, v4.0). Research documentation open on Zenodo and Kaggle — including honest reads of our own limits. 16K+ lines of documented code. Open for inspection.

Download PDF

About Winnex AI

Winnex Brasil Soluções Empresariais LTDA-ME — Goiânia, GO, Brazil. CNPJ: 58.364.637/0001-47. A deep-tech company built by a multidisciplinary team of collaborators. BSL 1.1 licensed.

BSL 1.1 CNPJ: 58.364.637/0001-47

Open Source Repositories

winnex-audit-cpp — C++20 engine, AVX2/FMA
audit-trail-plugins — Tracer-Gov, EU AI Act compliance
winnex-production-tools — Docker, enterprise deployment

GitHub →

Kaggle Benchmarks

Real Benchmark (valid reference) — current
BigANN-100M Verified
Madhava vs FAISS v2.0
Pareto Frontier Analysis

Real Benchmark → Speed GPU vs HNSW →

◧ The Silent Advantage — discreet adoption of Madhava & X-Factor

Why Winnex AI

We operate in sectors where uncertainty generates astronomically high fines. Winnex AI transforms vector search from an IT problem into a Legal Defense asset — with mathematics, not promises. The result: lower risk and measurable savings.

⛨ Risk Reduction — Proof, Not Probability

Every excluded document carries a mathematical proof it could not be in the top-K — not a probabilistic guess. That turns a compliance risk into a defensible position:

•EU AI Act (Art. 99): up to 4% of global turnover for non-compliance. A provable search is the difference between a fine and a defense.

•Legal Defense by construction: Madhava was born inside our Maestro ERP to power our own AI — see the origin story and how one engine now defends the whole Winnex product line.

•GDPR / LGPD: right to review automated decisions — answered with a recomputable proof, not "the model decided so".

•e-Discovery: Victor Stanley v. Creative Pipe — $1M+ in sanctions for deficient search methodology. Proof avoids the sanction.

•Zero bound violations across 20M+ verified query-vector pairs — the guarantee is measured, not marketed.

◆ Savings — Measured Efficiency

Winnex replaces costly, slow, or wasteful infrastructure with measured gains:

•Build 16× faster than HNSW @1M (2.57s vs 41.3s, measured) — continuous ingestion without costly rebuild windows.

•57 rebuilds/min @1M (config 32D→64D) vs HNSW 1.5/min — indexes refresh faster than your data changes.

•Streaming at 100M vectors — no need to buy RAM to hold the corpus; process in blocks, 18.6GB total.

•Agent security: Madhava-Sec prunes 98.1% of LLM calls with a bound — fewer tokens, lower cost, same coverage.

⊡ Cost-Efficient AI — Provider Distribution

Your enterprise needs cost-effective AI deployment. Winnex AI Engine distributes calls across 7 providers (WireGuard → Winnex Local → DeepSeek → Z.ai → OpenAI → Anthropic → Google) with automatic failover and per-provider cost optimization — routing to the most economical model for each task. AES-256-GCM API key encryption. No single vendor lock-in. Madhava-Sec further reduces spend by pruning up to 98.1% of LLM calls with a mathematical bound — you pay for what actually needs a model.

▣ Data Protection Regulation Compliance

EU AI Act (Arts. 12-15), LGPD (Art. 20), GDPR (Art. 22), HIPAA. Winnex Madhava is the only vector search technology that generates mathematical proof per excluded document — not a probability, but a mathematical certainty recomputable by any auditor or court. SHA3-256 audit trails and Ed25519 signatures.

◇ More Reliable AI

Deterministic search: same query + same data = same results, always. Every excluded document carries a per-document mathematical proof. Zero bound violations verified across 20M+ pairs — see the benchmarks for the measured results. Trust is not subjective — it is mathematical.

⊡ Audit Trails & Proof

Tracer-Gov generates audit trails in three modes: SHA3-256 hash chain (business record), Ed25519 signed (court admissible), blockchain smart contract (regulatory). Every excluded document carries an auditable record: "Doc #42042: bound=0.2595 < threshold=0.4500 → PROVABLY OUTSIDE TOP-10".

▦ Streaming & Legacy Integration

Madhava is built for data that changes every 1–60 seconds — no graph to maintain means the index rebuilds in seconds, not hours. Memory-map the corpus instead of loading it into RAM, ingest continuously, and add Madhava's proof on top of the stack you already run (FAISS, Pinecone, pgVector, Elasticsearch, SAP, Oracle). How streaming works ↓

Streaming: how Madhava ingests a moving corpus — and why legacy systems fit

Vector search usually assumes a static index: you build it, you query it, and every change is a painful rebuild. Enterprise data is never static — ERPs, clinical records and legal repositories change every minute. Madhava was built for the moving corpus: instead of a graph to maintain, it keeps a math-only structure that can be rebuilt in the time other engines take to start rebuilding.

1. Ingest as it arrives — no full reload

→ New/updated records arrive (SQL, FHIR, CSV, Kafka, legacy export) — embeddings are produced once, outside the engine.
→ The corpus is memory-mapped (np.memmap): the raw vectors never need to live in RAM — a 12.8 GB corpus indexes with a small footprint.
→ Rebuild the whole index on every ingestion — because rebuild ≈ seconds, you never maintain incremental state or stale partitions.

2. Query with proof, at any scale

→ Stage-1/Stage-2 projections prune with the Cauchy-Schwarz bound; k2_max caps the exact post-filter so queries stay bounded even at 100M vectors.
→ Every excluded document still carries its per-document proof — streaming never removes the guarantee.
→ Measured: 1M indexed in 2.57 s (vs 41.3 s HNSW), 100M in ~342 s via mmap on 4 CPUs, 0 bound violations.

3. Sit on top of what you already run

→ Madhava consumes float32 vectors — it does not replace your embedding pipeline, your database, or your ERP.
→ Deploy as a verification layer over FAISS, Pinecone, pgVector, Milvus, Elasticsearch/OpenSearch, or a legacy SAP/Oracle/Dynamics stack. No migration, no rewrite.
→ Add the proof where the risk is: regulated retrieval (Tracer-Gov / JUS / MED), continuous RAG, and audit trails that hold in court.

4. Honest trade-off

Per-query, an approximate index (HNSW/IVF) is faster. Madhava deliberately trades some latency for a per-document mathematical guarantee and a build that is 10–1000× faster — the right exchange when a missed document is a fine or a lost case, and when the corpus changes faster than a graph index can follow.

The Mathematical Proof Per Document

Ordinary vector search is probabilistic: an approximate index (HNSW, IVF, PQ) estimates what may be relevant — and can silently drop a document that mattered. Winnex Madhava does the opposite: for every document it discards, the engine emits a mathematical proof that the document was impossible to be in the top-K. Below is the same certificate the system actually produces — captured from the real engine, no illustrative numbers.

The real certificate (witness architecture · winnex-madhava 1.9.9)

Clinical corpus of 40 records · metric=cosine · basis=pca_corpus · k=5. The certificate is a witness, not a recomputation: it captures the engine’s decision at the moment of pruning — byte-for-byte identical to what the search actually decided.

winnex — interactive demo · search_audited · real engine outputengine 1.9.9

$ engine.search_audited(query, k=5, metric="cosine", basis="pca_corpus")

query = “hypertension — effectiveness of antihypertensive therapy”

threshold (5th exact) = +0.9927 · corpus = 40 records

Honest note: the proof covers the soundness of pruning (nothing relevant was dropped by the filter). End-to-end semantic recall also depends on embedding quality and the prefilter — factors the proof does not control. Reproducible: the same corpus and query regenerate the same certificate byte-for-byte (deterministic).

What it means for your stack

The metric that matters: 0 violations

The metric is not “marketing recall” — it is bound_violations == 0: no document within the proven bound was lost. Measured over 20M+ verified pairs (SIFT-1M, N=1M), not in a demo.

Drop-in on top of what you already run

Madhava-Sec wraps FAISS, Pinecone, pgVector and others with bound verification — no rewrite. Keep your infrastructure, add the proof.

C++20, deterministic, auditable

Same query + same data = same results, always. search_audited returns the per-document certificate. See repositories & benchmarks →

What the certificate proves — and what it does not

For an auditor, regulator, or court, the difference is between trusting the algorithm and verifying the decision. A log says “the document was pruned at stage 1.” A Winnex proof gives the mathematical why:

Audit record · example query "termination clause"

Doc #42042
true cosine = 0.2317
upper bound = 0.2595
threshold (10th exact) = 0.4500
0.2595 < 0.4500  ⟹  VERDICT: PROVABLY OUTSIDE TOP-10
 
audit: hash 0x7f3a… · SHA3-256 chain + Ed25519 signature (WORM)
engine: winnex-madhava 1.9.9 · 0 violations · deterministic

✓ Proves (soundness of pruning)

No document within the proven bound was lost in the search. bound_violations = 0 by construction — recomputable by any auditor.

✗ Does not prove

It does not prove semantic relevance (that is the embedding model’s job) nor end-to-end recall. The proof is a necessary condition of defensibility, not a ranking-quality guarantee.

Regulatory language the proof answers

LGPD · Art. 20 BR

Right to review automated decisions. Every exclusion carries a recomputable proof — “why was my data not considered?” no longer ends with “the model decided.”

GDPR · Art. 22 EU

Special-category data (health — Art. 9). A SHA3-256 + Ed25519 audit trail gives the technical basis for meaningful compliance self-assessments.

HIPAA US

The certificate exposes only the mathematical hash and performance metadata — never clinical content — keeping the verification flow privacy-compliant.

e-Discovery / legal discovery

Deficient search methodology has produced seven-figure sanctions (e.g. Victor Stanley). A search with per-document proof turns procedural risk into a defensible position.

The proof is the product — and the moat

We built the mathematical core of Winnex with $0 of external capital over 24 months, prioritizing scientific validation over market hype. Now, with the engine proven and benchmarks public, we are seeking smart-capital partners to accelerate certifications (SOC2, ISO 27001) and go-to-market expansion in Europe and Latin America.

winnex — capital & verifiable assets

external capital : $0 · 24 months of self-funded R&D
violations : 0 across 20M+ verified pairs · 0 on 5 new Kaggle datasets
benchmarks : public (Kaggle v1.9.9 + normalize 1.2.1, Zenodo) — audit before you invest
C++20 engines : Madhava · Madhava-Sec · normalize · +pip packages
certifications : SOC2 · ISO 27001 · in progress

What the market sells as “audit logs,” Winnex delivers as mathematical proof per document — the regulatory-compliance layer banks, hospitals, law firms and governments will need under the EU AI Act, LGPD, GDPR and HIPAA. The engine is the core asset; the category is the edge.

For funds and angels aligned to the long horizon

What we seek now

Partners who bring operational leverage: enterprise sales networks, certification pathways, and go-to-market presence in Europe and Latin America.

Capital efficiency

The same resilience as founders who “sold their homes,” expressed with the discipline of validating the math before scaling. We are not selling control or a rushed exit.

For investors

Full thesis, addressable market, and licensing model live in the dedicated area. Open the investor area →

Transparent Assessment

We build enterprise math infrastructure. We also know the market. Here is an honest picture of where we stand, what we are building toward, and why the challenges ahead are opportunities for our clients.

Multi-Provider Architecture — Designed for a Changing Ecosystem

The AI model ecosystem changes weekly — new quantizers, new inference frameworks, new providers. This is not a problem to solve; it is a design requirement we embraced from day one. The Winnex AI Engine distributes inference across 7 providers with automatic failover because no single model will solve every bottleneck. When DeepSeek releases a faster quantizer, it joins the chain. When a provider goes down, traffic routes transparently. When a new embedding model achieves better recall, it replaces the previous one without pipeline changes. The chain is designed to evolve. The mathematical proof layer — the Madhava-Sec bound verification — is provider-agnostic and model-agnostic. The guarantees do not change when the model changes.

Multi-Provider Model-Agnostic Future-Proof

Mathematical Proof vs. Audit Log — The Market Education Challenge

The market is flooded with "AI Trust" and "AI Governance" solutions — most are simple audit logs wrapped in compliance language. Winnex AI is fundamentally different. Our technology does not log what happened; it mathematically proves why a document was excluded. A log says "document #42042 was pruned at stage 1." A Winnex proof says "document #42042 cannot be in top-K because its Cauchy-Schwarz upper bound (0.2595) is provably below threshold (0.4500)." This is not a feature improvement — it is a category difference. We recognize that educating CTOs and CISOs to distinguish mathematical proof from audit logging requires time and resources. That is why we provide technical briefings, proof-of-concept deployments, and direct engineering support — we do not expect you to take our word for it. Run the benchmarks. Audit the code. Verify the proof.

Mathematical Proof Not a Log Self-Verifiable

Enterprise Sales & Post-Sale Engineering

Selling to regulated sectors — banking, healthcare, legal, government — means long sales cycles (6-18 months), rigorous SLAs, SOC2 and ISO 27001 certifications, and 24/7 support requirements. We are transparent: our origin is a research-driven team, not a multinational corporation. What we offer instead of enterprise overhead is direct engineering access. When you license Winnex AI, you work with the team that built the engine. Your POC is deployed by the same engineers who wrote the C++20 code. Your compliance documentation is reviewed by the same researcher who proved the Cauchy-Schwarz bounds. We are not a sales team reading a spec sheet. As we grow, we are building toward SOC2 certification, dedicated SLAs, and a specialized post-sale engineering team — because our clients in regulated sectors require it, and we are committed to delivering it. The technology is ready. The infrastructure is being built around it — with our clients, not ahead of them.

Direct Engineering POC Available SOC2 in Progress

The Market Thesis

The AI industry is moving from "what can we build?" to "how do we govern what we built?" We are building the infrastructure for the next decade of AI — where mathematical proof replaces probabilistic confidence.

The Red Ocean: Fast Vector Search is a Commodity

FAISS is free from Meta. Pinecone, Weaviate, Qdrant, Milvus compete on sub-millisecond latency. Margins are thin. Winnex does not compete here.

Vector Database Market — Real Forecast

2025

$2.65B

2030

$8.95B

CAGR 27.5% · Source: MarketsandMarkets, Vector Database Market (Dec 2025)

The Blue Ocean: Regulated Enterprise AI

A parallel market — smaller in volume, astronomically larger in value — is almost entirely unserved. No existing vector search technology satisfies regulatory requirements.

AI Governance Market — Accelerating

2029

$5.78B

CAGR 45.3% · Source: MarketsandMarkets, AI Governance Market (Jan 2025)

Regulated Market Segments Winnex Serves

Annual Addressable Markets

Compliance

$40B

Legal Discovery

$15B

Medical Literature

$8B

Patent Search

$3B

Source: Winnex AI Enterprise Stack research · Regulated sectors requiring transparent search

The Economic Asymmetry

A Single Compliance Failure Costs More Than 10,000 Licenses

EU AI Act: up to 4% of global annual turnover for non-compliance (Art. 99). For a $10B bank: $400M.

GDPR Art. 83: up to €20M or 4% of global turnover for violations of data subjects' rights (Arts. 12-22).

E-discovery case law: Victor Stanley v. Creative Pipe — $1M+ sanctions for deficient search methodology. Pension Committee v. Banc of America — adverse inference jury instruction for missing documents.

Source: Regulation (EU) 2024/1689 Art. 99 · GDPR Art. 83 · U.S. e-discovery case law

Dimension	Red Ocean (80%)	Blue Ocean (20%)
Primary need	Speed (sub-ms)	Proof and audit trail
Customers	Startups, e-commerce	Banks, healthcare, gov, legal
Competitors	FAISS (free), Pinecone	None (unique)
Pricing	Extreme commodity	Low (compliance premium)
Contract value	$1K-$50K/yr	$500K-$5M/yr
Regulatory need	None	EU AI Act, LGPD, HIPAA
Winnex position	Not competitive	Category creator

EU AI Act (2024/1689)

High-risk AI systems must be transparent, auditable, and keep records (Arts. 12-13). Penalty: up to 4% of global turnover. High-risk obligations apply from 2 August 2027 (Annex III sensitive areas) and 2 August 2028 (products).
Source: EC Digital Strategy · artificialintelligenceact.eu

GDPR (Art. 22) / LGPD (Art. 20)

Automated decisions must provide meaningful information about the logic involved. Data subjects can request review. "The model returned these results" is not a defensible answer. GDPR fines up to €20M or 4% of global turnover.
Source: gdpr-info.eu Art. 83

HIPAA / FRCP / Basel III

Medical retrieval must be complete. E-discovery demands defensible search. Credit decisions must be justifiable. Missing a document is a compliance failure. Winnex proves nothing was missed — with a mathematical proof, not a log.
Source: HIPAA Privacy Rule · FRCP Rule 26

Why RAG Needs Mathematical Proof — The Databricks Insight

Databricks — the company behind the most widely used data platform for AI — states that "even the most powerful LLMs can generate poor answers if they retrieve irrelevant or low-quality documents." In regulated industries, a missing document is not a quality issue — it is a compliance failure. Every RAG system is bounded by the quality of what it retrieves. Winnex Madhava ensures the retrieval is provably complete.
Source: databricks.com/glossary/retrieval-augmented-generation-rag

The Invitation

We have the technology. We have the proofs. We need partners to capture the regulated enterprise market before the compliance wave hits. We are transparent about our origin and ambitious about our destination.

Winnex Is Not Another SaaS

We are not building a hosted product with thousands of small subscriptions. Our business model is the one large regulated enterprises actually buy: engine licensing + implementation services for large players — banks, governments, hospitals, law firms, and the ISVs, database vendors, and platform companies that serve them. We sell the Madhava engine as a licensed component, and we deploy it through direct engineering services into existing stacks.

This is precisely why we seek investors: the engine is built and mathematically proven — the capital goes to what a licensing model requires. Enterprise certifications (SOC2, ISO 27001), the long sales cycles of regulated buyers, and the go-to-market reach that turns proven technology into a licensing business. We are not asking investors to fund another product race. We are asking them to fund the distribution of a proof.

Strategic Investment

Capital for engineering (C++/Rust core), certification (SOC2, ISO 27001), and go-to-market. We retain control and IP.

Technology Licensing

License the Madhava core to Pinecone, Weaviate, Qdrant as a compliance layer. Every vector database becomes audit-ready.

Distribution Partnership

Partner with Big Four (Deloitte, PwC, EY, KPMG) or cloud providers (AWS, Azure, GCP) to reach regulated enterprise clients.

Incubators & Accelerators

Winnex is a deep-tech journey built by a multidisciplinary team of collaborators. We welcome incubators, accelerators, and development programs that provide market access, certification support, sales enablement, and regulatory networks in Europe and Latin America — precisely the traction we do not yet have. Reach us at info@winnex.ai.

Capital Efficiency — Built More with Less

Funding Reality — Ours vs. Typical Startup

Winnex

$0 + ~2yr

Typical startup

$5M+

The honest picture: a deep-tech journey built by a multidisciplinary team, a working C++ engine, and verified mathematical guarantees. We have not yet proven we can sell it at scale — that is the gap true investors fill.

What Winnex Seeks

We are building a category — not just a product

Winnex is not asking investors to bet on a feature. We are building the regulatory compliance layer for the age of algorithmic accountability — the infrastructure that every regulated enterprise will need. We seek partners who understand that the EU AI Act, LGPD, GDPR, and HIPAA are not the end of regulation. They are the beginning. In five years, every enterprise AI system in a regulated environment will need to justify its decisions. The question is which technology will provide the infrastructure. We believe Madhava is that infrastructure.

A Deep-Tech Journey — Honest About Our Stage

Capital Efficiency — Built With Discipline

What We Seek Now — Smart-Capital Partners

We are not looking to sell control or rush an exit — we are looking for partners who bring the operational leverage we do not yet have: enterprise sales networks, regulatory and certification pathways (SOC2, ISO 27001, EU AI Act conformity), and go-to-market presence in Europe and Latin America. We welcome conversations with investors aligned with a long-horizon, deep-tech thesis.

Madhava Is the Core — Integrates Into Existing Stacks

Investors should see Winnex Madhava as the primary asset — the mathematically guaranteed search engine. Madhava-Sec is a drop-in layer, not a replacement: it wraps FAISS, Pinecone, pgVector, and other standard tools with bound verification, so teams keep their infrastructure and add the mathematical proof. We sell proof, not a rewrite.

Sources & Further Reading

The Open Letter:
• Winnex AI Open Letter to Investors — Download the Full Letter (PDF)

Media Coverage & Notable Articles:
• EU AI Act: What Companies Need to Know — Reuters
• The EU AI Act Explained — European Parliament
• EU AI Act: What It Means for Your Organization — McKinsey
• AI Governance Market Trends — Grand View Research
• The Vector Database Landscape — Pinecone Learning

Regulatory & Market Data:
Regulatory & Market Data:
• EU AI Act Summary — artificialintelligenceact.eu/high-level-summary
• EU AI Act Timeline — EC Digital Strategy
• GDPR Article 83 (Fines) — gdpr-info.eu/art-83-gdpr
• Vector Database Market — MarketsandMarkets (Dec 2025)
• AI Governance Market — MarketsandMarkets (Jan 2025)
• RAG & Retrieval Quality — Databricks Glossary
• Winnex Open Letter — Download PDF

For True Angels and Incubators — We're Listening

If you are a venture fund investing in AI governance, an incubator or accelerator providing market access, or a technology partner exploring licensing — we welcome the conversation. Deep tech deserves partners who understand the long horizon.

Contact: info@winnex.ai Open Letter (PDF) Sources & Media ← Back to Winnex AI

The Technology: Mathematical Proof as Product

We are not building a faster vector database. We are building the regulatory compliance layer for the age of algorithmic accountability. The proof is the product.

Winnex Stack — from the provable C++20 engines (Madhava, Spectral, Nano, X-Factor, Madhava-Sec) to the Maestro governance layer and the regulated Tracer applications

The Winnex Stack — the full technology architecture behind Winnex AI.

The Core Innovation

Cauchy-Schwarz Upper Bound

⟨v,q⟩ ≤ ⟨Pv,Pq⟩ + ‖v − PTPv‖ · ‖q − PTPq‖

If bound < threshold → mathematically cannot be in top-K.

This is not probabilistic. It is mathematical certainty.

Per-Document Audit Trail

Doc #42042: true cos = 0.2317
Upper bound = 0.2595
Threshold = 0.4500
Verdict: PROVABLY OUTSIDE TOP-10

Empirical Validation — 20M+ Verified Pairs, Zero Violations

Metric	Madhava	HNSW	IVF
NDCG@10	1.000*	1.000	0.987
Recall@10	1.000*	1.000	0.980
Bound violations	0 in 20M+ verified	Cannot measure	Cannot measure
Build (1M)	2.57s	~40s	<1 min
Deterministic?	Yes	No (random)	Yes
Audit trail?	Per-document	None	None

*Recall@10=1.0000 on BigANN-100M measured against an exact-scan ground truth recomputed by the benchmark (50 queries), not the official BigANN ground truth — that comparison is not yet published. Bound violations verified across 20M+ pairs (SIFT-1M, N=1M). See the Winnex AI Stack technical note (Zenodo 21182272).

The Story: Almost 2 Years of Intensive Research, Zero External Capital

We chose to move deliberately and prove things mathematically. Every vector search system was a black box. We asked: what would it take to build a search engine that could defend its decisions in court? The answer was a deep-tech research journey — Riemannian HMC on S^(d-1), PiPrime anchors, QR-orthogonalized JL projections, Cauchy-Schwarz upper bounds, error backpropagation modulation, and six transparently documented bug correction cycles. It took a set of collaborators — and 24 months of disciplined, self-funded research with $0 of external capital.

Output of Almost 2 Years of Research

16,000+ lines of documented code · Definitive benchmark (16 methods, 12 metrics, 3 datasets) · Zero bound violations across 20M+ verified pairs · Research open on Zenodo and Kaggle, including honest reads of our own limits.

Immediate Product Roadmap

Native C++/Rust core targeting sub-0.3ms (4-6 months) · Enterprise connectors: PostgreSQL/pgVector, Snowflake, Databricks, Elastic, OpenSearch · SOC2 Type II, ISO 27001, EU AI Act conformity certification.

What We Offer Partners

Exclusive IP (Madhava algorithm, audit trail system, complete codebase) · First-mover advantage (12-18 month window) · Proven (NDCG=1.000, zero violations) · Built by a multidisciplinary team of collaborators.

Europe: A Natural Home

Winnex is headquartered in Brazil, but our technology was built for the world's most demanding regulatory environments — and Europe is where that demand is highest and most urgent.

Europe Is the Epicenter of AI Regulation

The EU AI Act (Regulation 2024/1689) is the world's first comprehensive AI law — and it applies to any organization deploying high-risk AI systems in the EU, regardless of headquarters. European enterprises face the first binding deadlines:

February 2025: prohibited practices in force
August 2025: general-purpose AI obligations
August 2026: GPAI transparency rules
August 2027: high-risk Annex III systems
August 2028: high-risk integrated products
Source: EC Digital Strategy · artificialintelligenceact.eu

Why Europe, Why Now

The timing is aligned. Banks, hospitals, law firms, and government agencies across Europe must demonstrate that their AI systems are transparent, auditable, and mathematically justifiable. No existing technology can prove search completeness. Winnex can — and has, with zero bound violations across 20M+ verified pairs. The first-mover window is now.

A Global Standard, Built from Anywhere

Brazil's LGPD is structurally aligned with GDPR. The mathematics of provable search is jurisdiction-agnostic. Winnex builds infrastructure for the global regulated enterprise market — headquartered in Goiânia, engineered for Europe's regulatory frontier, and ready to deploy wherever AI governance demands proof.

AI Is Already Being Held Liable in Europe

In May 2026, the Regional Court of Munich ruled that Google's AI Overviews are Google's own words — making the operator directly liable for false answers, with 80% of legal costs on Google and possible international reach. The court rejected Google's defenses: "users can check for themselves" does not exempt liability, and an AI's output is "the result of an algorithm," not protected speech. Source →

The implication: when an AI excludes a document, the operator must be able to prove why. HNSW cannot. Madhava can — with a per-document mathematical proof.

Europe Entry Strategy — Spain & Portugal

Winnex is a Brazilian deep-tech company with LGPD alignment that maps directly to GDPR. We are studying entry into the European market with an initial focus on Spain and Portugal — where regulatory pressure, EU AI Act enforcement, and the language/cultural bridge to Brazil make adoption fastest. Our product is ready to scale into Europe's regulated enterprise market.

The Path to Enterprise Trust: Certifications & Partners

Large enterprises have extreme aversion to buying deep tech from startups without security audits. To serve banks (Tracer-GAP) and hospitals (Tracer-MED), Winnex is pursuing SOC2 Type II and ISO 27001 certifications — and will reach the right customers through the right partners: established SI integrators, consultancies, and platform vendors that already hold enterprise trust. The mathematical moat is built; the certification moat is next.

Deep Tech forMathematically Provable AI

Where Madhava Was Born

Born Inside the Maestro ERP

The Blind Spot We Found

Leveraging the Team's Research

One Engine, the Whole Product Line

From IT problem to Legal Defense asset

Our Products

PyPI Packages — One Command Install

C++20 Engines — The Mathematical Core

Winnex RAG — Deterministic Retrieval

Winnex Maestro — Inference & Data Governance

Winnex Tracer Series — Regulated Applications

Winnex Tracer for Liferay — Plug-and-Play Adoption

Winnex Solon — Guaranteed Legal AI

The Three Engines — Provable by Construction

Madhava — The Compliance Search Engine

Spectral — The Deterministic Tokenizer

Nano — Sovereign Inference

X-Factor — The Manifold Projector

Madhava-Sec — Agent Security Framework

winnex-madhava — pip installation

Installation

Quick start

Verified results — v1.9.9, five new Kaggle datasets (0 violations)

Parameter guide

Build vs Latency

Reproducible Kaggle benchmarks

Streaming — 100M vectors without loading the corpus into RAM

winnex-nano — pip installation

Installation

Quick start

winnex-xfactor — pip installation

Installation

Quick start

winnex-madhava-sec — pip installation

Installation

Quick start

Verified results — real run (this page)

Reproducible test — winnex-madhava

Winnex Maestro — Inference & Data Governance

Data Convergence — Legacy to Stream

Inference on Real Data — the Madhava Engine

Structured Agents — a Prepared Inference Environment

Trust Boundary — Security & Scoping

Módulo Maestro → Motor Madhava — positioning by measured metrics

Core Execution Layer

Interoperability — Madhava-Sec Works Standalone

The Maestro Engine — Orchestration for Provable AI

Benchmarks

Reference — v1.9.6 (historical) · GloVe / BIGANN / arXiv

The Race Car and the Truck

SIFT-1M (N=50K) — Industry Standard

Build Speed — Streaming Advantage

57 rebuilds/min at 1M (config 32D→64D) vs HNSW 1.5/min

True Streaming — BIGANN-100M (mmap, 12.8GB)

EU AI Act (Arts. 12-15)

LGPD (Art. 20) / GDPR (Art. 22) / HIPAA

Honest Assessment — From the Paper

Winnex Tracer Series

Tracer-GOV — Government Audit

Tracer-JUS — Legal e-Discovery

Tracer-MED — Clinical Triage

Tracer-GAP — Financial Gap Identification

Honest reading of the Tracer benchmarks

Precise scope of the guarantee

Now Public — Tracer for Liferay (2026-08-18)

Updated — Per-Document Certificate is now a Witness (winnex-madhava 1.9.1)

Open Source Repositories

winnex-audit-cpp

audit-trail-plugins

winnex-production-tools

winnex-maestro

winnex-enterprise-stack

winnex-axiom

madhava-sec

Licensing & Engagement

Implementation Service

License of Use

Whitepaper

Deep Tech for
Mathematically Provable AI

The Compliance Wave Is Coming.
Winnex Is Ready.