<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Verification on The Broken-Born program</title><link>/wiki/method/verification/</link><description>Recent content in Verification on The Broken-Born program</description><generator>Hugo</generator><language>en-us</language><atom:link href="/wiki/method/verification/index.xml" rel="self" type="application/rss+xml"/><item><title>The iron rule: no arithmetic by eyeball</title><link>/wiki/method/verification/iron-rule/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/wiki/method/verification/iron-rule/</guid><description>&lt;p&gt;&lt;em&gt;The iron rule is the program&amp;rsquo;s requirement that no number be accepted on inspection: every number a document asserts, and every number a reviewer disputes, is computed by code that is actually run and prints its result, and the code is kept in the repository&amp;rsquo;s &lt;code&gt;verify/&lt;/code&gt; folder. It was adopted after the first two blind reviews, in which AI referees working without code execution made three confident accusations of order-of-magnitude errors, all of which came from their own unit mistakes. The rule makes the arithmetic checkable by anyone who runs the scripts, and &lt;a href="/wiki/method/verification/the-gate/"&gt;the gate&lt;/a&gt; runs them before any work counts as finished. It does not make the physics right, which round 3 showed.&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Verification checks arithmetic, not the model</title><link>/wiki/method/verification/arithmetic-not-model/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/wiki/method/verification/arithmetic-not-model/</guid><description>&lt;p&gt;&lt;em&gt;A verification script confirms that a calculation was carried out correctly for the inputs and formulas written into it; it cannot tell whether those inputs and formulas are the right physics. The program learned this from its soliton dark-matter manuscript: every number in it was computed and checked by a gated script, yet one formula, the normalization of how many monopoles the early universe forms, was wrong, and only an independent review caught it. Checkpoint #11 has carried the caution since version 2.1, the rule on independent anchors is the repair, and every script page in this section states what its checks leave to the derivation.&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Independent anchors</title><link>/wiki/method/verification/independent-anchors/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/wiki/method/verification/independent-anchors/</guid><description>&lt;p&gt;&lt;em&gt;An anchor is a check that a verification script must pass against something known independently of the paper being checked, such as a textbook identity or a published value, before its own numbers are trusted. A check that only reproduces the paper&amp;rsquo;s own figure is circular: if the paper&amp;rsquo;s formula is wrong, the check repeats the error and passes. Review round 3 found such a case in the soliton manuscript, whose script anchored the monopole count to the previous draft&amp;rsquo;s own figure and computed a normalization too small by a factor of about 4.6×10³ without failing. The rule has been in the program&amp;rsquo;s method since, and three of the current scripts open with anchor checks taken from textbooks or from the cited literature.&lt;/em&gt;&lt;/p&gt;</description></item><item><title>The reduced-model stability rule</title><link>/wiki/method/verification/reduced-model-stability/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/wiki/method/verification/reduced-model-stability/</guid><description>&lt;p&gt;&lt;em&gt;The reduced-model stability rule says that when a calculation simplifies a model by holding some of its fields fixed, the full model&amp;rsquo;s stability must still be checked with every field free to move, and the text must say that the calculation used a reduction. Review round 4 supplied the reason: the potential first used in the program&amp;rsquo;s &lt;a href="/wiki/symmetry-breaking/toy-models/coset-model/"&gt;coset toy model&lt;/a&gt; had been checked only with the phase-space metric H held fixed, and it is unbounded below once H is allowed to vary, so the model&amp;rsquo;s intended vacuum was a saddle. The repaired potential was checked with all fields dynamical, and the toy-model note and its lattice script now name the simulation as a frozen-H reduction.&lt;/em&gt;&lt;/p&gt;</description></item><item><title>The Monte Carlo error-bar rule</title><link>/wiki/method/verification/monte-carlo-error-bars/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/wiki/method/verification/monte-carlo-error-bars/</guid><description>&lt;p&gt;&lt;em&gt;The Monte Carlo error-bar rule says that a number produced by a random simulation must come with an error bar estimated from several independent runs. A simulation started from a fixed random seed gives the same output every time it is run, which makes the number reproducible but says nothing about how far it lies from the average the simulation is estimating. Review round 4 found the case that prompted the rule: the high-temperature control values in the &lt;a href="/wiki/symmetry-breaking/toy-models/"&gt;toy-model note&lt;/a&gt; came from single fixed-seed runs without error bars, and the smallest lattice&amp;rsquo;s value was a short-run fluctuation. The lattice script now reports means and standard errors over four independent seeds, and its checks use those error bars.&lt;/em&gt;&lt;/p&gt;</description></item><item><title>The gate: scripts/check.sh</title><link>/wiki/method/verification/the-gate/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/wiki/method/verification/the-gate/</guid><description>&lt;p&gt;&lt;em&gt;The gate is the shell script &lt;code&gt;scripts/check.sh&lt;/code&gt;, which runs the repository&amp;rsquo;s six verification scripts in &lt;code&gt;verify/&lt;/code&gt; and then the wiki&amp;rsquo;s own consistency check, and exits with a failure if any check fails. The project calls it &amp;ldquo;the definition of done&amp;rdquo;: work is not finished until it passes, and a check may not be weakened to make it pass. Each verification script prints one line per check, a pass or a fail together with the measured value where there is one, so the record of a run shows what was tested as well as the verdict. What the gate tests is the arithmetic of the models the scripts encode and the form of the wiki; which claims it covers, and which it leaves to derivation, review or nothing, is listed below.&lt;/em&gt;&lt;/p&gt;</description></item><item><title>The verification battery T1–T7</title><link>/wiki/method/verification/battery/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/wiki/method/verification/battery/</guid><description>&lt;p&gt;&lt;em&gt;The verification battery is a set of seven numerical and exact-integer tests, T1 to T7, of the matrix algebra at the core of the program: the compatibility theorem, the parametrization of the modular field, and the algebra behind the mass of the &lt;a href="/wiki/gravity/momentum-graviton/"&gt;momentum graviton&lt;/a&gt; and the zero vacuum energy of its potential. It was written and run on claude.ai, carried into the repository as Appendix A of the handoff document, and now runs as &lt;code&gt;verify/battery.py&lt;/code&gt; in the gate, with the same computations and random seeds. Checkpoint #11 calls the results it confirms Tier 1 and tags them [V]. Six of the tests evaluate an identity at randomly drawn sample points and one is exact integer arithmetic, so the battery confirms the algebra at sample points rather than proving it, and none of the tests asks whether the algebra describes nature.&lt;/em&gt;&lt;/p&gt;</description></item><item><title>The soliton-obituary script</title><link>/wiki/method/verification/soliton-obituary-script/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/wiki/method/verification/soliton-obituary-script/</guid><description>&lt;p&gt;&lt;em&gt;The soliton-obituary script, &lt;code&gt;verify/soliton_obituary.py&lt;/code&gt;, recomputes the numbers in the record of why the program&amp;rsquo;s &lt;a href="/wiki/dark-matter/candidates/soliton-candidate/obituary/"&gt;superheavy-soliton dark-matter candidate&lt;/a&gt; failed: the corrected count of monopoles formed in the early universe, the mass at which their abundance would match the observed dark matter, the overproduction at the withdrawn manuscript&amp;rsquo;s benchmark mass, the corrected relic window of the hidden sector&amp;rsquo;s light fermion, the dark-radiation bound, and the exclusion of the minimal hidden sector. Before computing any of these it reproduces standard cosmology results that do not depend on the manuscript. It replaced an earlier script, knot_numbers.py, which had checked the manuscript&amp;rsquo;s own claims and had passed a wrong normalization. The candidate it documents is dead; the script keeps the arithmetic of that death reproducible.&lt;/em&gt;&lt;/p&gt;</description></item><item><title>The toy-model scripts</title><link>/wiki/method/verification/toy-model-scripts/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/wiki/method/verification/toy-model-scripts/</guid><description>&lt;p&gt;&lt;em&gt;The toy-model scripts are four programs in &lt;code&gt;verify/&lt;/code&gt; that recompute the results of the toy-model note, which studies two explicit field theories in which the exchange of position and momentum is an exact symmetry that the vacuum breaks. &lt;code&gt;toy_coset.py&lt;/code&gt; checks the coset sigma model (model I), &lt;code&gt;toy_gw.py&lt;/code&gt; the self-dual Grosse–Wulkenhaar model (model II), &lt;code&gt;toy_s4.py&lt;/code&gt; runs a lattice Monte Carlo of model I with the phase-space metric held fixed, and &lt;code&gt;toy_s5.py&lt;/code&gt; checks how the vacuum&amp;rsquo;s choice can make matter interactions local in position. They were written with the models on 2026-10-19, extended with the corrections of the round-4 review, and run in the gate. Their checks are exact symbolic identities, numerical tests against anchors taken from the cited literature, and seeded simulations with error bars; each confirms the arithmetic of the model as written, and several of the note&amp;rsquo;s conclusions rest on arguments that no script checks.&lt;/em&gt;&lt;/p&gt;</description></item></channel></rss>