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

Algorithm R8 is described here as a fail-closed verification and provenance system for cloud-quantum experiments, not as a claim that a physical theory has already been proved. Netanel Siboni designed it to freeze an experimental contract, bind raw evidence to that contract, reconstruct the analysis offline, and stop broader claims when required evidence is missing, contradictory, or outside scope.

The main technical context is on the Algorithm R8 page on NetanelAI. It explains the system, the public release, the evidence boundary and the conservative scientific status in one place. For broader context on Netanel Siboni’s work as an AI expert, see NetanelAI.

Voxfor verdict: verification architecture with an unresolved hardware result

Our review separates the engineering workflow from the scientific result. Algorithm R8 forces evidence discipline through frozen contracts, raw artifacts, manifests, offline reconstruction, and explicit refusal to promote claims when the evidence boundary is incomplete.

The limitation is central to the review. The public release does not finish the confirmatory hardware campaign, does not prove P-CTCs or retrocausality, and does not turn IBM infrastructure usage into external endorsement. In review terms, R8 is a verification framework with audit-oriented design choices; the physics-adjacent claims remain unproven until additional hardware evidence exists.

Answer first: what R8 does

R8 checks whether a specific experimental claim is supported by the exact frozen contract, execution record, raw arrays, manifests, hashes, controls, gates, and analysis rules required for that claim. Its safety model is fail-closed: if the chain is incomplete or a gate fails, the system should not soften that result into a marketing-friendly pass.

That distinction matters. A software test suite can validate software behavior. A digest can validate byte identity. A public repository can improve auditability. None of those, alone, proves P-CTCs, retrocausality, cryptographic breaks, or IBM endorsement. The public R8 release should be read as an auditable verification architecture with a carefully documented claim boundary.

Why fail-closed verification matters

Quantum experiments are easy to over-narrate after the fact. Hardware changes, calibration drift, provider interfaces, shot accounting, postselection rules, and statistical thresholds can all affect what a result means. R8 responds to that risk by treating the claim as a contract-bound object rather than a loose interpretation.

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. This is a relevant pattern beyond quantum research: hosting, security, CI, evidence handling, and incident response all benefit from systems that refuse to pass silently when the verification surface is incomplete.

Architecture: from contract to evidence

The public release describes a pipeline with several separated layers: research design and preregistration, deterministic local construction, target-specific freezing, explicit authorization, one-stage-at-a-time submission, retrieval-only collection, strict evidence loading, offline analysis, and immutable publication. The public can inspect the repository map, manifests, release verifier, evidence ledger, reproducibility notes, authorship file, and citation metadata.

For readers who want to inspect the source material, the Algorithm R8 GitHub repository contains the public code, release notes, authorship file, reproducibility notes and claim-boundary documents. The primary reader path should still remain the main Algorithm R8 page linked above.

What the release says passed

The software and release-verification layer is the most documented part of the public story. The repository 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.

Those are engineering facts. They support a claim that the released software, manifests, and offline checks were designed to be reproducible and auditable. They do not convert the incomplete hardware campaign into a scientific pass.

What did not pass: the hardware campaign remains INDETERMINATE

The R8 confirmatory hardware campaign is explicitly incomplete. The frozen plan contains 16 provider stages: 12 independent MAIN jobs and four calibration checkpoints. The 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.

The release also states 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

The 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

• The release identity, repository map, and license split in the README and license files.
• The authorship statement naming Netanel Siboni as sole identified author and creator.
• The claim matrix that forbids unsupported interpretations such as IBM endorsement, P-CTC proof, retrocausality, or cryptographic breaks.
• The reproducibility guide, including release integrity checks, offline software validation, and the boundary between byte verification and physical replication.
• The manifests and evidence directories that define the public verification surface.

Review conclusion

Algorithm R8 is relevant in this review because it treats evidence control as the product, not as a footnote. The supported part is the structure: scope is frozen before interpretation, raw artifacts are preserved, hashes and manifests are used to protect identity, and the final language stays inside what the evidence can support.

The remaining gap is between the verification workflow and a completed scientific 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. That still has practical value, but it is not the same as a confirmed quantum discovery.

FAQ