A long mathematical solution can be full of correct algebra and still fail because the student never finishes the actual job.
The student proves that two gradients are equal but the question asked for tangency, and no shared point was established. A parameter value is derived under a temporary assumption and then treated as universally valid. A result from part (a) is used in part (c), but the condition under which that result held has quietly disappeared. A diagram suggests two lengths are equal, and the student uses the equality as though it were given. An implication is proved in one direction while the question requires an equivalence. A candidate is generated but never shown to satisfy the original relation. A statement marked “hence” is reached numerically but the logical bridge from the earlier result is missing.
These are failures of proof-obligation control: knowing what the problem has already licensed, what the student has established, what remains conditional, and what still has to be justified before the solution is complete.
This article uses “proof obligation” as a practical training term. It does not imply that every Additional Mathematics question is a formal proof. The idea is simpler:
At every important stage, what are you currently entitled to use, and what do you still owe the problem?
This guide is global and board-agnostic. It applies to Additional Mathematics, Additional Maths, A-Math and comparable advanced secondary mathematics courses worldwide. The official syllabus, command-word conventions, accepted proof standards and mark-scheme requirements of the qualification being taken remain authoritative.
This article continues the eduKateSG examination-performance system after Dependency Chains, Constraint Integrity, State Versioning, Representation Fidelity, Exceptional-Case Control and Notation Integrity. The canonical job here is distinct: tracking the logical obligations that remain open while the mathematical state evolves.
The 50-second route
- Mark the target. What exactly must be found, shown, proved, justified, classified, compared or interpreted?
- Separate givens from assumptions. A diagram hint, a convenient branch or a temporary choice is not automatically a given.
- Separate derived facts from desired facts. Wanting something to be true does not make it available for use.
- Track conditional facts. “If k=2, then…” remains conditional until k=2 is established.
- Do not close an obligation early. Equal gradients alone may not prove tangency; derivative zero alone may not prove a maximum.
- Use prior parts with their conditions attached. The result from part (a) may carry a domain, branch or exactness state.
- Distinguish necessity from sufficiency. A necessary condition may generate candidates without proving the final claim.
- Return generated candidates to the original obligation. Check whether they actually satisfy what had to be shown.
- Use “hence” as a dependency signal. The question may be asking you to exploit an established state, not restart from scratch.
- Finish with closure. State the conclusion that discharges the original target, not merely the last intermediate equation.
Alicia proves something true, but not the thing she was asked to prove
Alicia is asked to show that a line is tangent to a curve at a specified point.
She differentiates the curve, finds the gradient at the point and shows that it matches the gradient of the line.
Then she stops.
Her calculation may be correct, but the proof obligation may still be open if the line has not been shown to pass through the relevant point. Equal gradients can describe parallel lines as well as a tangent relationship.
Alicia did not make a technique error. She made an obligation error: she discharged one sub-obligation and mistook it for the whole claim.
Her repair is to decompose the target:
- shared point;
- matching local gradient where appropriate;
- therefore tangent under the relevant syllabus conditions.
Tricia treats every step as though it needs a formal proof
Tricia reacts by over-justifying. She writes long explanations for routine algebra, names every identity and restates every given.
The result is logically careful but operationally expensive.
Proof-obligation control does not mean writing a proof commentary beside every line. It means knowing where justification is actually carrying the argument.
Tricia needs a hierarchy:
- routine algebra that preserves an already-established relation;
- method transitions that need a condition;
- candidate-generation steps that need later validation;
- logical leaps that need explicit justification;
- final closure that needs to answer the command word.
Kai Kai assumes the diagram is telling the truth
Kai Kai sees a diagram where two lines look perpendicular and a point appears to be a midpoint. He uses both relationships immediately.
Neither was given.
The diagram helped him see a possible route, but it did not license the facts.
His repair is to separate route hypotheses from usable facts. A visual clue may suggest what to investigate. It cannot be promoted to evidence unless the problem or prior mathematics supports it.
Proof obligations are not proof techniques
This article does not own algebraic proof, geometric proof, contradiction, induction or any other proof technique as a topic family.
Its job is earlier and broader: to track what needs proof, what has already been established, and whether the current method has actually discharged the target.
A student can know a proof technique and still leave the wrong obligation open.
Proof obligations are not Command Words
Command words tell the student the form of response expected: find, show, prove, hence, solve, determine, explain or justify according to the qualification.
Proof-obligation control takes that instruction and turns it into a live checklist of unresolved mathematical jobs.
The command word defines the contract. Obligation tracking manages the work needed to satisfy it.
Proof obligations are not State Versioning
State Versioning asks which mathematical state is current. Proof Obligations asks whether that current state is sufficient to justify the next claim or close the target.
A correct current value may still leave a proof obligation open.
Proof obligations are not Constraint Integrity
Constraint Integrity tracks conditions that determine admissibility. Proof Obligations tracks whether those conditions have been used where required to justify the final claim.
A candidate may satisfy the algebra but remain unproved as an answer until the domain or branch condition is applied.
Proof obligations are not Notation Integrity
Notation Integrity keeps symbols semantically consistent. Proof Obligations tracks the logical status of the claims those symbols express.
A beautifully notated statement can still be unproved.
The obligation ledger
A useful training model is an obligation ledger with five basic states:
- GIVEN: licensed directly by the question or an accepted definition/theorem within the course.
- ASSUMED: temporarily adopted for a route, case or contradiction and not yet globally established.
- DERIVED: established from licensed prior states.
- CONDITIONAL: true only while a stated condition remains active.
- OWED: still required before the target is complete.
The student does not need to write these labels in every exam. Training with them makes logical status easier to feel under pressure.
Given is stronger than “looks true”
A given is information the problem has authorised you to use.
Typical sources include:
- explicit statements in the question;
- labelled values or relationships;
- results from earlier parts when the question allows their use;
- definitions and accepted results within the syllabus;
- conditions established by prior working.
A shape in a diagram is not automatically a given merely because it appears visually convincing.
Assumption control
Assumptions are useful when they are explicit and scoped.
Examples:
- assume x ≠ 0 while solving the nonzero branch;
- suppose a parameter lies in one regime;
- take one candidate branch temporarily;
- assume a claimed relation for contradiction where such reasoning is in scope.
The danger is assumption leakage: the temporary state survives after its scope should have ended.
Assumption leakage
Assumption leakage occurs when a conditional or temporary fact becomes treated as global without justification.
For example:
Assume x>0 → derive a convenient form → later use that form for x<0 as though nothing changed.
The repair is to mark assumption entry and assumption exit during training.
Derived facts
A derived fact is available for use only if the chain that produced it remains valid.
Important questions:
- Which givens or earlier results support it?
- Was any branch condition active?
- Was any nonreversible transformation used?
- Does the fact survive a later correction?
- Is it exact or approximate?
This links proof obligations to provenance and State Versioning without duplicating either.
Conditional truth
Some facts are true only inside a condition.
Examples:
- if k=2, the curve has a repeated root;
- for x>0, a chosen transformation has a particular sign interpretation;
- on one branch of a trigonometric solution, θ lies in a stated interval;
- if the stationary point is a maximum, the surrounding behaviour should support that classification.
Conditional statements should not be promoted to unconditional conclusions without closing the condition.
The unresolved target
Long solutions often become busy enough that the original target disappears from working memory.
Keep a compact target statement active:
- find k;
- show tangent;
- prove maximum;
- determine number of roots;
- justify interval;
- find exact area;
- show identity;
- explain parameter range.
This works with Working Legibility: the target should remain easy to recover after interruptions.
Target decomposition
Some commands hide several sub-obligations.
“Show that this line is tangent” may require, depending on the problem:
- shared point or intersection state;
- matching gradient or repeated-root evidence;
- appropriate conclusion.
“Show that a stationary point is a maximum” may require more than f′(x)=0. The exact accepted route depends on syllabus, but the obligation principle is constant: candidate generation and classification are separate jobs.
Necessary versus sufficient conditions
This distinction is one of the most important obligation controls in long solutions.
A necessary condition must hold if the target is true, but may not prove the target by itself.
A sufficient condition is enough, under the relevant assumptions, to establish the target.
Examples of necessary-condition traps include:
- f′(x)=0 gives stationary candidates but does not by itself classify them;
- equal gradients can suggest tangency but may not establish shared contact;
- discriminant conditions can identify candidate parameter thresholds that still need interpretation;
- satisfying a transformed equation may not prove the original equation after a nonreversible step.
Proof-obligation control asks whether the current state is merely necessary or actually sufficient.
Candidate generation is not claim closure
Many methods generate candidates.
- quadratic roots;
- stationary points;
- parameter values;
- trigonometric angle candidates;
- intersection coordinates;
- inequality endpoints;
- values produced after squaring or substitution.
A candidate is a proposal. The obligation remains open until relevant constraints, classification and original-question conditions are satisfied.
The original-relation obligation
Whenever a transformation is not fully reversible, the student owes the original problem a return check.
This is especially important after squaring, cancellation, substitution or branch selection where extra or lost cases are possible.
Exceptional-Case Control owns the special values. Proof Obligations owns the fact that the route is not logically complete until the required return has happened.
The classification obligation
Some questions ask not merely for a value but for a type.
- maximum versus minimum;
- tangent versus secant;
- one root versus two;
- increasing versus decreasing;
- valid versus inadmissible;
- exact versus approximate;
- inside versus outside an interval.
Finding the candidate object does not discharge the classification obligation.
The interpretation obligation
Modelling questions often require a mathematical result to be returned to context.
A value of x may need to become a length, time, area, coordinate or parameter conclusion. A negative root may be mathematically valid but contextually impossible. An extremum may need to be named as the largest permitted physical quantity.
Representation Fidelity protects the return of meaning. Proof Obligations asks whether that interpretation was actually required before the answer contract was satisfied.
The exactness obligation
If the question requires an exact answer, obtaining a decimal candidate does not close the obligation.
If the question requires specified accuracy, an exact form may still need an appropriately rounded presentation.
The target includes answer form as well as mathematical value.
The units obligation
Where units are part of the problem contract, the numerical value alone may not complete the answer.
Units can also provide a plausibility check on interpretation. A result representing area should not return with a length unit.
The “hence” obligation
“Hence” usually signals dependency on an earlier result according to the assessment’s conventions.
The student should ask:
- Which earlier state is intended to be reused?
- What new target becomes cheap because that state is available?
- Does the earlier result carry conditions that must remain attached?
- Can the new claim be reached by a short dependency rather than a full restart?
Restarting from scratch can be valid but may waste time and miss the intended connection.
The “show that” obligation
A “show that” question gives the destination but not permission to assume the destination.
Students sometimes work backwards from the displayed result and accidentally use the target as a premise.
Backward reasoning can be useful for route discovery. But the final written argument must establish the target from authorised states rather than depend circularly on the statement being shown.
Circular reasoning
Circular reasoning occurs when the conclusion is used, directly or indirectly, to justify itself.
Typical signals:
- starting from the required identity and transforming until a known truth appears, without reversing the chain or proving equivalence;
- using the claimed parameter value to establish the condition that was supposed to determine that parameter;
- assuming tangency in order to derive the tangency condition;
- using a result from a later part as though already established.
Route discovery can move backward mentally. Proof closure must move forward from licensed states.
Forward derivation and backward planning
Strong problem solving often combines two directions:
- backward planning: what would be enough to prove the target?
- forward derivation: what can be established from the givens?
The solution becomes efficient when the two fronts meet at a valid bridge.
This is not the same as the BTT specialist owner on backward reasoning and target decomposition. Here the focus is not method selection; it is maintaining the logical boundary between planning assumptions and proved states.
Obligation dependencies
Some obligations cannot be closed until earlier ones are discharged.
Example:
prove point lies on curve → determine gradient there → compare line gradient → conclude tangency.
Skipping the first obligation weakens everything downstream.
This links to Dependency Chains: logical obligations can have dependency structure just as numerical states do.
High-propagation obligations
Some obligations deserve early checking because many later claims depend on them.
- the model equation is valid;
- the chosen branch is admissible;
- the parameter candidate satisfies the event;
- the transformation is reversible or later checked;
- the linked result from part (a) is being used under the right conditions.
A missed high-propagation obligation can make a long solution internally consistent but globally unsupported.
Obligation closure
An obligation closes when the required claim follows from authorised prior states under the relevant syllabus standard.
Closure should be visible enough that the student knows the job is complete.
Examples:
- candidate tested in original relation;
- endpoint compared;
- stationary candidate classified;
- shared point plus gradient relation established;
- parameter range combined with admissibility constraint;
- final contextual quantity stated with required form.
False closure
False closure occurs when a student feels finished because the algebra has produced a neat value.
Common signals:
- the value is not yet in the requested variable;
- classification is missing;
- domain filtering is missing;
- an assumption is still active;
- a candidate has not returned to the original relation;
- the command word asked for justification, not only computation;
- the final answer needs exactness, units or interpretation.
Obligation reopening after correction
A corrected upstream state can reopen obligations that appeared closed.
If a parameter changes, a previously checked domain, root count, geometry event or classification may need to be revisited.
This is a major interaction with State Versioning: retiring an old state can invalidate the logical closure built on that state.
Obligation inheritance across linked parts
Part (b) can inherit both results and unresolved obligations from part (a).
Before using an earlier result, ask:
- Was it fully established or only a candidate?
- Was it exact?
- Which branch produced it?
- Which assumptions remained active?
- Did the question explicitly invite reuse?
Linked-part performance improves when the student inherits the logical status, not merely the number.
Proof-obligation provenance
Every nontrivial claim should have enough provenance that the student can answer, “Why am I allowed to say this?”
- given by the question;
- definition;
- earlier result;
- algebraic derivation;
- domain condition;
- graph property established previously;
- case assumption;
- accepted syllabus theorem or identity.
Provenance need not be written in full every time. It must remain recoverable.
The proof-obligation checksum
At a major transition, ask:
What is given? What is assumed? What is derived? What is still conditional? What do I still owe?
This five-question checksum is deliberately compact.
The proof-obligation dashboard
| Measure | Question | Desired direction |
|---|---|---|
| Target loss | How often does the student forget the original job? | Down |
| Assumption leakage | How often do temporary assumptions become global? | Down |
| Candidate promotion | How often are generated values treated as proved answers? | Down |
| False closure | How often does the student stop before classification/filtering/interpretation? | Down |
| Circularity | How often is the target used as a premise? | Down |
| Dependency coverage | Are high-propagation obligations closed before downstream use? | Up |
| Reopening awareness | Are obligations revisited after corrections? | Up |
| Closure precision | Does the final line actually answer the command word? | Up |
Alicia’s proof-obligation programme
Alicia’s risk is false closure after one convincing calculation.
- rewrite the command word as a target;
- decompose targets that require more than one property;
- label candidate versus final states during review;
- force one final question: “What is still owed?”;
- audit where correct algebra failed to close the requested claim.
Her success metric is not longer answers. It is fewer unfinished logical jobs.
Tricia’s proof-obligation programme
Tricia’s risk is over-justification.
- separate routine algebra from claim-changing transitions;
- justify only where the logical state changes materially;
- compress repeated reasons into stable conventions;
- measure time overhead;
- retain explicit closure only for obligations that genuinely need it.
Her mature system becomes rigorous without becoming verbose.
Kai Kai’s proof-obligation programme
Kai Kai’s risk is promoting visual or intuitive hypotheses into usable facts.
- mark diagram-based ideas as route hypotheses;
- ask what licenses each nontrivial relationship;
- separate backward planning from forward proof;
- close the high-propagation obligation before accelerating;
- stress the same routine late in timed papers.
His speed remains useful because the logical floor beneath it becomes visible.
Frequently asked questions about proof obligations in A-Math
Do I need to write “given”, “assumed” and “derived” in the exam?
Usually not as a formal labelling system. The labels are a training device. In the examination, use the normal notation and reasoning conventions accepted by your qualification while keeping the logical status clear.
Why is f′(x)=0 not enough to prove a maximum?
It identifies a stationary candidate. Classification is a separate obligation and must be handled using an accepted method for the syllabus and problem.
Can I work backwards from a “show that” result?
You can use backward reasoning to discover a route, but the final argument must establish the target from authorised states without circularly assuming what had to be shown.
When is a candidate value actually proved?
When it satisfies all obligations relevant to the target: the derivation is valid, constraints are met, any required original-relation check is passed, and the final command word is answered.
Why does “hence” matter?
It often signals that an earlier established result is intended to discharge part of the new obligation efficiently. The exact convention depends on the examination, but the dependency signal is important.
A final proof-obligation checklist
- I know the exact target.
- I know which facts are explicitly given.
- I do not treat a diagram appearance as a given.
- I know which assumptions are temporary.
- I know when those assumptions stop applying.
- I distinguish desired facts from established facts.
- I distinguish candidates from accepted results.
- I distinguish necessary conditions from sufficient closure.
- I return candidates to the original relation when required.
- I classify stationary, parameter or geometric candidates when required.
- I restore domain, interval and branch conditions before closure.
- I preserve exactness and answer-form requirements.
- I preserve units and context when required.
- I use earlier parts with their conditions attached.
- I use “hence” as a dependency signal rather than ignoring it.
- I do not use the target as a premise in “show that” work.
- I reopen dependent obligations after an upstream correction.
- I can explain why every high-value claim is licensed.
- I finish with the conclusion the command word actually asked for.
- I can answer, at any major stage, “What do I still owe?”
The Proof-Obligation Laboratory
Proof-obligation control becomes reliable when students practise logical status separately from topic technique. The laboratory below deliberately creates unfinished, conditional and over-claimed solutions so the student learns to detect what is still owed.
Lab 1: given, assumed, derived, owed
Take a short question and sort every important statement into four columns: given, assumed, derived and owed.
Do not solve immediately. The purpose is to separate information the question has licensed from information the student merely hopes to establish.
Lab 2: false closure detection
Give ten partially completed solutions that stop one step too early. Examples include:
- stationary candidate found but not classified;
- parameter solved but not checked in the original event;
- intersection coordinate found but wrong branch not filtered;
- exact value derived but decimal answer requested;
- gradient matched but common point not shown;
- candidate roots found after squaring but not checked in the original equation.
The student’s only task is to write the missing obligation.
Lab 3: necessary or sufficient?
Present statements such as “f′(a)=0”, “discriminant = 0”, “two gradients are equal” or “the point satisfies one equation”. Ask whether the statement is necessary, sufficient, both, or neither for the target under the problem’s conditions.
The goal is not formal logic vocabulary for its own sake. It is to stop candidate-generating conditions from masquerading as finished proofs.
Lab 4: assumption entry and exit
Use a case split. Require the student to mark where an assumption begins and the final line on which that assumption is allowed to control the reasoning.
Then insert one line from the assumed branch into the other branch and ask the student to identify the leakage.
Lab 5: show-that circularity
Give a “show that” result and two proposed solutions:
- one begins from authorised givens and reaches the target;
- one begins from the target, transforms it into something known and never establishes reversibility.
The student identifies which route is logically complete and how the second could be repaired.
Lab 6: diagram versus evidence
Use diagrams deliberately drawn to suggest relationships that are not given: equal lengths, right angles, midpoints or tangency.
Ask the student to separate:
- visual route hypotheses;
- explicit givens;
- relationships that still need proof.
Lab 7: hence dependency
Give a linked question where part (b) can be solved efficiently using a result from part (a). Ask the student to identify exactly which earlier fact discharges which new sub-obligation.
Then compare the dependency route with a full restart and measure the time difference.
Lab 8: reopened obligation
Take a completed long solution and change one upstream value. The student must identify which apparently closed claims are no longer secure.
- domain membership;
- parameter event;
- classification;
- graph interpretation;
- downstream linked answers.
This makes obligation closure dynamic rather than permanent.
Lab 9: conclusion matching
Give a set of final lines and command words. Ask whether each final line truly closes the requested job.
- “x=4” after a request for a coordinate;
- “f′(x)=0” after a request to show a maximum;
- “k=2” after a request to determine the range of k;
- “area=12” after a question requiring exact units;
- “two roots” after a question requiring the parameter interval producing two roots.
Lab 10: full obligation map
Use one multi-part synthesis question. Build a map:
givens → sub-obligations → derived states → filters → classifications → final closure.
The student then solves the question while crossing obligations off only when the required evidence has genuinely been established.
The Proof-Obligation Failure Atlas
Failure 1: desired fact promotion
The student uses what they are trying to prove as though it were already available.
Repair: separate target from givens and derived states.
Failure 2: diagram promotion
A visual feature is treated as evidence.
Repair: mark it as a route hypothesis until mathematically licensed.
Failure 3: assumption leakage
A temporary case condition becomes global.
Repair: explicit assumption scope and branch exit.
Failure 4: candidate promotion
A generated value is treated as the answer before filtering or classification.
Repair: keep candidate status until all relevant obligations close.
Failure 5: necessary-condition closure
A condition that must hold is mistaken for a condition that proves the claim.
Repair: ask what additional evidence makes the condition sufficient.
Failure 6: circular proof
The target enters the argument as a premise.
Repair: preserve backward work as planning, then rewrite the final chain forward from authorised states.
Failure 7: classification omission
The candidate exists, but its type has not been established.
Repair: create a separate classification obligation.
Failure 8: answer-form omission
The mathematics is complete but the requested exactness, units, interval form or contextual interpretation is missing.
Repair: include answer form inside the target from the start.
Failure 9: stale closure
A downstream claim remains marked as proved after an upstream correction invalidates its foundation.
Repair: reopen dependent obligations when authoritative states change.
Failure 10: conclusion mismatch
The final line answers a nearby question rather than the actual command word.
Repair: compare the final conclusion directly with the original target before leaving the question.
Obligation authority levels
- Unopened: a target not yet addressed.
- Active: currently being worked on.
- Conditional: apparently satisfied under an assumption still needing closure.
- Closed: sufficiently established under the assessment standard.
- Reopened: closure invalidated by correction or new information.
- Retired: obligation removed because the route or branch was rejected.
This is a training model, not formal examination terminology. Its purpose is to make logical status visible enough to manage.
Proof Obligations Under Full-Paper Pressure
Proof-obligation failures are especially dangerous under examination pressure because they often look like successful solving. The page contains algebra. Numbers appear. A parameter emerges. A stationary point is found. The student feels progress and moves on.
The missing work is logical rather than computational, so it is easier to overlook when time is tight.
The obligation budget
Do not spend equal effort justifying every line. Spend attention where the logical status changes.
- when a candidate is generated;
- when a new assumption is introduced;
- when a route becomes conditional;
- when a prior part is imported;
- when a nonreversible transformation is used;
- when classification is required;
- when the answer form changes from working state to final state;
- when an upstream correction invalidates earlier closure.
Routine algebra inside a stable logical state usually needs less attention than these boundary moments.
Proof obligations under time debt
When behind time, students often skip exactly the steps that close obligations: testing a candidate, checking an endpoint, writing the final conclusion, restoring the original variable or verifying a parameter event.
Use a minimum viable closure routine:
- read the command word again;
- identify the current candidate or derived state;
- ask what one condition still separates candidate from answer;
- perform that check;
- state the requested conclusion.
This is usually cheaper than losing a method-mark chain because the final obligation was never discharged.
Proof obligations under fatigue
Late-paper fatigue increases false closure. A neat value feels finished because working memory has less capacity to hold the original target.
Late in the paper, use fixed triggers:
- candidate found → classify/filter;
- parameter found → return to event;
- stationary point found → classify;
- transformed variable solved → return to source variable;
- interval found → check endpoint status;
- linked value imported → restore conditions;
- final line → match command word.
Proof obligations after interruption
If a question is skipped and revisited, the student may remember the algebra but forget what remained unproved.
Before leaving a difficult question, preserve a re-entry capsule:
- current target;
- last closed obligation;
- current candidate or conditional state;
- next obligation;
- active assumption if any.
This works with Working Legibility and State Versioning to reduce reconstruction cost.
Proof obligations after a correction
When an upstream state changes, logical closure must be re-evaluated.
A corrected value can reopen:
- domain membership;
- branch admissibility;
- stationary-point classification;
- tangency evidence;
- parameter interpretation;
- linked-part conclusions;
- rounding or answer-form obligations.
The student should not preserve a conclusion merely because it was once written.
Proof obligations and Checkpoint Architecture
Checkpoint Architecture becomes more precise when checkpoints are attached to obligations rather than arbitrary line counts.
High-yield checkpoints include:
- before a candidate propagates;
- after a temporary assumption has done its work;
- when a necessary condition is about to be treated as sufficient;
- before an earlier-part result is reused downstream;
- before final answer formatting.
Proof obligations and Reliability Testing
Reliability Testing should vary logical structure as well as topic.
- questions where the candidate is already sufficient;
- questions where classification is still needed;
- questions with hidden endpoint obligations;
- show-that questions vulnerable to circularity;
- hence questions requiring reuse;
- linked parts carrying conditions;
- questions with misleading diagrams;
- questions where correction reopens earlier work.
If the student succeeds only when the logical structure is familiar, obligation control is not yet robust.
Proof obligations and Question Compression
Question Compression should preserve the unresolved target, not just the numerical state.
A strong compressed state may be:
target: prove max | candidate x=a | still owe: classification + endpoint comparison.
This is more useful than carrying only x=a, because it preserves what the candidate is for and what remains unfinished.
Proof obligations and Decision Latency
Clear obligation recognition can reduce Decision Latency. If the student knows that the remaining job is classification, method search becomes narrower.
Many long-question stalls occur because the student knows the current mathematics but no longer knows what subproblem remains.
Proof obligations and Load Tolerance
Externalising the active obligation reduces cognitive load. The student does not need to hold the whole logical structure mentally while executing algebra.
One short target note can preserve the reasoning architecture through a long manipulation sequence.
Proof obligations and Score Stability
Obligation errors create unstable performance because they depend heavily on question wording and structure. A student may score strongly on direct “find” questions and lose marks on “show”, “hence”, classification or linked-part questions despite similar mathematics.
Training obligation families raises the score floor by reducing sensitivity to those structural variations.
Proof obligations and Performance Headroom
When obligation tracking becomes automatic, fewer cognitive resources are spent wondering whether the problem is finished.
That preserves Performance Headroom for genuinely unfamiliar mathematics.
The full-paper proof-obligation audit
After a fresh paper, review not just wrong answers but unfinished logical jobs.
| Obligation event | Audit question | Failure signal |
|---|---|---|
| candidate generated | Was it validated? | candidate promotion |
| assumption introduced | Was its scope closed? | assumption leakage |
| show-that target | Was the target used as a premise? | circularity |
| stationary point | Was classification completed? | false closure |
| parameter value | Was original event restored? | detached parameter |
| linked part | Were inherited conditions preserved? | status loss |
| final answer | Did it match the command word and answer form? | conclusion mismatch |
The obligation heatmap
| Obligation family | Fresh | Timed | Late | Full paper |
|---|---|---|---|---|
| target retention | Green? | Green? | Amber? | Green? |
| candidate validation | Green? | Amber? | Amber? | Green? |
| assumption scope | Green? | Amber? | Amber? | Amber? |
| classification | Green? | Green? | Amber? | Green? |
| show-that closure | Green? | Amber? | Amber? | Green? |
| linked-part inheritance | Green? | Amber? | Amber? | Amber? |
| answer-form closure | Green? | Green? | Amber? | Green? |
The colours are training shorthand, not official assessment categories.
A one-week proof-obligation cycle
Day 1: target and ledger
Separate givens, assumptions, derived states and unresolved targets across short questions.
Day 2: candidates and classification
Train the difference between generating a candidate and proving the final claim.
Day 3: assumptions and circularity
Practise case scope, backward planning and forward proof closure.
Day 4: linked parts and hence
Track which earlier result discharges which later obligation.
Day 5: answer-form closure
Train exactness, units, interval form and context as part of the target itself.
Day 6: timed mixed obligations
Use mixed-topic questions and record false closure, assumption leakage and conclusion mismatch.
Day 7: full-paper transfer
Run a fresh representative paper and audit every unfinished or falsely closed logical job.
A four-week proof-obligation cycle
- Week 1: givens, assumptions, targets and candidate status.
- Week 2: necessity, sufficiency, classification and original-relation return.
- Week 3: show-that circularity, hence dependencies, linked-part inheritance and corrections.
- Week 4: timed mixed practice, late-paper stress and full-paper regression tests.
The proof-obligation readiness gate
Proof-obligation control is approaching examination readiness when fresh representative work shows that:
- the target remains visible through long algebra;
- givens are not confused with diagram impressions;
- temporary assumptions stay scoped;
- candidate values are not promoted early;
- necessary conditions are not mistaken for full closure;
- classification obligations are completed reliably;
- nonreversible transformations trigger original-relation checks;
- show-that reasoning avoids circularity;
- hence questions use earlier states efficiently;
- linked parts preserve logical status and conditions;
- corrections reopen dependent obligations when necessary;
- final lines match the command word, answer form and context;
- closure survives realistic speed and late-paper fatigue.
Proof obligations in the final revision phase
Close to the examination, consolidate a small set of obligation triggers rather than inventing a large logic notation system:
- candidate → validate;
- assumption → close scope;
- stationary → classify;
- show that → do not assume target;
- hence → reuse prior state;
- correction → reopen dependents;
- final line → match command word.
Proof obligations on examination day
Keep the target alive. Use only facts the mathematics has licensed. Let assumptions remain temporary. Treat candidates as candidates until the required checks are complete. Use earlier results with their conditions attached. Reopen closure after meaningful corrections. Finish by answering the exact job the command word created.
The paper rewards mathematics that reaches the required conclusion, not merely mathematics that produces activity.
The proof-obligation operating loop
The complete loop is:
Read Contract → Mark Target → Separate Given and Assumed → Derive → Track Conditions → Generate Candidate → Validate → Classify → Close Obligation → Reopen if State Changes → Match Final Conclusion.
Read what the question is actually asking. Mark the target. Separate licensed facts from temporary assumptions. Derive new states without promoting wishes into evidence. Track the conditions under which each state is true. Generate candidates where the method requires them. Validate those candidates. Classify when the target demands classification. Close the obligation only when sufficient evidence exists. If an authoritative state changes, reopen every dependent claim. Finally, match the written conclusion to the original command word and answer contract.
That is how long mathematical solutions become logically complete rather than merely computationally busy.
The deeper idea: a solution is a set of debts being paid
A mathematical question creates obligations. Every legitimate step can discharge one obligation, create another, or move an obligation into a different representation.
Alicia learns that one true intermediate result does not automatically close the whole target. Tricia learns that rigor is selective rather than verbose. Kai Kai learns that a plausible relationship is still only a hypothesis until the mathematics licenses it.
The governing question becomes:
What has the mathematics already paid for, and what does the solution still owe?
When the student can keep that ledger accurately, long solutions become easier to finish, easier to audit and much harder to derail through hidden logical gaps.
Continue through the eduKateSG Additional Mathematics performance system
- Additional Mathematics Examination Performance
- Additional Mathematics Score Stability
- Additional Mathematics Accuracy Reserve
- Additional Mathematics Load Tolerance
- Additional Mathematics Decision Latency
- Additional Mathematics Dependency Chains
- Additional Mathematics Fatigue Curve
- Additional Mathematics Performance Headroom
- Additional Mathematics Question Compression
- Additional Mathematics Execution Debt
- Additional Mathematics Reliability Testing
- Additional Mathematics Constraint Integrity
- Additional Mathematics State Versioning
- Additional Mathematics Checkpoint Architecture
- Additional Mathematics Working Legibility
- Additional Mathematics Representation Fidelity
- Additional Mathematics Exceptional-Case Control
- Additional Mathematics Notation Integrity
- Additional Mathematics Hub: Start Here for A-Math