Open verification infrastructure for high-risk artificial intelligence
Volume I · Number 1 · Filed 25 May 2026 · Lisbon
A Statement of the Problem
The EU AI Act compels every high-risk system to keep a complete log of its decisions. It does not compel that the log be trustworthy — and today, no off-the-shelf technology makes it so.
§ 1 · The Statute
From 2 August 2026, every high-risk AI system placed on the EU market — credit scoring, hiring, biometric identification, employment, essential services, law enforcement, migration, justice1 — must maintain automatic logs over its lifecycle.
The legal text says the logs must exist. It is silent on whether the logs can be trusted. Today a company can edit its own audit trail before a regulator inspects it, and there is no technical means by which the regulator can detect the edit. Penalties for record-keeping failures reach €15 million or 3% of global turnover.
Attestly is the integrity layer the regulation forgot to specify — published as open digital base infrastructure, not as a vendor product.
§ 2 · The Library
Every AI decision is canonicalised, hashed, signed with the system's Ed25519 key, and appended to a hash-chained ledger. Database triggers enforce append-only at the SQL layer; cryptographic chaining enforces it at the storage layer.
SHA-256 · Ed25519 · SQLite WAL · PostgreSQL row-level append constraint
Merkle roots are periodically published to a transparency log as signed commitments — never the underlying decisions. The Signed Tree Head is the only data that touches public infrastructure. The decisions remain private to the operator.
RFC 9162 · Sigstore Rekor compatible · GDPR-safe by construction
A standalone CLI and a browser-WASM verifier. A regulator drops an exported evidence bundle into the tool and receives a mathematical verdict — independent of the operator's claims, independent of any vendor.
Single-binary CLI · WASM verifier under 500 KB · Reproducible builds
§ 3 · Access
Rust 1.85 or newer. SQLite bundled. No other runtime dependencies. The end-to-end demo runs cleanly on Linux, macOS, and Windows.
# Clone the sourcegit clone https://github.com/attestly/attestlycd attestlycargo build --release# Run the end-to-end verification demobash examples/demo.sh# Windows equivalentpwsh examples\demo.ps1
| Surface | State | Notes |
|---|---|---|
attestly-core · Rust library | v0.1.0 · active | 20 tests passing. CI: Linux · macOS · Windows. |
attestly-verify · CLI verifier | v0.1.0 · active | Single static binary; reproducible build. |
| WASM browser verifier | in development | Drag-bundle-and-verify UX for regulators. |
| Production transparency log (Tessera) | scheduled | Pending grant outcomes. |
| Independent security audit | scheduled | EU-based firm; commissioned upon grant award. |
§ 4 · Cross-References
Attestly is designed against the EU regulatory text and the international evidentiary standards a court will reference. The architecture is conventional and prior-art-supported: Merkle's 1979 binary authentication tree4, Haber & Stornetta's 1991 cryptographic time-stamping5, the Certificate Transparency model from 20136, and the Sigstore Rekor model from 20217.
Attestly's contribution is the binding to Article 12 evidentiary requirements — not novel cryptography. That is the right choice for regulator confidence: a court should not be asked to assess a new primitive.