Codex Audit Phase 2

Scope: second-phase PUM toolkit audit after notes/08_codex_audit.md. Read-only audit except for this note.

1. New-symbol verification

Checked pum_core/symbols.py against exact Fraction recomputation.

Result: the formulas for the newly appended symbols evaluate as encoded, but the count/citation metadata needs cleanup.

Findings:

• The prompt says 12 new symbols were added after the marker. I count 13 _s(...) entries after --- Newly-discovered cardinals..., because the later Pi/Phi and recurrent ratio blocks are also after that marker.
• SYMBOLS contains 58 symbols, not 57. pum_audit/audit.csv also has 58 data rows and lists every symbol in SYMBOLS.
• SUN_OCTAVE citation says PART_17 line 453, but physical line 453 says CURRENT DC / AC MATTER ... = 77,760, not 1,728,000. Supporting lines found:
• line 442: 1,728,000 [129,600 x 13.333] / 11.111 ...
• line 444: SO 1,728,000 THE SUN'S OCTAVE ...
• line 571: 1,728,000 [SUN EM DIAMETER] / 5.555 ...
• line 574: SO 1,728,000 THE SUN OCTAVE ...
• lines 5010-5012: SUN'S OCTAVE 1,728,000 / ...
• LIGHT_TIMES_11 = 1,600,000 is supported, but not by lines 480-484 as encoded. Physical line 469 has the identity 144,000 ... x 11.111 ... = 1,600,000; line 474 has the prose claim that 1,600,000 represents the 16 segments. Lines 480-484 are the following / 11.111 = 129,600 RFEU passage.
• AETHER_NINTH_FIFTHS citation says 140 mentions. In notes/09_part17_identities.csv, literal 64,800 appears 143 times total, in 85 unique rows when counting either equation or context, and in 58 equation fields. I do not reproduce 140 from the CSV.

2. Code-correctness spot checks

Seeds:

• pum_core/seeds.py still uses exact Fraction values for the audited master seeds: AETHER=144000, SUN=864000, TIME=518400, MATTER=3456000, GREAT_YEAR=25920, SANSKRIT_TIME=311040, RFEU=129600, MUSIC_C=800/3, and AETHER_TO_MATTER=100/9.
• Body diameters/radii and dimension fractions match the prior ledger/audit model.

Element algorithm:

• digit_product, elemental_value, right_triangle, triangle_area, and cascade correctly encode the stated algorithm.
• Independent re-derivation for Argon:
• mp = -189.4 = -947/5
• digits 1,8,9,4; product 288; square 82,944, matching ELEMENT_VALUES_CLAIMED["Ar"].
• 3-4-5 sides: 947/5, 3788/15, 947/3.
• area: (2/3) * (947/5)^2 = 1793618/75 = 23,914.906666....
• Hydrogen cascade spot check matches the patent values:
• area 44,789.76
• /24 = 1,866.24
• /60 = 31.104
• /60 = 0.5184
• /60 = 0.00864
• /60 = 0.000144

Parser checks in pum_core/verify.py:

Parser note: repeating decimals require explicit ... Bare 11.111 is treated as finite 11111/1000, by design.

Audit CSV:

• pum_audit/audit.csv has 58 rows, matching all 58 symbols in SYMBOLS.
• No missing/extra symbol names relative to SYMBOLS.
• Every exact_fraction field matches the imported symbol value.
• Derivation prose is not independently parseable, but the exact fractions are consistent with the symbol table.

3. Delta-map recomputation

Recomputed every pum_delta/delta.csv row as:

delta_pct = (pum_value - measured_value) / measured_value * 100

Result: all 24 rows match the stored percentage to 4 decimal places. No incorrect computed deltas found.

Notes:

• Day length (mean solar) rounds to -0.0000%; exact delta is slightly negative.
• Year (Julian) and Year (PUM = 360 days) are separate rows; the Julian row is exact by definition, while the PUM 360-day row correctly shows -1.4374%.
• Some comparisons are intentionally semantic/unit mismatches, already called out in comments, e.g. speed of light scalar and apparent solar radius.

4. Tuning-system sanity

Checked pum_tuning/scales_manifest.json.

Dimension scale:

• Ratios: 1, 10/9, 25/18, 5/3, 35/18, 2.
• All are unique.
• All are octave-reduced into [1, 2].
• Ratios are sorted ascending.
• Cents recomputation using 1200 * log2(ratio) matches manifest within rounding:
• 0.0, 182.4037, 568.7174, 884.3587, 1151.2296, 1200.0.

16-EDO:

• Manifest cents are exactly 75, 150, ..., 1200.
• This is correct for 16 equal divisions of the octave: 1200 / 16 = 75 cents per step.

5. Identities-CSV spot check

Sampled 20 random rows from notes/09_part17_identities.csv with deterministic seed 1729. Arithmetic was recomputed with Fraction; repeated 3-digit same-digit decimals such as 11.111 were treated as repeating for this CSV check.

Spot-check result: 16/20 are exact or acceptable rounded decimal matches; 4/20 are arithmetic failures in the mined CSV. This looks like source/OCR/table-fragment extraction noise, not a Fraction arithmetic issue.

6. Anything to flag for follow-up

1. Fix symbol-count expectations: the live catalogue has 58 symbols, not 57. If 57 is intended, decide whether PUM_KHEOPS_HYPOT should merge with PYRAMID_ANGLE_KHEOPS, since both encode 51.84.
2. Fix the SUN_OCTAVE citation from line 453 to a supporting line such as 444, 574, or 5010-5012.
3. Fix the LIGHT_TIMES_11 citation from line 480-484 to line 469 plus line 474.
4. Reconcile AETHER_NINTH_FIFTHS mention count. I get 143 literal 64,800 occurrences in the CSV, not 140.
5. Add a validation/triage column to notes/09_part17_identities.csv or a derived QA artifact. The sample found obvious bad rows, so downstream consumers should not treat all mined identities as verified.
6. Consider adding tests for verify.py covering explicit .. notation, because the distinction between finite 11.111 and repeating 11.111.. is critical.