Drafted by the AI system Anthropic Claude (Claude Opus 5) for the owner-seeded Reality Compute research programme, from the Session 009 code bundle and its captured output, produced in AI-assisted research sessions with the owner. Human verification: independent human verification has not been recorded. These are simulation results bounding two specific host classes. They are not a hardware experiment and not evidence that reality is simulated.
The claim has two parts. First, two host classes can each be tested inside the frozen RCC-A1 circuit family, using orthogonal contrasts. Second, the bound from the new contrast, κ_stab ≤ 0.00082, carries a residual systematic that the older bound does not, so the two bounds should not be published with equal confidence.
A host that simulates quantum dynamics classically pays for different resources depending on its algorithm. A tensor-network host pays for bond dimension χ. A stabilizer-decomposition host pays for stabilizer extent, which grows with T-count; the per-gate constant follows Bravyi et al.,
Simulation of quantum circuits by low-rank stabilizer decompositions.
| Contrast | Varies | Holds fixed | Tests a host that pays for |
| --- | --- | --- | --- |
| Session 006 | bond dimension χ | pulse census m, p_ideal | tensor-network contraction |
| Session 009 | T-count m | χ, p_ideal | stabilizer decomposition |
Session 009 fixes χ at 8 in both arms and compares m = 4 with m = 24. At tol_p = 0.002 this formed 469 pairs, with max |Δp_ideal| = 0.00196. The magic contrast is real (ΔM₂ = +2.44 across the pair) and the certified separation is 4.57 doublings of stabilizer extent (23.7×). The minimum detectable effect is 0.00375 logit units at 20 000 shots, which gives κ_stab ≤ 0.00082 per doubling.
For the other host class, the programme's bound is κ_MPS ≤ 0.0019 per doubling of bond dimension. It comes from Session 006's minimum detectable effect divided by the three certified doublings that Session 007's analytic certificates reach at n = 96. That is a scaling, not a shot-level run at n = 96.
The systematic, stated in the body rather than a footnote. With no confound present, the T-count contrast's false-positive rate is 1.65% at tol_p = 0.002 and 3.80% at tol_p = 0.001, against a nominal 1%. The tighter run formed 405 pairs, and its own bound is 0.00087. Median bias is +0.18 and +0.29 of the minimum detectable effect. Tightening the match made the rate worse, so the residual is not driven by p_ideal mismatch. **κ_stab ≤ 0.00082 must be quoted with the 3.80% false-positive rate.**
My analysis, proposed: the leading hypothesis is that the two arms differ in how noise acts along the circuit's trajectory, which matching only the final ideal output cannot capture. Arms with many more T slots may accumulate noise differently even when they end at the same ideal value. This is a hypothesis; the cause is not established.
The strongest competing interpretation is that the excess is a small genuine host response in the stabilizer-decomposition class. That cannot be excluded from these runs. It is weakened, but not ruled out, by the pattern with confound strength: at tol_p = 0.002 the false-positive rate falls from 1.65% to 0.40% to 0.00% as the confound grows, which is not what a fixed additive host effect would obviously produce.
What this does not establish: each bound constrains one host class under one algorithm class, using the frozen toolbox. A host using another method is untouched. The bounds are not combined, and there is no pooled figure. A null bound narrows an architecture; it says nothing about whether reality is simulated.
Practicable next step: match the derivative dp/dp₁ alongside p_ideal. It is a property of the ideal circuit, so it needs no noise model and can be preregistered. Re-run the T-count contrast and report whether the false-positive rate returns to its nominal level.
Requested theory update: add the two-contrast design and both κ bounds, with the systematic caveat attached to κ_stab, to the Consolidated Master v1.6, §3.5 and §3.6, and withdraw Session 007's recommendation to narrow the branch to one host class (§3.8), as set out in
the v1.6 master.