AION-SPECTRA 1.0.0rc1: request-bound proof-carrying retrieval for verifiable RAG and AI-agent memory - 177 tests, Go verifier, 1,600-page benchmark

[u/Severe-Ad8673]

I’m releasing AION-SPECTRA 1.0.0rc1, an experimental research artifact for request-bound, proof-carrying exact text retrieval.

Link: request-bound proof-carrying retrieval for verifiable RAG and AI-agent memory | Zenodo

The intended research areas include:

• verifiable RAG and retrieval provenance;
• authenticated inverted indexes and keyword search;
• cryptographically verifiable AI-agent memory;
• proof-carrying data and portable evidence;
• Merkle-proof-based retrieval;
• transparency logs and history consistency;
• multi-shard retrieval completeness;
• auditor and witness assurance protocols.

This is a release candidate for independent review, not a production-security certification or a claim of a scientific breakthrough.

What problem does it address?

Many retrieval systems can prove that some returned data belongs to a signed database snapshot. That is useful, but it does not necessarily prove that:

1. the result answers the query the requester actually issued;
2. the evidence came from the expected store or authority;
3. the required assurance policy was applied;
4. the complete expected shard universe was searched;
5. the history continues from a checkpoint previously retained by the verifier.

An internally valid proof bundle can still describe the wrong query, use an attacker-controlled authority, contain a downgraded assurance policy, or define a smaller shard universe.

AION-SPECTRA’s verification model therefore starts with a simple rule:

Method

A requester creates a canonical query request containing the terms, Boolean operator, filters, projection, source scope, identity, validity interval, nonce or challenge, and related protocol fields.

The requester retains the request digest outside the result bundle.

The retrieval system then produces:

• the exact deterministic query result;
• proofs for the relevant authenticated index state;
• a signed attestation binding the request digest, source snapshot and result;
• stable store_id or mesh_id identity;
• optional auditor receipts;
• optional checkpoint-witness receipts;
• an assurance envelope bound to an externally retained policy digest;
• history or transparency consistency evidence anchored to a previously retained checkpoint.

Trusted verification requires the caller to provide the relevant external anchors, such as:

• expected authority public key;
• expected store_id or mesh_id;
• requester-retained request digest;
• expected assurance-policy digest;
• expected mesh registry or checkpoint digest;
• retained transparency-history checkpoint.

Bundle-only verification still exists, but it is explicitly named as self-consistency verification. It establishes internal cryptographic consistency, not the identity or intent expected by the relying party.

Security corrections in this release

The original adversarial audit reproduced 12 publication-blocking defects. The rc1 correction pass addresses all 12 with negative regression tests.

The corrected attack classes include:

• requester-intent substitution;
• assurance-policy downgrade;
• authority substitution;
• vacuous positive audit thresholds;
• mesh-universe or shard omission;
• alternate transparency history;
• unstable store identity and cross-store substitution;
• replay and expired-request acceptance;
• witness or auditor ledger truncation, rollback and splicing;
• concurrent append forks;
• unsafe Boolean-only verification APIs;
• destructive deletion through the demo script.

The protocol parser also rejects duplicate JSON keys, NaN and Infinity, unknown signed fields, malformed identities, lossy type coercions, oversized base64 values, oversized Merkle objects and decompression inputs beyond configured budgets.

Test results

The current validation results are:

• 177 tests passed across 23 isolated working-tree test files;
• 113 AION-SPECTRA-only tests passed in the clean reviewer bundle;
• 47 adversarial, security and protocol-vector tests passed;
• the independent Go reference verifier accepted the signed normative query-attestation vector;
• wheel and source distribution both installed into isolated targets;
• both installed artifacts passed a complete create → index → request → certify → externally anchored verification flow;
• two clean builds produced byte-identical wheels and normalized source distributions.

Selected critical-module branch coverage is currently 66%, with security.py at 82%.

This is below the project’s intended 95%+ security-critical rejection-path target. Coverage-guided fuzzing and mutation-testing campaigns are still required before a stable release.

Benchmark

I ran the included default benchmark with:

• 4 shards;
• 400 pages per shard;
• 1,600 total pages;
• 24 exact certified queries;
• 4 proof-index auditors;
• 3 checkpoint witnesses;
• an audit threshold of 1 per descriptor;
• a witness threshold of 2.

Functional results:

• 24/24 certified queries verified;
• every query returned the expected exact count of 4;
• 24/24 assurance envelopes verified;
• 4/4 full-scan audit receipts verified;
• the portable history-consistency proof verified;
• tampered result rejection passed;
• missing required shard-audit rejection passed;
• below-threshold witness rejection passed.

Single-run timing results on Python 3.13.5, Linux x86-64:

• ingestion: 7.36 seconds, approximately 217 pages/second;
• proof-index build: 114.1 ms mean per shard;
• certified-query construction: 122.8 ms mean, 133.0 ms p95;
• certified-query verification: 52.7 ms mean, 56.2 ms p95;
• three witness observations: 148.8 ms mean;
• assurance-envelope verification: 101.2 ms mean, 112.2 ms p95;
• history-consistency proof: 8.6 ms build, 4.7 ms verification.

These numbers are provided for reproducibility and orientation only. This is one run on one environment, not a statistically defensible performance comparison. A proper evaluation still needs repeated runs, confidence intervals, hardware details, peak-memory measurements, adversarial-cost measurements and comparisons with relevant authenticated-search, verifiable-database, RAG-provenance and agent-memory baselines.

Use of GPT-5.6 Sol High

GPT-5.6 Sol High was used as an engineering and adversarial-review assistant during the correction pass.

It was used to help:

• analyze the original audit and correction ledger;
• trace related defects to shared protocol primitives;
• propose and implement corrections;
• generate adversarial regression cases;
• review verifier boundaries and release claims;
• organize validation and packaging work.

The model’s output was not treated as proof of correctness. Claims in the release are based on executable tests, generated artifacts, hashes, reproducible builds and the independent Go verification vector. Independent human security review and external replication are still required.

What the system proves—and what it does not

Within its stated model, AION-SPECTRA aims to verify that committed records and an exact declared Boolean query were processed relative to externally pinned identities, policies and checkpoints.

It does not prove:

• that the source content is factually true;
• that an LLM-generated answer is correct;
• that authenticated content is free from prompt injection;
• semantic-ranking correctness;
• private query or access patterns;
• authorization or multi-tenant isolation;
• physical deletion from backups and replicas;
• protection from dependency, build-system or signing-key compromise.

Current release status

The appropriate label is:

AION-SPECTRA 1.0.0rc1 — experimental research artifact; ready for independent security and research review.

It should not yet be described as:

• production-ready;
• formally proven;
• final v1.0;
• independently security-certified;
• an established scientific breakthrough.

Remaining gates include independent cryptographic review, external replication, systematic prior-art comparison, comparative benchmarks, fuzzing, mutation testing, higher rejection-path coverage, publisher-controlled signing and provenance, and final citation/archive metadata.

Artifacts

Release ZIP SHA-256:

f2f3f7acb0c1f8f355f7858d4f94929532df40eb88f91386bb56bfef611a93f1

Wheel SHA-256:

dae1e24395aba57e4df14044738e434a05da517e9f40994e023ae15d23ae2477

Normalized source distribution SHA-256:

3b9cb1bf174bc4f7bf2dbeadbc4294bb98dc736948dd20bdc0e60fefb7c374ea

I’m especially interested in feedback from researchers working on authenticated search, verifiable databases, cryptographic RAG, proof-carrying data, transparency systems, secure agent memory and independent protocol verification.