For Auditors ARCHIVE

For Auditors: 5-Minute Verification Checklist

This page provides a quick verification path for external auditors evaluating MathLedger's governance claims.

5-Minute Verification Checklist

Complete these steps to verify the system's core claims:

Step 1: Open the Hosted Demo (30 seconds)

1. Navigate to /demo/
2. Confirm the demo loads without errors
3. Verify the version banner shows v0.2.4-verifier-syntax-fix

Step 2: Run the Boundary Demo (90 seconds)

1. In the demo, click "Boundary Demo: Same Claim, Different Authority"
2. Observe the 4-step sequence:

1. Key insight: Same mathematical truth, different outcomes based on trust class declaration

Step 3: Download Evidence Pack (30 seconds)

1. After running the boundary demo, click "Download Evidence Pack"
2. Save the JSON file locally
3. Note: This file contains cryptographic commitments to all demo operations

Step 4: Verify with Auditor Tool (60 seconds)

1. Open the Evidence Pack Verifier
2. Upload the evidence pack JSON you downloaded
3. Click "Verify"
4. Confirm status shows PASS
5. Observe the hash verification: U_t, R_t, and H_t all match

Step 5: Tamper Test (60 seconds)

1. Open the downloaded evidence pack in a text editor
2. Change any character in the reasoning_artifacts section
3. Re-upload to the verifier
4. Click "Verify"
5. Confirm status shows FAIL with hash mismatch

Ready-to-Verify Examples (No Demo Required)

If the demo is unavailable or you want to verify without running it, use these pre-generated examples:

Download Examples

The file /v0.2.4/evidence-pack/examples.json contains:

Verification Steps

1. Download examples.json
2. Copy the content of examples.valid_boundary_demo.pack to a new file
3. Open the Evidence Pack Verifier
4. Upload the pack JSON
5. Click Verify and observe PASS
6. Repeat with tampered_ht_mismatch.pack and observe FAIL

Why This Matters

These examples prove:

• The verification algorithm is deterministic (same input always produces same hash)
• Tamper detection works (any modification is detected)
• No demo required (auditors can verify offline using the same code)

What This Version Claims

This version (v0.2.4) demonstrates:

• Deterministic canonicalization of reasoning artifacts (RFC 8785-style)
• Cryptographic binding via H_t = SHA256(R_t || U_t)
• Trust class separation where ADV claims are excluded from R_t
• Replay verification using the same code paths as live execution
• Self-auditing capability via the evidence pack verifier

What This Version Does NOT Claim

1. No formal verification — FV (Formally Verified) claims always return ABSTAINED. There is no Lean/Z3/Coq integration.

1. No multi-model consensus — Only one partitioner template is active. The "multi-model arena" is not operational.

1. No learning loop — RFL (Reinforcement from Ledger) is not active. The system does not learn from past decisions.

1. No production hardening — This is a demonstration, not a production system. Do not use for real financial or legal decisions.

1. No guaranteed uptime — The hosted demo may be unavailable. Local execution is always possible.

Key Documentation Links

Field Manual (Why It Exists)

The Field Manual (fm.tex/pdf) is an internal constraint artifact, not marketing documentation.

How auditors should use it:

• Cross-reference claims — If a feature is claimed, check FM for caveats
• Look for "TODO" and "OBLIGATION" — Explicit acknowledgments of gaps
• Compare versions — FM changes show what was addressed between releases
• Trust gaps over features — The gaps we document are more honest than features we claim

Local Verification (Alternative Path)

If the hosted demo is unavailable, verify locally:

git clone https://github.com/helpfuldolphin/mathledger
cd mathledger
git checkout v0.2.4-verifier-syntax-fix
uv run python demo/app.py
Open http://localhost:8000

The local demo produces identical evidence packs that can be verified with the same auditor tool.

External Audits

Independent audits of this project are listed below.

Legacy Status Labels (Pre-v0.2.2 Archives)

Archives published before v0.2.2 may display a Status: CURRENT label in their HTML, even though they are now superseded. This is expected behavior due to archive immutability.

• Pre-v0.2.2 archives embedded status at build time
• Archived HTML files cannot be modified after publication (immutability requirement)
• The fix introduced in v0.2.2 shows Status: LOCKED and defers to /versions/

• A client-side banner is injected into legacy archive pages via Cloudflare Pages Functions
• The banner links to /versions/ for canonical status
• No archived files are modified; injection happens at runtime

See Legacy Status Banner for technical details.

Questions?

For technical questions about this verification process, see the Hostile Demo Rehearsal document which addresses common skeptical questions with prepared answers.