Proof-writing Clinic
proofwriting, proof debugging, assumptions, variable scope, clarity
1 Role
This page is the practical capstone of the proofs module.
Its job is not to introduce one new proof method. Its job is to help you revise a draft until it becomes an argument another careful reader can actually trust.
2 First-Pass Promise
Read this page after Counterexamples and Proof Debugging.
If you stop here, you should still understand:
- the difference between a proof that feels plausible and a proof that is actually clear
- the most common structural bugs in early proof drafts
- how to repair a draft without rewriting everything from scratch
- how to run a short self-edit checklist before you call a proof finished
3 Why It Matters
A lot of proof frustration comes from mixing two problems together:
- the idea of the proof is not yet right
- the idea is fine, but the writing hides it
A proof-writing clinic helps separate those.
In practice, many weak drafts fail because of a small number of recurring issues:
- assumptions are not stated clearly
- variables appear without being introduced
- a conclusion is asserted with no justification
- definitions are repeated abstractly instead of applied concretely
- the proof structure says one method is being used, but the body uses another
This matters in class, but it also matters in research. A theorem can be mathematically correct and still unreadable. That is a real problem, because unreadable proofs are hard to verify, hard to debug, and hard to extend.
4 Prerequisite Recall
- a proof needs a clear start point and end point
- each proof step needs some justification, not just plausibility
- a false theorem and a true theorem with a bad proof are different problems
5 Intuition
Think of proof revision the way you think about debugging code.
A first draft often contains:
- unnecessary lines
- variables that were never introduced
- a jump that only works if an unstated assumption is added
- sentences that are grammatically fine but mathematically vague
The point of clinic-style revision is to ask, line by line:
- what is this sentence doing?
- what earlier fact justifies it?
- if I remove this sentence, does anything break?
- if the proof breaks, what exact role was this sentence supposed to play?
That process usually makes the proof shorter, clearer, and more correct at the same time.
6 Formal Core
Proposition 1 (Structural Checklist) A proof draft should answer these questions explicitly or implicitly:
- What are the assumptions?
- What is the exact claim to prove?
- Which proof method is being used?
- Where are new variables introduced, and where do they come from?
- What justifies each nontrivial step?
- What exact statement has been proved at the end?
Proposition 2 (Common Proof Bugs) The most common proofwriting failures are:
missing setup: assumptions or target are not articulatedscope bug: a variable appears without being introduced or changes meaning mid-proofload-bearing bug: a sentence is true but unused, or a needed sentence is missingdefinition bug: a definition is repeated abstractly instead of applied to the current objectmethod mismatch: the proof claims to be direct, contradiction, or induction but does not actually follow that structureequation pile: equations appear with no explanation of why each transformation is valid
Proposition 3 (Revision Rule) When revising a proof, fix logic before style, but use style to expose logic.
In practice:
- test whether the theorem is true
- locate the first unjustified step
- repair the mathematical structure
- then cut extra sentences and improve phrasing
Good style is not cosmetic. It often reveals the hidden bug.
7 Worked Example
Consider the theorem:
If \(m\) and \(n\) are even integers, then \(m+n\) is even.
A student writes:
Proof: Since \(m\) and \(n\) are even, every even number can be written as twice an integer. So \(m=2a\) and \(n=2b\). Then \(m+n=2a+2b=2(a+b)\). Therefore \(m+n\) is even. QED.
This draft is close, but let us put it through clinic.
7.1 What Is Good
- the overall idea is correct
- the relevant definition is being used
- the final algebra points to the right conclusion
7.2 What Needs Repair
- The proof does not begin by clearly stating the assumptions and target.
- The sentence “every even number can be written as twice an integer” repeats the definition abstractly instead of applying it directly to \(m\) and \(n\).
- The variables \(a\) and \(b\) appear, but their source should be stated more cleanly.
- The last line should explicitly connect the algebraic form \(2(a+b)\) to the definition of evenness.
7.3 Revised Version
Proof: Choose any even integers \(m\) and \(n\). We will show that \(m+n\) is even. Since \(m\) is even, there is an integer \(a\) such that \(m=2a\). Since \(n\) is even, there is an integer \(b\) such that \(n=2b\). Therefore \[ m+n = 2a+2b = 2(a+b). \] Because \(a+b\) is an integer, this shows that \(m+n\) has the form \(2k\) for some integer \(k\), namely \(k=a+b\). Hence \(m+n\) is even, as required.
This version is not dramatically longer, but it is much easier to trust. Every introduced variable has a source, and every algebraic step is tied back to the target definition.
7.4 What Actually Changed
The revision did not invent new mathematics. It made the argument verifiable.
That is the clinic mindset:
- preserve the working core idea
- expose hidden assumptions and variable origins
- make the endpoint match the theorem exactly
8 Computation Lens
A strong self-edit pass can be run with this short checklist:
Truth check: have I tested whether the theorem is even true?Setup check: do the assumptions and target appear near the start?Variable check: does every symbol come from somewhere?Method check: does the body actually match the claimed method?Line check: can I justify every nontrivial sentence from earlier facts?Endpoint check: does the last sentence prove exactly the theorem, not a nearby statement?Trim check: can I delete any sentence without harming the argument?
This is the proof analogue of running unit tests, type checks, and a linter before shipping code.
9 Application Lens
Proof clinic habits transfer directly to research work:
- they make theorem statements easier to audit
- they make collaborator feedback more precise
- they reduce the risk of a hidden assumption breaking a later section
- they make paper proofs easier to compress without making them unreadable
In theory-heavy papers, the difference between a strong and weak proof section is often not brilliance. It is disciplined exposition.
10 Stop Here For First Pass
If you can now explain:
- what the main categories of proofwriting bugs are
- how to turn a vague draft into a verifiable proof
- why revising for clarity often improves correctness
- what checklist you would run before submitting a proof
then this page has done its main job.
11 Go Deeper
The most useful companion pages in the proofs module are:
- Counterexamples and Proof Debugging, if you need to decide whether the theorem or the proof is broken
- Contrapositive and Contradiction, if a draft is using an indirect method sloppily
- Induction, if the draft bug is about a bad base case or bad inductive hypothesis
After this page, the natural next move is to start the Logic module or move into Statistics, depending on whether you want more proof fluency or more applied math next.
12 Optional Paper Bridge
- Stanford CS103 Proofwriting Checklist -
First pass- one of the strongest official guides to structure, load-bearing sentences, variable scope, and proof style. Checked2026-04-24. - Stanford Discrete Structures Proofwriting Checklist -
Second pass- great for the next layer of proofwriting precision once objects like functions and graphs enter the picture. Checked2026-04-24. - CMU OLI Logic & Proofs -
Second pass- official interactive environment that supports repeated proof practice with feedback. Checked2026-04-24. - MIT 6.042 Problem Set Instructions -
Paper bridge- short official statement of what graders expect from readable, structured proofs. Checked2026-04-24.
13 Optional After First Pass
If you want more practice before moving on:
- take one of your old proof drafts and annotate the role of every sentence
- rewrite one proof with the goal of deleting every non-load-bearing line
- compare a mathematically correct but sloppy proof with a polished revision and ask what changed
14 Common Mistakes
- assuming clarity is a cosmetic issue instead of a mathematical one
- repeating definitions instead of applying them
- using notation as the verb of a sentence
- introducing a variable and never using it
- ending with a nearby conclusion rather than the actual target statement
15 Exercises
- Take the theorem “If \(n\) is even, then \(n^2\) is even.” Write a proof draft that is mathematically correct but stylistically weak, then revise it.
- Find the bug in this sentence: “Since \(A \subseteq B\), all elements are in \(B\).” What is missing?
- Take any proof from the proofs module and mark each sentence as one of: setup, variable introduction, justified inference, or conclusion.
16 Sources and Further Reading
- Stanford CS103 Proofwriting Checklist -
First pass- outstanding official source for revision habits and recurring proof bugs. Checked2026-04-24. - Stanford Discrete Structures Proofwriting Checklist -
First pass- official supplement showing how proofwriting standards become more precise in discrete structures. Checked2026-04-24. - CMU OLI Logic & Proofs -
Second pass- official interactive logic course with strong support for repeated proof practice. Checked2026-04-24. - MIT 6.042 Problem Set Instructions -
Second pass- concise official reminder that clarity and explicit structure are part of mathematical correctness in practice. Checked2026-04-24.
Sources checked online on 2026-04-24:
- Stanford CS103 Proofwriting Checklist
- Stanford Discrete Structures Proofwriting Checklist
- CMU OLI Logic & Proofs
- MIT 6.042 proof guidelines