Authors: Chenyang An (cya.portfolio@gmail.com) Qihao Ye (q8ye@ucsd.edu) Minghao Pan (mpan2@caltech.edu) Jiayun Zhang (landiveo@gmail.com)
Paper: QED: An Open-Source Multi-Agent System for Generating Mathematical Proofs on Open Problems
Citation
@inproceedings{an2026qed,
title={{QED}: An Open-Source Multi-Agent System for Generating Mathematical Proofs on Open Problems},
author={Chenyang An and Qihao Ye and Minghao Pan and Jiayun Zhang},
booktitle={3rd AI for Math Workshop: Toward Self-Evolving Scientific Agents},
year={2026},
url={https://openreview.net/forum?id=EPCNlZRUc3}
}QED is a multi-agent pipeline that takes a mathematical problem statement in LaTeX and produces a rigorous natural-language proof. The pipeline orchestrates Codex (and optionally Claude and Gemini) through their respective CLIs via bash subprocesses (minimal extra dependencies required besides the coding CLI themselves). QED conducts the literature survey, decomposes the problem, executes the plan and verifies the proof. So far, QED has produced 5 works in the area of probabilty, PDE, algebraic geometry and inverse problems that are original and nontrivial according to expert evaluations.
Domain: Partial differential equations, advection-diffusion, mixing, fluid dynamics.
What QED solved: Explicit lower bounds for advection-diffusion equations across three scenarios: a polynomial bound for inviscid shears, a uniform positive lower bound on the mixing scale for diffusive shears, and an exponential bound for rapidly oscillating time-periodic flows. The proofs were generated entirely by QED without expert human intervention.
Workflow: Chenyang An ran QED in decomposition mode.The proof was verified by Professor Xiaoqian Xu.
Expert: Xiaoqian Xu, Assistant Professor of Mathematics at Duke Kunshan University and Zu Chongzhi Center for Mathematics and Computational Sciences.
Problems and proofs: proved_statements/analysis-May-19-2026/
Expert comment (Xiaoqian Xu)
This work is comparable to work published at SIAM Journal on Mathematical Analysis (SIMA) or Journal of Differential Equations (JDE) or higher.
The paper captures three typical scenarios a human researcher might face:
-
Section 2 (polynomial bound for inviscid shears): This shows that AI is good at handling prove-or-disprove problems. If one direction is not that hard, AI may be able to solve it. This is quite different from human researchers.
-
Section 3 (diffusive shears): Given results from humans, AI can easily fill in the gaps and optimize the constants. This illustrates universally useful ways of using AI.
-
Section 4 (oscillating flows): This is remarkable. The problem itself is intuitive, but solving it would mean spending months learning Floquet theory—painful for someone not versed in functional analysis. AI solved it nicely. The proof is standard, but what's hard is the combination of standard techniques from quite different fields—a common scenario for human researchers, particularly when training students.
On AI capability: This shows that the lower bound for AI (since there is almost no cost in human effort, like learning or thinking) is already quite high. It may suggest that mathematics under a certain level—a level that we cannot even call medium for average mathematicians—should be seen as trivial.
See the full expert comments for complete details.
Domain: Algebraic geometry, Hodge theory, monodromy, cohomology of degenerations.
What QED solved: The invariant cycle theorem (Clemens-Schmid, 1970s) states that for a semistable family of complex projective varieties, the invariant class on a nearby smooth fiber extends to the total space. This was known over
Expert: Yilong Zhang, Limited Term Assistant Professor in the Department of Mathematics at the University of Georgia,one of the authors of arXiv:2602.07302.
Workflow: Chenyang An ran QED in decomposition mode. QED produced the proof through 1 plan, 2 revisions, and 7 attempted proofs in total. The proof was verified by Professor Yilong Zhang.
Problems and proofs: proved_statements/algberaicgeometry-May-17-2026/
Expert comment (Yilong Zhang)
"The method in AI's proof that interprets the coboundary map $H^1(X^) \to H^2(X, X^)$ as the residue map is original. This actually holds in higher degrees by working with Griffiths' residue, but in degree one, this interpretation is the classical residue and is particularly useful for LICT$_\mathbb{Z}$, since one has the key lemma which is essential in the proof."
"The proof is elementary and elegant. (The first lemma is essentially residue theory in complex analysis, and the second is essentially reduced to Picard-Lefschetz theory for curves.) It provides a different point of view on the integral version of the invariant cycle theorem in degree one."
See the full expert comments for complete details.
3. Return Probability Asymptotics for Lamplighter Walk on $\mathbb{Z}_2 \wr T_d$ (Probability Theory)
Domain: Probability theory, random walks on groups, lamplighter random walks, spectral analysis.
What QED solved: For
Expert: Minghao Pan, PhD candidate at Caltech Mathematics Department.
Workflow: Minghao Pan provided the problem statement to QED with no further mathematical input. QED ran in decomposition mode and produced the correct proof through multiple rounds of refinement, including substantial changes of proof plan by the decomposition agent. The proof was verified by the expert.
Paper: Return Probability for the Switch–Walk–Switch Lamplighter Walk on a Regular Tree (arXiv:2605.21744)
Problems and proofs: proved_statements/prob-May-15-2026/
Expert comment (Minghao Pan)
This is a research-level open question in probability theory. Without human mathematical input beyond the problem statement, QED generated a correct proof through multiple rounds of refinement, including substantial changes of proof plan by the decomposition agent. The first result is a solid specialized contribution. Its proof has real mathematical content as it cleverly combines probabilistic constructions with spectral analysis. Its significance appears comparable to work suitable for venues such as the Electronic Journal of Probability or Proceedings of the American Mathematical Society. The question is in the style of precise probabilistic calculations and estimates.
4. Total Variation Asymptotics for Switch-Walk-Switch on $\mathbb{Z}_2 \wr \mathbb{Z}$ (Probability Theory)
Domain: Probability theory, random walks on groups, lamplighter random walks, total variation distance.
What QED solved: Let
Expert: Minghao Pan, PhD candidate at Caltech Mathematics Department.
Workflow: Minghao Pan provided the problem statement to QED with no further mathematical input. QED ran in decomposition mode and produced the correct proof through multiple rounds of refinement, including substantial changes of proof plan by the decomposition agent. The proof was verified by the expert.
Problems and proofs: proved_statements/prob-May-15-2026/
Expert comment (Minghao Pan)
This is a technically nontrivial PhD-level problem in probability theory. Without human mathematical input beyond the problem statement, QED generated a correct proof through multiple rounds of refinement, including substantial changes of proof plan by the decomposition agent. The question is in the style of precise probabilistic calculations and estimates.
Domain: Inverse problems, Carleman estimates, wave equations on half-infinite domains.
QED contribution: An early version of QED identified a characteristic-aligned logarithmic weight with sample parameters through seven search rounds under author-derived screening criteria.
Paper results: The authors independently derived the admissible parameter ranges and certified the weight. They proved a global half-line Carleman estimate, weighted conditional lateral Cauchy stability, and a finite-depth semilinear reconstruction result with an endpoint graph stabilizer; they also performed the numerical experiments.
Experts: Qiao Zhuang (University of Missouri-Kansas City), Qihao Ye (University of California, San Diego), Zhongqiang Zhang (Worcester Polytechnic Institute), and Yu Wang (Southwest Jiaotong University).
Paper: Chenyang An, Yu Wang, Qihao Ye, Zhongqiang Zhang, and Qiao Zhuang (2026). Carleman Estimates for Wave Equations on the Half-Line: AI-Assisted Weights and Applications (arXiv:2609.06283). See Appendix A for discovery and Appendix B for author-led parameter analysis.
Search archive and report: Code, prompts, and seven-round records; Verification Report — Round 7. The archived AI-generated report checks simplified search conditions; the paper supplies the final mathematical certification. See the case notes and BibTeX citations.
Expert comment (Qiao Zhuang, Qihao Ye, Zhongqiang Zhang, Yu Wang)
The use of LLM-based search aims to replace the traditional hand-crafted process of identifying suitable Carleman weight functions for deriving Carleman estimates. This process is often difficult, highly problem-dependent, and time-consuming, and may still fail to produce a valid construction through manual trial. By automating the search over admissible weight functions under the required structural and inequality constraints, the approach has the potential to systematically explore viable candidates, thereby reducing reliance on ad hoc intuition and extensive analytical effort. This is particularly important for inverse problems, where the construction of an appropriate Carleman weight is a central and highly nontrivial step that directly impacts stability and uniqueness results. An LLM-assisted search framework can help identify feasible weight structures, guide the design of admissible functions, and accelerate the development of Carleman-based methodologies, thereby extending their applicability to more complex or less structured problems. The contribution produced by QED appears comparable in scope and technical depth to specialized analysis papers published in venues such as Journal of Mathematical Analysis and Applications
QED takes a LaTeX problem statement, orchestrates multiple LLMs to search for a proof, verifies the proof through multi-phase checking, and iterates until the proof passes or retry limits are exhausted. The final output is a rigorous natural-language proof with citations and a summary of the entire proof effort.
The pipeline runs in three stages: literature survey (Stage 0), the decomposition prover (Stage 1), and the proof-effort summary (Stage 2).
Easy short-circuit. During Stage 0, the survey agent classifies the problem as Easy / Medium / Hard. If the classification is Easy, the survey agent writes proof.md directly and the pipeline exits — Stages 1 and 2 are skipped, so proof_effort_summary.md, summary_log/, and decomposition/ are not produced. Medium / Hard problems run all three stages.
| Dependency | Purpose | Install |
|---|---|---|
| Python 3.11+ | Pipeline runtime | python.org or conda |
pyyaml |
Config parsing | pip install pyyaml |
| Claude CLI | LLM backend | curl -fsSL https://claude.ai/install.sh | bash (macOS/Linux/WSL) |
| Codex CLI | LLM backend | npm install -g @openai/codex |
| Gemini CLI | LLM backend | npm install -g @google/gemini-cli |
You need at least one model CLI installed. Install only the ones you plan to use — every agent role in config.yaml can be set to "claude", "codex", or "gemini".
The configuration prioritizes capability for mathematical proof search. Model selections were checked against official documentation on September 22, 2026:
| Provider | Selected model | Reasoning |
|---|---|---|
| Codex | GPT-6 Astra (gpt-6-astra), OpenAI's most capable model |
max |
| Claude | Claude Fable 5.1 (claude-fable-5-1), Anthropic's choice for the most demanding reasoning |
Adaptive thinking; use CLAUDE_CODE_EFFORT_LEVEL=max for maximum effort |
| Gemini | Gemini 3.1 Pro Preview (gemini-3.1-pro-preview), selected for complex reasoning |
HIGH for API access; CLI/model defaults for saved Google login (see subscription track) |
All shipped agent roles use Codex and inherit its global model and reasoning setting. Change an agent's provider to use Claude or Gemini. These are provider-specific choices for this workflow, not a measured ranking on QED's problems. Fable 5.1 requires Claude Code 2.1.257 or later.
Clone the repository, then choose either Python venv or Conda:
git clone https://github.com/proofQED/QED.git && cd QEDOption A: Python venv
python3.11 -m venv .venv
source .venv/bin/activate
python -m pip install -r ui/requirements.txtOption B: Conda
conda create -n agent python=3.11 pip -y
conda activate agent
python -m pip install -r ui/requirements.txtFor either option, point the launchers at the active environment:
export QED_PYTHON="$(python -c 'import sys; print(sys.executable)')"In each new terminal or when switching environments, activate your chosen environment (source .venv/bin/activate or conda activate agent) and repeat the export. This ensures the terminal launchers use the selected environment even when both exist. Without QED_PYTHON, run.sh and run_verifier.sh prefer .venv/bin/python, then fall back to the Conda environment agent. The UI uses its own Python interpreter unless QED_PYTHON overrides it.
Then install the model CLIs you plan to use:
# Install at least one model CLI; these are separate from Python dependencies.
curl -fsSL https://claude.ai/install.sh | bash # Claude (macOS/Linux/WSL)
npm install -g @openai/codex # Codex
npm install -g @google/gemini-cli # GeminiYou can also use an existing Python 3.11+ environment: activate it, install the dependencies, and set QED_PYTHON as above.
Before launching QED, complete Track 1: API access or Track 2: Subscription access below for each model provider you use. Both tracks work with either Python environment and use the same UI, prover, and verifier commands. The default configuration needs only Codex authentication.
After completing your chosen authentication track, launch QED's Streamlit web UI to edit the problem, configure providers / per-agent models, launch and monitor the pipeline, and stream agent logs from your browser.
# Launch from your activated venv or Conda environment
python -m streamlit run ui/app.pyThis opens the app in your browser (default: http://localhost:8501). From there:
- Edit the problem — paste your LaTeX problem statement in the Problem tab (or point it at an existing
.texfile). - Pick providers / models — the Configuration tab edits
config.yamlin place (per-agent provider, model, reasoning effort, etc.). - Run — hit Start. The Progress panel shows live indicators for Survey → Decomposition Loop → Summary, with token usage and the latest agent log tail.
- Resume — if a previous run was interrupted, the UI auto-detects prior progress in the output directory and offers to continue from the last checkpoint.
Please don't refresh the page. You will lose the pipeline progress if you refresh.
The UI uses the same pipeline.py under the hood, so anything you can configure on the command line is available in the UI.
From your activated venv or Conda environment, with QED_PYTHON set as above:
First: write your problem statement in
problem/problem.tex(LaTeX format).
bash run.shThe input file should be a LaTeX problem statement:
\begin{problem}
Let $f: [0,1] \to \mathbb{R}$ be a continuous function satisfying
$f(0) = f(1) = 0$ and $f(x) > 0$ for all $x \in (0,1)$.
Prove that there exists $c \in (0,1)$ such that
\[
\frac{f'(c)}{f(c)} = \frac{1}{1-c}.
\]
\end{problem}When the run finishes, your proof is at <output>/proof.md. For Medium / Hard problems a summary of the proof effort is also written to <output>/proof_effort_summary.md; Easy problems take the short-circuit path described above and skip the summary stage.
Run this from the repository root with your venv or Conda environment activated:
# Prompt/config checks plus a short live request to each enabled pipeline provider
python code/smoke_test.py --config config.yamlThe live check requires authenticated model CLIs and consumes a small amount of model usage. It also runs automatically before run.sh starts the proof pipeline. A successful check requires the expected assistant response; CLI error output does not count as success.
A standalone tool for checking mathematical proofs or problem statements. Two modes:
- Verify a proof (default): Takes a problem + proof pair, classifies difficulty as Easy or Hard, then routes through a 1-agent (Easy) or 3-agent (Hard) verification pipeline. Hard problems go through structural verification first, then detailed verification only if structural passes.
- Review a problem (
--problem-only): Takes just a problem statement and checks whether it is well-defined — reports on clarity, consistency, completeness, and soundness.
Supports Claude, Codex, and Gemini. Provider settings are in the standalone_verifier section of config.yaml.
Use your activated venv or Conda environment with QED_PYTHON set as described in Installation.
Verify a proof:
- Place your problem statement in
standalone_verifier/problem.txt. - Place the proof in
standalone_verifier/proof.txt. - Run:
bash run_verifier.shReview a problem statement only:
bash run_verifier.sh problem.txt --problem-onlyReports are written to standalone_verifier_result/:
| File | When |
|---|---|
report.md |
Always — combined final report |
structural_report.md |
Hard problems — structural verifier's raw output |
detailed_report.md |
Hard problems, structural PASS — detailed verifier's raw output |
# Custom input files
bash run_verifier.sh problem.txt proof.txt
# Problem-only review (no proof needed)
bash run_verifier.sh problem.txt --problem-only
# Override provider for all agents
bash run_verifier.sh problem.txt proof.txt --provider gemini
# Override model
bash run_verifier.sh problem.txt proof.txt --provider claude --model claude-fable-5-1QED runs a structured plan-prove-verify-regulate cycle. A Decomposer creates a YAML proof plan (a DAG of intermediate claims), a Single Prover executes the plan, two Verifiers check the result, and a Regulator decides what to do on failure.
Agents (each independently configurable to use Claude, Codex, or Gemini):
| Agent | Role |
|---|---|
| Decomposer | Creates a YAML proof plan — a DAG of intermediate claims |
| Single Prover | Writes a complete proof following the plan |
| Structural Verifier | Checks structure, citations, completeness (phases 1-5) |
| Detailed Verifier | Step-by-step mathematical correctness (phase 6) |
| Regulator | Analyzes failures and decides the next action |
| Verdict | Returns DONE or CONTINUE |
Three-level retry hierarchy (controlled by the Regulator):
| Level | When | What happens | Default limit |
|---|---|---|---|
| REVISE_PROOF | Plan is sound, execution has errors | Re-prove with same plan | 4 per revision |
| REVISE_PLAN | Plan has structural gaps | Modify the plan, then re-prove | 4 per attempt |
| REWRITE | Fundamental approach is flawed | New decomposition from scratch | 4 total |
When a lower-level limit is exhausted, the system automatically escalates. When all limits are exhausted, the regulator writes a failure analysis for human review.
Choose an authentication track for each provider you use. Both tracks run through the model CLIs. API access uses API credentials and provider billing; subscription access reuses a CLI account login and its allowance or usage credits. Model access and limits depend on that account.
The snippets below update the corresponding sections of config.yaml; keep the remaining settings. All shipped agents use Codex. To enable Claude or Gemini, change the relevant agent's provider and remove incompatible per-agent model overrides, as described under Per-Agent Model Selection.
Codex / OpenAI API
Create an API key in the OpenAI Platform, then authenticate Codex with it:
export OPENAI_API_KEY="your-openai-api-key"
printenv OPENAI_API_KEY | codex login --with-api-key
codex login status # Confirm API-key authenticationKeep the model configuration below. QED reuses Codex's saved credentials; it does not read an OpenAI API key from config.yaml.
codex:
model: "gpt-6-astra"
reasoning_effort: "max"These calls are billed to your OpenAI Platform account separately from a ChatGPT subscription. See the official OpenAI authentication documentation.
Claude / Anthropic API
Create a key in the Claude Console and set:
claude:
provider: "api_key"
api_key:
model: "claude-fable-5-1"
key: "your-anthropic-api-key"QED passes this key to Claude Code as ANTHROPIC_API_KEY. In this project, exporting that variable alone is insufficient: the runner clears it before applying claude.api_key.key. API usage uses your Anthropic API account. See Claude Code authentication.
Gemini API
Create a key in Google AI Studio and set:
gemini:
model: "gemini-3.1-pro-preview"
thinking_level: "HIGH"
api_key: "your-gemini-api-key"QED passes this key as GEMINI_API_KEY. API quotas and billing apply independently of Google AI subscription access. See Gemini CLI API-key authentication.
Claude and Gemini keys entered in config.yaml are also included in QED's saved run configuration; keep both the configuration and run outputs private.
Optional: Claude through AWS Bedrock
For AWS-billed access, configure credentials, model access, and a supported region in your AWS profile or AWS_REGION, following the Claude Code Bedrock guide:
claude:
provider: "bedrock"
bedrock:
model: "anthropic.claude-fable-5-1"
aws_profile: "default"QED sets CLAUDE_CODE_USE_BEDROCK=1 and AWS_PROFILE. Use the Bedrock-specific model ID above for any Claude per-agent overrides too.
Codex / ChatGPT subscription
QED can use GPT-6 Astra through your ChatGPT/Codex subscription without an OpenAI API key, provided your account and workspace have model access. Sign in through Codex:
codex login # Sign in with ChatGPT in the browser
codex login status # Confirm: Logged in using ChatGPTIf switching from a saved API-key login, run codex logout before signing in again. Use the same model settings as the API track:
codex:
model: "gpt-6-astra"
reasoning_effort: "max"The pipeline and standalone verifier both call codex exec and reuse that login. Usage follows your Codex allowance and applicable credits. See the official OpenAI authentication documentation.
Claude subscription
Sign in to Claude Code with your eligible Claude account:
unset ANTHROPIC_API_KEY
claudeUse /login to select the subscription account and /status to confirm the active authentication. Remove conflicting API or cloud-provider overrides from your shell or Claude settings if needed. Then set:
claude:
provider: "subscription"
subscription:
model: "claude-fable-5-1"No Anthropic API key is needed for this route. Fable access depends on your plan and may use paid usage credits; QED's non-interactive calls can consume those credits without an interactive consent prompt. See Claude authentication and Fable usage credits.
Gemini / Google account or subscription
Start Gemini CLI and select Sign in with Google. For Google AI Pro or Ultra, use the account associated with the subscription:
unset GEMINI_API_KEY GOOGLE_API_KEY GOOGLE_GENAI_USE_VERTEXAI
geminiThen set:
gemini:
model: "gemini-3.1-pro-preview"
api_key: ""
thinking_level: ""
thinking_budget: nullAlso remove any per-agent thinking_level or thinking_budget overrides. This is required for cached-login use in the current QED runner: explicit thinking overrides create a temporary Gemini home that does not contain your saved login. Empty thinking settings preserve the normal CLI configuration and model-default thinking. This does not change the selected model.
Gemini headless calls can reuse a cached Google login; account eligibility, model access, and quotas still apply. See Gemini CLI authentication and Gemini CLI configuration.
The selected models are listed under Prerequisites. Authentication changes how requests are authorized and billed; each agent still inherits its model settings from config.yaml unless overridden.
For Claude Fable 5.1, use Claude Code 2.1.257 or later. Update an existing native installation and request maximum reasoning effort:
claude update
claude --version
export CLAUDE_CODE_EFFORT_LEVEL=maxLaunch QED from that shell so Claude calls inherit the effort setting. For other installation methods, follow the Claude setup guide. See Claude model and effort configuration.
For Codex, update with npm install -g @openai/codex@latest if your CLI does not support max. QED uses max with its own agent pipeline; Codex's ultra also enables automatic delegation. See Codex models and reasoning.
After completing either track, run the Runtime Checks, then use the shared UI, terminal, or standalone verifier instructions above. The live check consumes usage under the authentication method you selected.
Every agent role is configured as a dict with at least a provider field. Any other field overrides the corresponding knob from the global claude: / codex: / gemini: section for that one agent. Knobs you don't set fall back to the global section.
decomposition:
models:
decomposer:
provider: "codex"
model: "gpt-6-astra" # overrides global codex.model
reasoning_effort: "max" # overrides global codex.reasoning_effort
single_prover:
provider: "claude"
model: "claude-fable-5-1" # use anthropic.claude-fable-5-1 for Bedrock
detailed_verifier:
provider: "gemini"
model: "gemini-3.1-pro-preview"
thinking_level: "HIGH" # API track only; omit for saved Google login
# Falls back entirely to global codex defaults
structural_verifier:
provider: "codex"The override knobs are provider-specific: model for all three; reasoning_effort for Codex; thinking_level / thinking_budget for Gemini. For Claude, the auth mode (subscription / api_key / bedrock) stays global (controlled by claude.provider); only the model string can be overridden per agent.
The same dict shape applies to:
pipeline.literature_surveyandpipeline.proof_summary- All six
decomposition.models.*agents (decomposer, single_prover, regulator, structural_verifier, detailed_verifier, verdict) - All four
standalone_verifier.*agents (judge, structural_verifier, detailed_verifier, problem_reviewer)
See config.yaml for the full reference with comments. The most important fields:
| Field | Description |
|---|---|
pipeline.literature_survey |
Per-agent dict for the Stage 0 survey |
pipeline.proof_summary |
Per-agent dict for the Stage 2 summary |
decomposition.models.* |
Per-agent dicts for the six decomposition agents |
decomposition.max_proof_attempts |
REVISE_PROOF limit (configured: 8) |
decomposition.max_revisions |
REVISE_PLAN limit (configured: 4) |
decomposition.max_decompositions |
REWRITE limit (configured: 4) |
standalone_verifier.* |
Per-agent dicts for the four standalone-verifier agents |
A survey agent evaluates the problem's difficulty (Easy / Medium / Hard) and researches the mathematical landscape: classifying the problem domain, identifying applicable theorems, and cataloguing related results. Output is saved to <output>/related_info/ (difficulty_evaluation.md plus, for Medium / Hard, related_work.md) for downstream agents.
If the agent classifies the problem as Easy, it also writes the final proof.md directly and the pipeline returns immediately — Stages 1 and 2 are skipped. For Medium / Hard problems, control passes to Stage 1.
The decomposition prover runs here. See the "Prover Pipeline" section above for the agent roles and the three-level retry hierarchy.
After the proof loop finishes (success or retry limits exhausted), a summary agent reads all generated files and writes proof_effort_summary.md — a comprehensive record of the entire proof journey. Stage 2 only runs for Medium / Hard problems; the Easy short-circuit skips it.
Verification is split into two phases, each run by a separate agent:
Structural verification (phases 1-5):
- Problem-Statement Integrity — Word-by-word comparison: does the proof actually prove the stated problem?
- Citation Verification — Checks every
<cite>block; fetches source URLs and verifies that quoted statements match the source. - Subgoal Tree Structure — Validates the proof's decomposition into subgoals for completeness and well-formedness.
- Additional Rules — Applies any human-provided verification criteria from
human_help/files. - Decomposition Adherence — Checks that the proof follows the decomposition plan.
Detailed verification (phase 6):
- Step-by-step verification — Fine-grained logical checking with computational verification, subgoal resolution,
<key-original-step>mismatch analysis, and coverage checks.
The proof search agent is required to use two tag formats that the verifier checks:
<cite>...</cite>— Every external result (theorem, lemma, etc.) must include: type, title, authors, source URL, exact statement, and usage description. The verifier independently checks each citation's faithfulness.<key-original-step>...</key-original-step>— Every nontrivial, original step must be wrapped in this tag with maximal detail. The verifier flags untagged hard steps and inflated tags.
No agent framework is used. All model calls are bash subprocesses:
- Claude:
claude -p --output-format json --model <model> <prompt> - Codex:
codex --search -m <model> exec --json -C <dir> <prompt> - Gemini:
gemini -m <model> -o json -p <prompt>
Each call is wrapped in asyncio.run_in_executor so the event loop stays non-blocking. Token usage from each call is parsed from JSON stdout and tracked in TOKEN_USAGE.md and token_usage.json.
You can steer both the prover and the verifier while the pipeline runs. The decomposition prover reads optional per-run guidance files from human_help/:
human_help/additional_prove_human_help_global.md— Hints for the decomposer / single prover. Editable at any time during a run.human_help/additional_verify_rule_global.md— Verification criteria treated as hard requirements by the structural verifier.
If the pipeline is interrupted (crash, Ctrl-C, machine shutdown), just re-run with the same output directory:
# Same command — the pipeline detects prior progress automatically
bash run.sh /path/to/problem.tex /path/to/outputThe pipeline will:
- Skip the literature survey if already complete.
- Hand off to the decomposition prover, which scans its own
decomposition/directory hierarchy (attempt → revision → proof) and restores the full state — counters, decomposition plan, attempt history — then continues from the exact interruption point.
Each pipeline stage writes logs to its own directory under <output>/:
| Log file | Location | What it records |
|---|---|---|
AUTO_RUN_STATUS.md |
literature_survey_log/, summary_log/ |
Current pipeline state — step, timestamps, PID. Overwritten on each update. |
AUTO_RUN_STATUS.md.history |
Same directories | Append-only event history with timestamps. |
AUTO_RUN_LOG.txt |
Same directories | Full streaming output from all agent calls — tool invocations, model responses, token stats. |
TOKEN_USAGE.md |
<output>/ root |
Running total of tokens used, broken down per call and per provider. Updated after every agent call. |
STATUS.md |
decomposition/ |
Current decomposition state — attempt, revision, proof number, current activity. |
log.txt |
decomposition/ |
Timeline of all decomposition agent calls. |
For Medium / Hard problems the full layout below is produced. Easy problems only produce problem.tex, proof.md, TOKEN_USAGE.md, token_usage.json, related_info/difficulty_evaluation.md, and the literature_survey_log/ directory — Stages 1 and 2 don't run, so proof_effort_summary.md, summary_log/, and decomposition/ are absent.
<output>/
├── problem.tex # Copy of input problem
├── proof.md # Final proof
├── proof_effort_summary.md # Stage 2 summary (Medium / Hard only)
├── TOKEN_USAGE.md # Human-readable token tracking
├── token_usage.json # Machine-readable token tracking
├── related_info/ # Stage 0 output
│ ├── difficulty_evaluation.md # Easy / Medium / Hard
│ └── related_work.md # Applicable theorems (Medium / Hard only)
├── summary_log/ # Stage 2 logs (Medium / Hard only)
└── decomposition/ # Stage 1 artifacts (Medium / Hard only)
├── STATUS.md # Current state (attempt, revision, proof, activity)
├── log.txt # Timeline of all agent calls
├── failure_analysis.md # Written when all retry limits exhausted
└── attempt_N/
└── revision_N/
├── decomposition.yaml # The proof plan (DAG of intermediate claims)
├── decomposer_response.md # Raw decomposer output
└── proof_N/
├── proof.md # Complete proof
├── prover_response.md # Raw prover output
├── scratchpad.md # Prover's scratch work
├── structural_verification.md # Phases 1-5 report
├── detailed_verification.md # Phase 6 report
└── regulator_decision.md # REVISE_PROOF / REVISE_PLAN / REWRITE
The hierarchy reflects the three retry levels: attempt_N (REWRITE) → revision_N (REVISE_PLAN) → proof_N (REVISE_PROOF).
QED/
├── config.yaml # Pipeline configuration
├── run.sh # Entry point (smoke test + pipeline)
├── clean.sh # Cleanup script
│
├── code/
│ ├── pipeline.py # Main orchestrator
│ ├── model_runner.py # Async wrappers for Claude, Codex, Gemini CLIs
│ ├── decomposition_prover.py # Decomposition-based prover
│ └── smoke_test.py # Pre-flight validation
│
├── prompts/ # Prompt templates ({placeholder} filled at runtime)
│ ├── literature_survey.md
│ ├── proof_effort_summary.md
│ └── decomposition-prover/
│ ├── decomposition.md
│ ├── single_prover.md
│ ├── proof_verify_structural.md # Phases 1-5
│ ├── proof_verify_detailed.md # Phase 6
│ ├── regulator.md
│ └── verdict_proof.md
│
├── problem/
│ └── problem.tex # Your problem goes here
│
├── human_help/
│ ├── additional_prove_human_help_global.md
│ └── additional_verify_rule_global.md
│
├── skill/
│ └── super_math_skill.md # Proof methodology system prompt
│
└── ui/ # Streamlit web UI (experimental)
├── app.py
├── config_panel.py
├── process_manager.py
├── progress_monitor.py
└── utils.py
This pipeline runs all model CLIs with permissions bypassed (--dangerously-skip-permissions for Claude, --dangerously-bypass-approvals-and-sandbox for Codex, --approval-mode yolo for Gemini). Agents can read, write, and execute files without confirmation.
Recommendations:
- Review the prompts in
prompts/before running. - Run in an isolated environment (container or VM) when possible.
- Avoid running on machines with sensitive credentials or data.
- Monitor the agent logs (
AUTO_RUN_LOG.txt) during execution.
flowchart TD
P["problem.tex"] --> LS["Literature Survey"]
LS -- Easy --> O["proof.md"]
LS -- Medium / Hard --> DC["Decomposer"]
DC --> SP["Single Prover"]
SP --> SV["Structural Verifier"]
SV --> V1{"Verdict"}
V1 -- DONE --> DV["Detailed Verifier"]
V1 -- CONTINUE --> REG["Regulator"]
DV --> V2{"Verdict"}
V2 -- DONE --> SUM["Summary"]
V2 -- CONTINUE --> REG
REG -- REVISE_PROOF --> SP
REG -- REVISE_PLAN --> DC
REG -- REWRITE --> DC
SUM --> O