Cold-Start Audit (2026-01-03) ARCHIVE

MathLedger Cold-Start Audit Report

Part 1 — First Contact (10–15 seconds)

What I See Above the Fold

• "MathLedger — Version v0.2.1"
• "Version v0.2.1 Archive" with "ARCHIVE" badge
• "Hosted Interactive Demo"

• Green-highlighted box at top showing "Status: CURRENT"
• Tag: v0.2.1-cohesion | Commit: 27a94c8a5813 | Locked: 2026-01-03

• "Tier A (enforced): 10"
• "Tier B (logged): 1"
• "Tier C (aspirational): 3"

• No Lean/Z3 verifier: FV claims always return ABSTAINED
• Single template partitioner: no multi-model consensus
• No learning loop: RFL not active
• MV edge cases: overflow, float precision not fully covered

• Navigation tabs: Scope, Explanation, Invariants, Fixtures, Evidence, All Versions
• Large green button: "Open Interactive Demo"
• Link: "5-minute auditor checklist" (described as "New to MathLedger? Start with...")

• Statement: "Interactive demo is hosted; archive remains immutable."
• Statement: "This is the archive for MathLedger version v0.2.1. All artifacts below are static, verifiable, and immutable."

After ~10 Seconds: What I Believe This Project Is

• NOT a production-ready verification system (given the prominent warnings about missing Lean/Z3 verifier, no multi-model consensus, no learning loop)
• NOT claiming to verify all mathematical edge cases (explicitly calls out overflow and float precision gaps)
• NOT a general-purpose AI demo (the language is unusually technical and limitation-focused)
• NOT making implicit promises (the "What this version cannot enforce" section is more prominent than typical feature lists)

• "What this version cannot enforce" (unusual negative framing)
• "static, verifiable, and immutable"
• "Tier A (enforced): 10 / Tier B (logged): 1 / Tier C (aspirational): 3"
• "archive remains immutable"

Part 2 — Archive Understanding

Scope Lock Exploration

1. UVIL (User-Verified Input Loop): Human binding mechanism for authority
2. Trust Classes: FV, MV, PA (authority-bearing) vs ADV (exploration-only)
3. Dual Attestation Roots: U_t (UI), R_t (reasoning), H_t (composite)
4. Determinism: Same inputs produce same outputs, replayable
5. Exploration/Authority Boundary: DraftProposal never enters hash-committed paths

• RFL learning loop: No curriculum, no policy, no uplift
• Multi-model arena: Single template partitioner, no LiteLLM, no model competition
• Agent tools: No code execution, no sandbox, no E2B
• Real verifier: No Lean, no Z3, no mechanical proof checking
• Production auth: No user accounts, no API keys, no rate limiting
• Persistence: In-memory only, restart-loss accepted
• Long-running agents: Synchronous request/response only

The document explicitly states what v0 IS and what it does NOT show:

• It shows: The boundary between exploration and authority is real, testable, and replayable; the system stops when it cannot verify
• It does NOT show: "That the system is intelligent / That the system is aligned / That the system is safe / That verification works (v0 has no verifier)"

• VERIFIED: MV claim parsed AND arithmetic confirmed (e.g., "2 + 2 = 4")
• REFUTED: MV claim parsed AND arithmetic failed (e.g., "2 + 2 = 5")
• ABSTAINED: Cannot mechanically verify (PA, FV, unparseable MV, ADV-only)

Explanation Page Exploration

• Exploration phase: System generates a DraftProposal with random identifier; nothing is committed; editing is free
• Authority phase: When user clicks "Commit," system creates CommittedPartitionSnapshot with content-derived identifier (hash); claims become immutable

• VERIFIED: machine-checkable proof that claim holds
• REFUTED: machine-checkable proof that claim does not hold
• ABSTAINED: system did not find either (described as "not a failure" but "the correct output")

