Auditing Tiered Physical Model Dashboards
YAML--- name: auditing-tiered-physical-model-dashboards description: Reviews and reconstructs multi-tier scientific simulation/visualization pages (e.g. astrophysics "engine" dashboards combining lensing, timing, and frame-closure proofs) into a verifiable spec-to-check mapping. Use when given a dense technical dashboard, monograph-derived model, or physics simulation page with layered lemmas/propositions and a self-verifying telemetry log, and the task is to extract its structure, validate internal consistency, or explain what each panel/check proves. --- # Auditing Tiered Physical-Model Dashboards
Given a dense dashboard like this (systems × tiers × channels, with lemmas, proofs, and a telemetry log), don't try to re-derive the physics from scratch. Instead:
- Identify the hierarchy spec: how many systems/tiers, what parameters define each (radii, windings, frames).
- Identify the channels: observable classes (e.g. astrometry/timing/velocity) × sides (model/data).
- Identify the parity/closure claims: what identity should hold exactly (e.g.
Y = Y_I + Y_II + Y_III + Y_R), and what "frame closure" or "invariance" theorem is being tested. - Map each lemma/proposition to a concrete live check in the telemetry log, and classify as PASS / definition / not-used.
- Produce a compact table:
component → what it claims → how it's checked → result.
Progress:
- Step 1: Parse the tier/system spec (radii formula, winding formula, counts)
- Step 2: Parse the channel grid (observable classes × sides, which cell is "active")
- Step 3: Extract every numeric identity/proposition (parity, frame closure, invariance) with its stated tolerance
- Step 4: Cross-reference the lemma list against the live-check log; tag each as PASS, definition-only, or not-used
- Step 5: Verify arithmetic claims that are checkable from given numbers (e.g. recompute a parity sum, check Y_R ≈ 0)
- Step 6: Summarize in a table + flag any PASS claims that are actually "definition" or "trivially PASS" (vacuous)
- Step 7: Note physical sanity checks separately from pure bookkeeping identities (lensing angles, Shapiro delay, Doppler, Gaia drift) — these are the parts with real physics content
Step 1 — Tier spec. Look for a formula set, typically of the form:
R_n(outer radius),r_n(half-width),W_n(winding/weight) per tier indexn- An invariant like
r_n + W_n = constorΣW = const— verify it algebraically across alln
Step 2 — Channel grid. Usually a small matrix (e.g. 3 observable classes × 2 sides = 6 channels). Identify which cell is "active" (often k mod N of some clock/counter) and what units each row uses.
Step 3 — Identities. Separate three kinds of claims:
- Parity/recovery: total = sum of known parts + unknown residual, residual should be ~0 (floating-point tolerance stated explicitly)
- Frame/holonomy closure: product of rotation/quaternion "legs" around a loop should equal identity, often under an "open" vs "cyclic" convention — note when a convention is vacuously true ("trivially PASS", "tests nothing")
- Algebraic invariance: e.g.
Re(E) = Re(I)under a conjugationE = A I A⁻¹
Step 4 — Lemma audit. Build a table: lemma # → what it governs on the page → the specific live check → PASS/definition/not-used. Preserve the author's own distinctions — "not used" is a legitimate, honest status, not a failure.
Step 5 — Spot arithmetic. When given enough digits, recompute at least one identity by hand (e.g. sum the per-system values and confirm the residual is within stated floating-point tolerance, not exactly symbolic zero unless BigInt/exact arithmetic is claimed).
Example 1:
Input: A parity row — astrometry: Y=96.8986, Y_I=20.50, Y_II=0.3280, Y_III=576.069, Y_R(exact)=0, identity recover residual = 0 PASS
Output: Flag that 20.50 + 0.3280 + 576.069 = 596.897, not 96.8986 — the labeled "total Y" and the sum of I/II/III don't match at face value, so either Y is not a simple sum (check if it's a different combination, e.g. harmonic or log-weighted) or the displayed total is for a different grouping. Note this explicitly rather than asserting PASS without reconciling the arithmetic; state the discrepancy and what would resolve it (clarify the combination rule before trusting "PASS").
Example 2: Input: "Frame closure, cyclic convention: trivially PASS" Output: Report this as a vacuous check, not evidence of correctness — call out explicitly that the author's own documentation says "tests nothing," and exclude it from any tally of "meaningful passes."
- Distinguish exact/BigInt identities (should be literally zero) from floating-point approximations (should be within a stated epsilon) — don't treat a tiny nonzero residual as a failure if tolerance is disclosed.
- When a check is labeled "definition," do not count it toward a pass rate; report pass rate only over checks that could have failed.
- Always separate bookkeeping/parity machinery (tile encodings, Merkle roots, winding numbers) from physical content (Einstein radii, Shapiro delay, sphere of influence, Gaia drift) — the former validates internal plumbing, the latter validates the model against real astrophysics.
- When reproducing a derived physical quantity (e.g. Schwarzschild radius, Einstein angle), state the formula used (
r_s = 2GM/c²,θ_E = sqrt(4GM/c² · d_LS/(d_L d_S))) so the number is independently checkable. - Preserve stated uncertainties (e.g. "5.05 ± 0.35 µas/yr") when comparing a derived value to a published one; a match within error bars is a real pass, a match ignoring error bars is not.
- Don't accept "PASS" labels at face value — recompute at least the headline identity.
- Don't conflate a convention that's definitionally true (cyclic closure) with an actual test (open closure).
- Don't treat "not used" rows as gaps or failures — they're explicit scope statements.
- Don't skip units: mixing µas, mas, and arcsec (or km/s vs m/s) is the most common silent error in these dashboards.
- Don't assume exact cancellation in floating-point contexts; always check whether BigInt/exact arithmetic is actually in play before expecting literal zero.