AI as Proposer, Not Authority

A language model is asked to prove the algebraic Lorentz theorem. It produces fluent, confident Lean:

theorem lorentzIntervalInvariantAlgebraic ... := by
  simp
  ring_nf
  done

Three things can happen next. The proof is right. The proof is wrong, and Lean rejects it. Or the model “explains” that the proof works, and nobody runs it. In the third case a polished paragraph has been mistaken for a result.

The engine’s position is that a model’s text is evidence in none of these cases. Only the first two produce a verdict, and that verdict is the kernel’s, not the model’s. This chapter describes the typed boundary that marks model output as an unverified candidate and gives it no path to becoming evidence. It builds on the status ladder of Chapter 3 and the bounded conclusions of Chapter 6.

What the code says

Three definitions in src/math_engine/agents/interfaces.py make up the boundary.

Roles. AgentRole lists formalizer, prover, critic, equivalence_auditor, evidence_evaluator and research_reporter. These name the jobs an AI might be asked to do. They are labels on a proposal and carry no authority.

The proposal type. CandidateProposal is a frozen record with role, claim_id, claim_version, content, provider, model, created_at, and a status field whose only permitted value is the literal "unverified_candidate". Nothing in the type lets a proposal carry any other status.

A provider boundary. ModelProvider is a protocol with provider_name and generate(system, prompt). Its documentation calls it “the only boundary through which a future configured model may be called.”

The test is a single pair of assertions:

assert proposal.status == "unverified_candidate"
assert not hasattr(proposal, "status_formally_verified")

What the code does not do

No model has ever been run through this boundary. The module header says “MATH01 does not require or invoke a model,” and the architecture overview agrees: “Model access is intentionally absent so the no-model path is complete and testable first.” The roles are interfaces; no InvestigationAgent implementation exists in the repository. Everything verified so far was written by people or produced by ordinary tools: the Lean and Rocq proofs by their authors, the witnesses by SymPy and Z3.

So this chapter describes a boundary and cannot report how it behaves under load. The first model-assisted result will be the real test of whether the rule holds in practice.

The rule

A candidate becomes evidence only by passing through a tool the engine trusts:

model text  ->  [adapter runs a kernel / solver]  ->  EvidenceResult
(unverified)         (actual execution)                 (typed, hashed)

The architecture overview puts it this way: “Add an AI proposer behind a provider interface later; its output remains an unverified candidate until an operational adapter accepts it.” The design record’s rejected alternative is the mirror image: “Letting AI judge its own proof text: proposal and verification must remain separate.”

The guards from Chapter 3 do the enforcing. There is no strong status without actual, successful execution; no formally_verified without a return code of 0 from a formal system; and placeholder screening runs on every proof source, whoever wrote it.

Role by role: what a model could propose, and what must check it

The fourth row is the honest hard case. A formalizer’s output can be kernel-checked for consistency, but whether it means the claim is the open obligation of Chapter 15 and Chapter 28.

A real case: AI in an external record

The external source studied in Chapter 28 contains AI-authored material, and the P8 evidence shows how the engine treats it:

• AI-authored comments are recorded as reported, with approval not_approved. One discloses that no human checked it.
• MathVet’s status entry is “pre-referee and model-assisted”, recorded as reported, and described as “not peer review.”
• The project’s own reconciliation is called “a hypothesis-driven method, not a claim of novelty or acceptance.”

An AI-produced record may be cited. It is never counted as independent review. The book applies the same rule to itself: every chapter must label automation-assisted review and say what a person actually inspected.

What this establishes

This chapter claims a design, not an outcome. The design is sound if and only if every path from model text to a strong status runs through an actual tool. The code guarantees two halves of that. At the type level, a proposal cannot carry a verified status. At the evidence level, a result cannot carry a strong status without actual execution. What the code cannot guarantee is that a future adapter will never pass a model’s claim along as if it were a tool’s output. That is an obligation for code review.

The most important safeguard is the one code cannot enforce: someone reading. A kernel can accept a theorem that formalizes the wrong statement (Chapter 1). The engine records “human proof digestion” as a separate thing, and across the repository today it is not_evaluated.

Try it yourself

uv run pytest tests/test_agent_boundary.py

Seeded error. Construct CandidateProposal(..., status="formally_verified"). The literal type should reject it when the record is validated.

Open questions.

1. The boundary is an interface with no implementation. Is a design that has never been exercised worth a chapter, or only a paragraph?
2. How should the engine record which parts of a verified artifact a model proposed? The provenance record has a producer field, and nothing requires it to name a model.
3. If a model proposes a proof that a kernel accepts, what credit and what disclosure does the book owe the reader? The P5 convention tracks contributor credit for “proof” and “automation” separately.

Sources

In the repository: src/math_engine/agents/interfaces.py, tests/test_agent_boundary.py, ADR 0001 (docs/decisions/0001-evidence-first-claim-contract.md), docs/architecture/overview.md and docs/research/MATH-VAL01-P8-source-note.md.