/verify-proof

name: verify-proof
description: Verify a result and, on acceptance, write it as a fact — via the fact_submit tool. Use for the full target theorem AND for every sharply-delimited intermediate result, lemma, construction, or formula you intend to build on. The verifier is the sole authority on mathematical correctness.

Verify Proof

The verifier is the **canonical and sole authority on mathematical correctness**. Mathematics requires 100% accuracy; even though this verifier is not a formal proof assistant, it is the strongest correctness check in the system. No LLM consultation, panel, or self-critique substitutes for it.

**You verify and write a fact through one tool: `fact_submit`.** It runs the glossary-coverage check, calls the verifier, and writes the fact to the fact graph **iff the verifier accepts** — there is no other way a fact enters the graph.

When to submit

• **The full target theorem** — when you have assembled a complete proof of the

whole problem (as a self-contained statement + proof, citing its predecessors by `fact_id`).

• **Every intermediate result you intend to USE downstream** — a lemma, a

candidate construction, an arithmetic/closed-form claim, a saturation or local-to-global claim, any sharply-delimited step. **Adopting an unverified partial result as a building block is the single biggest correctness risk.** When in doubt, submit.

Choose a substantive mathematical boundary, not the smallest checkable line. Routine calculations, substitutions, and bookkeeping identities should normally remain internal steps in the proof of a deeper fact. The submitted fact should state one mathematically significant conclusion; depth must not be simulated by bundling several shallow or unrelated claims. Split supporting claims only when they have independent downstream uses, separate proof obligations, or need isolated verifier repair.

Do **not** build on an unverified finding from global memory. A `conclusion` / `example` / `counterexample` there is awareness, not a brick — re-derive it as a self-contained statement+proof and submit it before relying on it.

Before you submit — write an "ugly-proof" fact

A fact in the fact graph is written in **"ugly-but-rigorous"** form (the operator may call it an **"ugly-proof"**). The one goal of this form is that the fact is **mechanically checkable for correctness** by a reader with no memory and no math intuition (an agent with no recall, a human, the verifier). It is allowed — encouraged — to be **ugly**: redundant, machine-flavored, verbose. It is **not allowed** to be ambiguous, vague, or context-dependent. "Ugly" is the deliberate contrast with the polished arXiv paper (a separate pipeline); here, only mechanical correctness matters.

Concretely, before you submit:

• **Self-contained.** A reader using only this fact + its declared predecessors +

the project glossary can decide whether the math is correct. No appeal to chart positions, parse status, project history, or "as we know".

• **Define every symbol.** Each symbol used in the statement/proof is defined: in

this fact's `glossary_introduces`, in a cited predecessor's glossary, in the project glossary, or in the **global glossary** of universal notation (Z, Q, R, C, floor/ceil, gcd/lcm, intervals, Greek parameter names). Don't redefine universal notation — `glossary_introduces` is for project-specific symbols only. Reuse the project's existing symbol for the same object. `fact_submit` returns `undefined_symbols` if you missed one.

• **Cite every dependency by `fact_id`** — never "by the result above", never the

problem statement as a math source.

• **Every quantifier explicit; every introduced parameter (epsilon, k, …) carries

an explicit range.**

• **No handwave** ("obviously", "easy to see", "routine", "analogously",

"by some classical argument") and **no chart-position references** ("as above").

• **Avoid duplicates.** `gm_search` the fact graph / global memory (or read

`fact_graph/facts/`) for an existing fact with the same statement; if one exists, cite its `fact_id` instead of re-proving it.

Submit and repair

Call `fact_submit(statement, proof, predecessors=[...], glossary_introduces={...})`. Read the result:

• `accepted: true, fact_id` — the fact is written. **Cite `fact_id`** downstream.
• `accepted: false, repair_hints` (+ `undefined_symbols`) — revise: resolve

critical errors first, then all remaining gaps; do not assume the fix is local — change strategy or backtrack if needed; then resubmit. Treat any `wrong` verdict, any critical error, or any gap as failure.

• `verdict: "error"` — the verify service was unavailable; retry.
• `accepted: true, write_error` (e.g. a predecessor was revoked) — the fact was not

written; re-prove or avoid that predecessor.

Every outcome is auto-logged to global memory (kind `verification`), so the feedback is shared — `gm_search` it to learn from others' rejections.

The verifier is the only correctness authority

If your own reasoning, the main agent's `master_guidance`, or any other LLM calls a result correct but `fact_submit` rejects it, the verifier wins. Always. Note the disagreement (a `dead_end` finding) and treat the "looks correct" opinion as the unreliable signal it was. A non-verifier opinion (including `master_guidance`) is for ideas and directions, never for correctness.

Tools

• `fact_submit` (the only path to verify a result and write a fact)
• `gm_search` (check for an existing fact before submitting; read others' verification outcomes)
• the fact graph is read directly (`fact_graph/facts/`, `glossary.json`)