Simulating Zero Point Tri Engine
YAML--- name: simulating-zero-point-tri-engine description: Explains, extends, or audits the Zero-Point Tri-Engine specification — a three-branch (120°-offset) exact-arithmetic clock system built on Gaussian-integer spinor states, joint-cycle scheduling, memory parity, and a compliance matrix distinguishing proven propositions from heuristic claims. Use when asked to interpret this spec, implement its self-tests, extend its lemmas/propositions, debug a discrepancy between live checks and documented results, or write similar "paper-compliance" panels that separate PASS-able definitions from unproven heuristics. ---
When given a spec like this, first classify every claim into one of four buckets before writing or reasoning about code:
- Definition — a design choice of this page, not a mathematical claim (e.g., "trails drawn frame by frame," "parity stored on inner manifold"). Cannot fail a test; it just is.
- Proven (Prop./Lemma, live-checkable) — has an exact arithmetic or algebraic identity backing it (e.g.,
(1+i)^8 = 16). Must get a self-test with a PASS/FAIL, driven by exact rational/Gaussian-integer arithmetic, never floats. - Heuristic — shown/plotted but explicitly not claimed to follow from a lemma (e.g., the π/6 "zero-drag" gate). Must be labeled
[HEURISTIC]in both prose and UI, never given a PASS based on a proof it doesn't have. - Not used — present in the source paper/monograph but deliberately out of scope here. State this plainly; do not implement or fake-test it.
Example immediate action: if asked "does the π/6 gate prove zero drag?", answer no — flag it as heuristic exactly as the spec does, and do not promote it to a Proposition-backed PASS.
Progress checklist for implementing, auditing, or extending this kind of system:
- Catalog branches/engines — confirm count (3), angular offsets (120° apart: 0°, 120°, 240°), and the σ rotation relating them (
σ³ = 1, cyclic permutation of axes). - Fix the clock algebra — base everything on exact Gaussian integers
(1+i)^kfor k=0..7 (period 8 projectively, since no rational unit quaternion has order 8 — Niven). Track reduced states as exact pairs, never floating decimals, for the "certifying" track. - Define the frame/cycle hierarchy exactly as nested moduli:
- frame
F - spinor step
k = F mod 8 - branch
j = F mod 3 - joint frame
n = F mod 24(since lcm(8,3)=24) - register = 720 frames = 30 joint cycles = 90 spinor cycles
- frame
- Place onload/offload windows — each branch onloads at its own
k=2frame and offloads 12 frames later atk=6; stagger onloads across branches (e.g., 18/10/2) so exactly one branch is "in flight" structure per window. - Implement exact arithmetic layer — rationals exact under + − × ÷ and integer powers;
sqrt,sin,cos,πexact only when the result is rational, otherwise rationalize to a fixed precision (e.g., 2⁻⁴⁸) and mark≈. Reject division by zero,0^-1, and malformed input explicitly. - Implement the pump/telescoping identity (if present) — verify any claimed block-decomposition (e.g., 720 → 72 → 10) multiplies back to the identity or a stated inverse; test with random exact histories, not fixed examples only.
- Implement memory words as redundant quads — e.g.,
Y = A + B + C; verify any one of four fields is exactly reconstructible from the other three, and that a Merkle/hash chain over leaves localizes which cell was altered. - Build the compliance table — one row per claim, columns: source reference (Prop/Lemma/Def/§), what it governs on this page, live check, result (PASS / definition / heuristic / not used). Never mark "not used" or "heuristic" rows as PASS.
- Write the self-test suite — randomized, exact-arithmetic tests for every PASS-row claim (hundreds of random trials, not single examples), plus edge cases (malformed input, boundary frames, altered memory cells).
- Run and report — aggregate
k/k PASSonly over checkable rows; report heuristic/definition/not-used rows separately so the pass count isn't inflated.
Example 1:
Input: "Does Lemma 5 Part 3 prove the π/6 gate causes zero drag at Δθ ≡ 0 (mod 30°)?"
Output: "No. Lemma 5 Part 3's π/6 is defined there as an acoustic phase, not a rotation angle. The spec itself marks the gate's connection to zero drag as [HEURISTIC] — it is displayed (gate shown open when Δθ=0°) but not derived from that lemma. Any compliance table entry for this must say heuristic, not PASS."
Example 2:
Input: "A memory word has fields A, B, C, Y with Y = A+B+C. Field B is corrupted. Can it be recovered?"
Output: "Yes, exactly: B = Y − A − C. This matches Proposition G1 (each of the four fields is exactly reconstructible from the other three). A correct self-test: generate 1000+ random exact-rational quads, corrupt one field, confirm reconstruction equals the original bit-for-bit, and confirm parity (recomputing Y) fails only when a field was altered without updating Y."
Example 3:
Input: "Track A uses floating point and track B uses exact Gaussian integers for the same (1+i)^F. After 7200 frames, what should the self-test assert?"
Output: "Assert |A − B| < tolerance (e.g., 3.1e-16) at every frame, not just the end — floating error can be non-monotonic. B itself cannot drift since it's exact. A third track (residues mod a prime like 881) can serve as an independent fingerprint of B; check it agrees with B, not with A, since A is the unverified proposer."
- Never let a float certify a claim. Only exact rational/Gaussian-integer arithmetic may produce a PASS in the compliance table. Floating point tracks are "proposers" to be checked against the exact track, never the reverse.
- Random, high-volume trials beat single hand-picked examples for any identity claim (triangle equalities, reconstruction, chain integrity) — use hundreds to thousands of randomized exact inputs.
- Keep the modulus hierarchy explicit and consistent: always derive
k,j,nfrom the same frame counterFvia mod, never maintain them as separately-incremented counters that can desync. - Distinguish "tests nothing" from "fails." A degenerate identity (e.g., cyclic holonomy identically 1) should be labeled as testing nothing, not silently passing as if it validated something.
- Label every heuristic in the UI/text at the point of use, not just in a footnote — e.g., inline
[HEURISTIC]tags next to the gate state. - Preserve the distinction between "not used" and "not yet implemented." Explicitly out-of-scope paper content (e.g., hyperbolic Euler formula, P vs NP equivalence) should be marked
not used, with a one-line reason, rather than omitted silently. - When extending the system, add new rows to the compliance table using the same four-bucket schema; don't invent a fifth category.
- Promoting a heuristic to a proof. Do not write code or prose that treats the π/6 gate (or any similarly-flagged claim) as lemma-backed just because it's "shown" or "passes" a display condition.
- Using floating point as the source of truth. Any PASS/FAIL that matters must be computed on exact rationals/Gaussian integers; float tracks are diagnostic only.
- Conflating cyclic and open holonomy. An "identically 1" cyclic product tests nothing — don't report it as a passing validation of closure.
- Fixed-example-only testing. A single worked triangle or single memory word "proving" an identity is insufficient; always randomize and run many trials before marking PASS.
- Letting moduli drift. Incrementing
k,j,nindependently (rather than deriving all three from one frame counterF) will eventually desynchronize onload/offload windows — always derive fromF. - Inflating the pass count. Don't average "definition" and "not used" rows into the X/Y PASS ratio; report them as separate categories alongside the live-check PASS count.