Algorithm R8 Review: Netanel Siboni’s Fail-Closed Quantum Verification System

Algorithm R8 is a verification workflow for cloud-quantum experiments, not a finished proof of a new physical theory. Its practical idea is simple enough to follow: define the claim before the run, freeze the contract, preserve the raw evidence, reconstruct the analysis offline, and stop the conclusion at the point where the evidence stops.

Main source context comes from the Algorithm R8 page on NetanelAI. This review uses that page and the public release material as the boundary: what is documented, what is reproducible from the release, and what still remains outside the evidence.

A relevant AI context sits behind the release as well: Netanel describes Algorithm R8 as created with GPT-5.6 Ultra, then shaped into a structured verification workflow with frozen contracts, reproducible artifacts, and fail-closed claim handling. That origin supports the article’s AI angle without changing the evidence boundary of the review.

Voxfor verdict: audit structure with unresolved hardware evidence

A cleaner reading splits R8 into two layers. One layer is the audit workflow: contracts, artifacts, manifests, offline reconstruction, and a rule that incomplete evidence cannot become a pass. That layer gives the review a clear path.

Hardware results form the second layer, and that is where the article has to stay careful. Public release material does not finish the confirmatory hardware campaign and does not prove P-CTCs or retrocausality. So the value of R8 today is the reviewable evidence workflow, while the physics-adjacent result remains unresolved.

One reading caveat remains: readers outside quantum computing, CI/DevOps, version control, or audit-trail work may need a slower bridge into terms such as calibration gates, MAIN jobs, manifests, hashes, release integrity, and offline reconstruction. This review keeps those terms because they define the evidence boundary, but the practical takeaway is simpler: R8 is mainly about when a technical claim is allowed to move from “recorded” to “verified”.

So what does R8 actually check?

R8 checks whether a specific experimental claim is supported by the frozen contract and the evidence attached to it: execution records, raw arrays, manifests, hashes, controls, gates, and analysis rules. If the chain is incomplete or a gate fails, the system should leave the claim unresolved instead of turning it into a softer pass.

This is the point that keeps the review grounded. A software test suite can validate software behavior. A digest can validate byte identity. A public repository can help an auditor follow the work. None of those, by itself, proves P-CTCs, retrocausality, or cryptographic breaks.

Why fail-closed verification matters

This matters because quantum results can change meaning quickly when context is missing. Hardware behavior, calibration drift, provider interfaces, shot accounting, postselection rules, and statistical thresholds all affect interpretation. R8 responds by making the claim a contract-bound object rather than a loose story written after the run.

In practical terms, fail-closed means that missing stages, failed calibration gates, absent keys, mismatched hashes, unauthorized claim scope, or incomplete independent-job structure should stop the claim from escalating. A similar idea fits operational infrastructure: if CI jobs, deployment checks, or incident evidence run on VPS infrastructure, a missing log or mismatched hash should keep the status unresolved.

Architecture: from contract to evidence

Architecture is easier to follow as a chain of custody. First comes the research design and preregistration. Then local construction is made deterministic, the target is frozen, authorization is recorded, stages are submitted one at a time, evidence is collected without rewriting the run, and the analysis is reconstructed offline. Public release material exposes the repository map, manifests, release verifier, evidence ledger, reproducibility notes, authorship file, and citation metadata.

From there, readers who want to inspect the material directly can use the Algorithm R8 GitHub repository. It contains the public code, release notes, authorship file, reproducibility notes, and claim-boundary documents. For the full explanation, the NetanelAI R8 page remains the clearer entry point.

What the release package can support

Software and release verification have the clearest public trail. Repository material documents a public, secret-free IBM-pilot pytest baseline of 1262 passed, 10 deselected, 4 warnings, a trusted custodian baseline of 1272 passed, 4 warnings, 181 independent simulation tests, seven permission-normalizer tests, and public CI workflows for offline IBM-pilot validation, simulation, and release integrity.

That supports a narrow conclusion: the released software, manifests, and offline checks are presented in a reproducible audit format. It does not move the incomplete hardware campaign into a scientific pass.

What did not pass: the hardware campaign remains INDETERMINATE

This is where the review has to slow down. R8 confirmatory hardware remains explicitly incomplete. Its frozen plan contains 16 provider stages: 12 independent MAIN jobs and four calibration checkpoints. Public live inventory contains six stages: two calibrations and MAIN_BLOCK_1 through MAIN_BLOCK_4, totaling 245,760 recorded shots. Only four of the required 12 independent MAIN jobs are present, ten planned stages are absent, and no final MAIN_ANALYSIS certificate exists.

Release notes also state that CAL_MAIN_MID_1 fails both frozen dynamic and truth-table gates, and CAL_MAIN_BEFORE also fails both frozen calibration gate families. Therefore the correct status is INDETERMINATE: the confirmatory claim has not been decided under the frozen contract.

R9 and R10 should not be blended into R8

A second source of confusion is naming. Public documentation separates R8, R9, and R10. R8 is the fail-closed verification/provenance release and its incomplete confirmatory campaign. R9 is described as an exploratory diagnostic layer, including a 20-qubit Kingston spatial panel inside one provider job. Its baseline-region noninferiority estimate was approximately -0.22 percentage points with a 95% interval from -1.44 to +0.93 percentage points against a -3 point margin, but all spatial regions and the solo arm failed the absolute truth-table gate. It should not be described as proof of general crosstalk immunity.

R10 should be treated as future work, not as a completed run. Any reference to an intended IBM ibm_kingston 156-qubit experiment must remain framed as a plan unless a later primary source verifies that the run occurred and documents its result.

What readers can verify from the R8 source material

• Release identity, repository map, and license split in the README and license files.
• Authorship statement naming Netanel Siboni as sole identified author and creator.
• Claim matrix separating the verification workflow from unsupported interpretations such as P-CTC proof, retrocausality, or cryptographic breaks.
• Reproducibility guide, including release integrity checks, offline software validation, and the boundary between byte verification and physical replication.
• Manifests and evidence directories that define the public verification surface.

Review conclusion

Conclusion should stay conservative. R8 is not convincing because it announces a physics result; it is reviewable because it shows how a claim can be boxed in by evidence. Scope is frozen before interpretation, raw artifacts are preserved, hashes and manifests protect identity, and the final language is supposed to stay inside what the evidence can support.

A plain gap remains: the verification workflow is more complete than the hardware result. Until the missing MAIN jobs, failed calibration gates, and final certificate problem are resolved, R8 should be reviewed as an audit architecture with an incomplete hardware campaign, not as a confirmed quantum discovery.

FAQ