Evidence and review

The September 2026 baseline

This documentation was checked on 5 September 2026. It describes information available by that date, not a forecast for the rest of September. Release statements below come from the project's dated release records; they are not a fresh inspection of every installed phone.

The release notes describe the product changes. The claims ledger distinguishes implementation work from mathematical evidence.

Two independent labels

Product status answers whether something is in a released beta, in development, on the roadmap, or a research candidate. Evidence status answers what supports a specific property. A released feature can have an open proof obligation. A conditional proof can concern a construction that has never shipped.

Implemented and tested

Code and checks exercise a mechanism. The result is bounded by the tested inputs, state transitions, platforms and versions.

Randomized simulation

A program explores selected model executions. A counterexample can reveal a mistake; a clean finite run does not establish all possible executions.

Machine-checked symbolic result

A prover checks a formula in an explicit model. Cryptographic primitives are abstracted. The model's scope, reachable executions and correspondence to implementation must also be examined.

Conditional proof

A mathematical argument under named assumptions and a specified attack experiment. Its conclusion applies only within those boundaries.

Conformance evidence

Checks connect concrete bytes or implementation events to a specification or model. Matching test vectors cover less than the full state machine.

Independent review or audit

A separate reviewer examines a named scope and version, publishes findings, and records their disposition. Auris has no independent implementation audit to cite.

Open or refuted

Open means sufficient evidence is missing. Refuted means there is a counterexample to the exact statement. Both are retained so later wording cannot quietly revive an unsupported claim.

What this documentation review establishes

The editorial review compares public explanations with current source, dated owner documents, frozen research statements and primary external references. Machine assistance was used. It is not an independent cryptographic review, a fresh proof of every result, a new production inspection or an audit of the full application.

The revision-1.16 R2 reproduction suite passed in this review. It checks selected bytes, parsers and the root-key adapter; it does not prove the assumptions. The revision-1.4.2 R3 publication checker also passed, reporting 34/34 selected results consistent with the saved evidence package; that is different from running a fresh complete prover search. Each research page states its own limits.

Several internal documents preserve older release snapshots. A July model is kept pinned to its July construction; a later code change does not silently update its theorem. When records conflict, the documentation uses the dated owner record and current mechanism, and preserves unresolved assurance gaps.

What you can check independently

The reading list links standards and published protocol specifications. Those sources establish their own algorithms and claims; they do not certify Auris's use of them.

The project records an R2 archive under DOI 10.5281/zenodo.21486656. The Zenodo API record, file sizes and archive checksums were retrieved and reconfirmed on September 5; the local PDF and ZIP match the archive’s recorded checksums. No public IACR ePrint report number was verified. See the R2 scope and publication record.

The application source remains closed. Internal test logs and models described here are project-reported evidence unless an accessible artifact is linked explicitly. A filename, a hash, or this website's description alone is not a substitute for access to the artifact.

Six questions for any security sentence

1. Which protocol, build, parameter set and configuration does it cover?
2. Who is the attacker, and what can they observe, change or compromise?
3. When does compromise happen, and what must subsequently be erased or refreshed?
4. Which delivery, storage, clock and operator assumptions are required?
5. What was actually checked, by whom, and where is the evidence?
6. What remains outside the result?

Auris's goal is to make those answers easy to find. More documentation improves inspectability; it does not replace independent validation.