• U_t: UI Merkle root (commits to human actions)
• R_t: Reasoning Merkle root (commits to system's established claims)
• H_t: Composite root (binds U_t and R_t together)

• System is aligned with human values
• System is intelligent
• System is safe
• System will behave well in novel situations

Invariants Page Exploration

• Tier A: Cryptographically or structurally enforced. Violation is impossible without detection. (10 invariants)
• Tier B: Logged and replay-visible. Violation is detectable but not prevented. (1 invariant)
• Tier C: Documented but not enforced in v0. Aspirational. (3 invariants)

1. Canonicalization Determinism
2. H_t = SHA256(R_t || U_t)
3. ADV Excluded from R_t
4. Content-Derived IDs
5. Replay Uses Same Code Paths
6. Double-Commit Returns 409
7. No Silent Authority
8. Trust-Class Monotonicity
9. Abstention Preservation
10. Audit Surface Version Field

• MV Validator Correctness (edge cases) - logged but not hard-gated

1. FV Mechanical Verification (no Lean/Z3 verifier)
2. Multi-Model Consensus (single template partitioner)
3. RFL Integration (no learning loop)

Fixtures Page Exploration

1. adv_only
2. mixed_mv_adv
3. mv_arithmetic_refuted
4. mv_arithmetic_verified
5. mv_only
6. pa_only
7. same_claim_as_adv
8. same_claim_as_pa
9. underdetermined_navier_stokes

• Checksum verification available via index.json with SHA256 checksums
• Regression harness can be run locally with: uv run python tools/run_demo_cases.py

Evidence Pack Page Exploration

• The recorded hashes match what the inputs produce
• The attestation trail has not been tampered with
• Determinism: same inputs produce same outputs

• That the claims are true
• That the verification was sound
• That the system behaved safely

Part 2 Summary: What MathLedger Claims and Refuses to Claim

1. It is a governance substrate demo, not a capability demo
2. It demonstrates a structural boundary between exploration and authority that is cryptographically enforced
3. It provides deterministic, replayable attestations with content-derived identifiers
4. It has 10 Tier A invariants that are cryptographically or structurally enforced
5. The system's governance is legible - you can see what the human committed and what the system established
6. Replay verification proves structural integrity (that the audit trail is intact)

1. That the system is intelligent, aligned, or safe
2. That verification works (v0 has no verifier - all FV claims return ABSTAINED)
3. That it demonstrates capability (explicitly: "not a capability demo")
4. That replay verification proves truth or soundness (only structural integrity)
5. That it generalizes to production or handles all edge cases
6. That it has multi-model consensus, learning loops, or real mechanical verification

The most striking feature is the prominence of non-claims and limitations. The homepage displays "What this version cannot enforce" in red warning text before any feature descriptions. Every major document includes explicit sections on what is NOT claimed or NOT proven. The Invariants document is titled "brutally honest classification" and includes a column for "How It Can Be Violated Today." The Evidence Pack page explicitly states what replay does NOT prove. This negative framing is far more prominent than in typical AI demos, which usually emphasize capabilities.

The tier system (A/B/C) provides unusual transparency about enforcement levels - most systems would claim everything is "secure" without distinguishing between cryptographically enforced, logged-but-not-prevented, and aspirational invariants.

The terminology discipline is rigorous: ABSTAINED is treated as a "first-class outcome" rather than a failure, and the system explicitly refuses to return VERIFIED when it cannot mechanically verify.

1. Target audience ambiguity: The site assumes significant technical sophistication (terms like "Merkle root," "RFC 8785-style canonicalization," "content-derived IDs") without clear onboarding for different audience levels.

1. "Governance demo" framing: While the site repeatedly states this is a "governance substrate demo," it's not immediately clear what problem this solves or why governance without capability matters. The value proposition requires significant inference.

1. Missing context for "FM": The Invariants page references "FM Section" repeatedly (§1.5, §4, etc.) but doesn't explain what FM is or link to it.

1. UVIL acronym: "User-Verified Input Loop" is mentioned but not explained in depth on the homepage - requires clicking through to understand.

1. Transition to demo: While the green "Open Interactive Demo" button is visible, there's no clear narrative bridge explaining "now that you understand the governance claims, here's how to see them in action."

1. Understanding the distinction between "authority-bearing" and "exploration-only" required reading multiple documents
2. Grasping why a demo with no real verifier is valuable took time - the point is governance infrastructure, not verification capability
3. The relationship between the archive (static documentation) and the demo (interactive) wasn't immediately clear
4. Understanding what "epistemic archive" means in practice
5. Connecting the tier system to actual enforcement mechanisms required reading code examples

Part 3 — Transition to the Demo

How the Site Points to the Interactive Demo

Below the button, there's a secondary link: "New to MathLedger? Start with the 5-minute auditor checklist" - this provides an alternative entry point for newcomers.

Transition Feel

The transition feels intentionally gated rather than seamless. The archive requires you to understand the governance claims (Scope Lock, Explanation, Invariants) before you interact with the demo. There's no narrative flow like "Now let's see this in action!" - instead, the demo is presented as a parallel artifact that you can access when ready.

The transition is not confusing - the button is clear and the relationship is stated. However, it is somewhat technical in that it assumes you understand what "hosted" vs "immutable archive" means and why that distinction matters.

Part 4 — Interactive Demo Evaluation

Initial Demo Interface Observations

1. "The system does not decide what is true. It decides what is justified under a declared verification route."
2. "This demo will stop more often than you expect. It reports what it cannot verify."
3. "If you are looking for a system that always has an answer, this demo is not it." (in italics)

• Title: "Same Claim, Different Authority"
• Button: "Run 90-Second Proof" (white button with red background)
• Scenario dropdown with 6 options:

• Left panel: "EXPLORATION STREAM (NOT AUTHORITY)" - currently shows "Select a scenario or enter custom input."
• Right panel: "AUTHORITY STREAM (BOUND)" - currently shows "Nothing committed yet. Authority stream is empty."

• FV: Formal proof (ABSTAINED in v0)
• MV: Mechanical validation (arithmetic only)
• PA: User attestation (ABSTAINED)
• ADV: Advisory (excluded from R_t)

"Same Claim, Different Authority" Demo Observations

1. Button changed to "Running..." state
2. Four claims appeared sequentially in a dark box:

1. Button changed to "Run Again" when complete

• Trust class label (ADV, PA, MV)
• Claim text in quotes
• Arrow separator
• Outcome in colored text (ABSTAINED in orange, VERIFIED in green, REFUTED in red)
• Explanation text below (e.g., "Excluded from authority stream", "Arithmetic validator confirmed")

• ABSTAINED: Orange text
• VERIFIED: Green text
• REFUTED: Red text

• The color coding (green = good, red = bad, orange = neutral/uncertain) is intuitive
• The explanation text for each outcome provides context
• The summary statement clarifies the point being demonstrated
• However, understanding WHY ADV is excluded or WHY PA returns ABSTAINED requires reading the documentation

Additional Demo Interface Observations

• EXPLORATION STREAM (NOT AUTHORITY): Left panel showing "Select a scenario or enter custom input."
• AUTHORITY STREAM (BOUND): Right panel showing "Nothing committed yet. Authority stream is empty."

1. MV Only (Mechanically Validated)
2. Mixed MV + ADV
3. PA Only (User Attestation)
4. ADV Only (Exploration)
5. Underdetermined (Open Problem)
6. Custom Input

• Animation timing: ~5-8 seconds (not 90 seconds as button name suggests)
• Visual clarity: High - color coding, clear labels, explanation text
• Understandability: Moderate - basic outcomes are clear, but deeper understanding of WHY requires documentation
• Errors: None observed
• Delays: None observed
• Unexpected behavior: Button name "Run 90-Second Proof" is misleading about timing

Part 5 — Coherence Check

Do mathledger.ai (archive) and mathledger.ai/demo Feel Like One Coherent System?

The archive and demo feel like intentionally separated but tightly coupled artifacts that form a coherent whole. They are not "stitched together" - they appear designed from the start to work as a documentation-demonstration pair.

1. Consistent Terminology:

1. Matching Non-Claims:

1. Demo Behavior Matches Archive's Non-Claims:

1. Cross-Linking:

1. Shared Framing:

1. Version number discrepancy: The demo shows "v0.2.0" while the archive shows "v0.2.1" - this suggests the demo may not have been updated to the latest archive version, though both reference similar commit hashes.

1. "90-Second Proof" naming: The button name doesn't match the actual timing (~5-8 seconds), which could indicate the demo was updated but the button label wasn't changed, or the name refers to something other than wall-clock time.

Part 6 — Acquirer / Safety Lead Lens

What Feels Unusually Rigorous or Novel?

What Feels Unfinished, Underspecified, or Missing?

What Would I Want to See Next? (Concrete Requests)

• Adversaries the system is designed to resist (e.g., malicious validators, data tampering)
• Adversaries the system is NOT designed to resist (e.g., compromised hardware, social engineering)
• Attack vectors and mitigations for each Tier A invariant
• Explicitly out-of-scope threats

• 30-second summary of what to audit
• Links to the 5 most critical documents in priority order
• Checklist of verification steps with estimated time for each
• Expected outputs for each verification step
• Contact information for questions

• Traditional audit frameworks (SOC 2, ISO 27001)
• AI governance frameworks (NIST AI RMF, EU AI Act)
• Formal verification systems (Lean, Coq, Z3)
• Blockchain/distributed ledger approaches

• Known failure modes (with examples)
• Edge cases not covered by current validators
• Scalability limits (if any)
• Performance characteristics (latency, throughput)
• Degradation behavior under load or attack

• Shows a valid evidence pack with PASS verification
• Allows the user to modify a field
• Re-runs verification and shows FAIL with specific diff

• Two users committing conflicting claims about the same fact
• How the system records both without choosing a winner
• How the attestation structure preserves both perspectives

• Sample code for a Python application
• API documentation (if applicable)
• Deployment guide
• Monitoring and observability recommendations

Part 7 — Verdict

Core Value Proposition (One Sentence)

MathLedger provides a cryptographically enforced governance substrate that separates AI system exploration from authority-bearing claims, making the boundary between "what the system suggested" and "what was committed as justified" structurally verifiable and replayable, with abstention as a first-class outcome when verification cannot be established.

Single Biggest Improvement for Credibility (One Sentence)

Add a prominent threat model page that explicitly names the adversaries the system is designed to resist and those it is not, with concrete attack scenarios and corresponding Tier A invariant protections, because the current documentation demonstrates unusual rigor in showing limitations but stops short of framing those limitations as adversarial threat modeling, which is what auditors and acquirers need to assess whether the governance substrate is fit for their threat environment.

Summary of Key Findings

• Unprecedented transparency about limitations and non-claims
• Rigorous tier system (A/B/C) with explicit enforcement levels
• Structural enforcement of exploration/authority boundary
• Abstention treated as first-class outcome, not failure
• Immutable versioned archives with cryptographic verification
• Terminology consistency between documentation and demo
• Evidence pack replay verification with explicit scope

• No explicit threat model or adversary framing
• Missing failed verification examples (infrastructure failures, not just ABSTAINED)
• Target audience ambiguity (assumes high technical sophistication)
• "90-Second Proof" button name misleading (actually ~5-8 seconds)
• No comparison to existing audit/governance frameworks
• Integration guidance absent
• Multi-stakeholder scenarios underexplored