Additional Mathematics Repair Sequencing | How to Fix Multiple Errors in the Right Order Without Rebuilding Correct Work

The Repair Sequencing Laboratory

Repair sequencing becomes reliable only when students practise with solutions containing more than one confirmed fault. The laboratory below deliberately separates diagnosis from repair order: the student is told what is wrong, then must decide what to fix first, what to invalidate, what to preserve and what to retest.

Lab 1: the upstream parameter

Give a linked problem with a confirmed wrong parameter k, two wrong substitutions that use k, and one independent arithmetic slip in a side calculation.

The student must sequence repairs. Correct k first, regenerate its dependents once, then repair the independent arithmetic slip separately. Measure how much duplicate work is avoided compared with fixing errors in page order.

Lab 2: independent branches

Create two branches that do not share a downstream state. Place one confirmed error in each. Ask whether repairing Branch A should invalidate Branch B.

The correct answer is no unless a shared global condition changes. The exercise trains selective preservation rather than global restart.

Lab 3: coupled faults

Place one wrong equation upstream and a later wrong candidate generated from it. Both are confirmed faults. Ask which fault has precedence.

The candidate should not be “fixed” directly because it may disappear automatically when the equation is repaired and solved again.

Lab 4: masking-aware repair order

Use two compensating sign errors. Tell the student both are confirmed. Ask which to repair first and what to expect after the first repair.

The student should choose the more upstream error, accept that the endpoint may temporarily become worse, then repair the second fault and regression-test.

Lab 5: invalidation-radius mapping

Mark one wrong intermediate result in a long solution. Ask the student to label every later state as DIRECT DEPENDENT, INDIRECT DEPENDENT, INDEPENDENT, RETIRED or UNCERTAIN.

Only after the map is complete may the repair begin. This separates correction from panic-driven rewriting.

Lab 6: recompute versus revalidate

Correct a branch condition that changes admissibility but does not change a previously derived symbolic identity. Ask which states need full recomputation and which need only contextual revalidation.

The goal is to distinguish changed mathematics from changed authority.

Lab 7: branch-changing repair

Give a parameter correction that crosses a threshold and changes the valid branch. The student must retire the old branch entirely rather than insert the new parameter into old branch-local formulas.

Score whether stale branch assumptions survive the repair.

Lab 8: calculator-state repair

Use one wrong calculator mode and one independent algebraic slip. The student must identify which outputs actually depend on the calculator state and avoid recomputing page-only algebra that is unaffected.

Lab 9: repair reveals a hidden fault

Plant two compensating errors. Reveal only one first, let the student repair it, and then show the resulting deterioration in the endpoint. Ask the student to preserve the confirmed correction and search for the newly unmasked second fault.

The lesson is that repair can increase visible error while decreasing actual mathematical error.

Lab 10: restart threshold

Present three repair scenarios: one local fault, one medium-fan-out fault, and one heavily contaminated state with several crossing dependencies. Ask the student to choose LOCAL REPAIR, SECTION RESTART or FULL QUESTION RESTART and justify the cost.

The purpose is to make restart a reasoned economic decision rather than a reflex.

The Repair Sequencing Failure Atlas

Failure 1: page-order repair

The student fixes errors in the order they appear visually, ignoring dependency structure.

Repair: identify governing ancestors before touching downstream symptoms.

Failure 2: final-answer-first repair

The student recomputes the final lines while an upstream confirmed error is still active.

Repair: restore the upstream authority first, then regenerate the endpoint once.

Failure 3: global invalidation

One local correction causes the student to distrust the whole question.

Repair: map invalidation radius and preserve independent branches.

Failure 4: under-invalidation

The source state changes, but stale dependents remain active.

Repair: retire every direct dependent before rebuilding the chain.

Failure 5: over-invalidation

Correct independent work is erased because it happens to appear after the faulty line on the page.

Repair: use dependency, not chronology, to decide what survives.

Failure 6: symptom patching

A late result is changed manually to look right while the upstream source remains wrong.

Repair: correct the source state and recompute honestly.

Failure 7: masking reversal

A verified correction makes the endpoint worse, so the student restores the old mistake.

Repair: keep the confirmed repair and search for the compensating fault.

Failure 8: stale branch survival

A corrected parameter changes the regime, but formulas from the previous branch remain in use.

Repair: treat branch identity as part of state authority and retire invalid branch-local work.

Failure 9: duplicate recomputation

A downstream state is recomputed, then recomputed again after its upstream source is later fixed.

Repair: sequence upstream high-fan-out repairs first.

Failure 10: no regression closure

All known errors are repaired, but the rebuilt chain is never tested as a system.

Repair: run a final consistency, constraint, branch and endpoint regression check.

Repair-state lifecycle

1. Fault Confirmed: the state is known to be wrong.
2. Dependency Mapped: affected downstream states are identified.
3. Priority Assigned: the repair is ordered relative to other faults.
4. Source Repaired: the governing state is corrected.
5. Dependents Invalidated: stale states lose authority.
6. Recomputed/Revalidated: only affected work is rebuilt.
7. Fault List Reopened: masking changes and disappearing symptoms are reassessed.
8. Next Fault Repaired: remaining confirmed faults are processed in sequence.
9. Regression-Tested: the rebuilt chain is checked.
10. Closed: no known fault or stale dependent remains active.

A worked sequencing pattern: parameter, branch, arithmetic

Suppose a student has three confirmed faults: k was solved incorrectly, the sign of a branch condition is wrong, and a later multiplication is incorrect.

Do not fix the multiplication first. First correct k. Then re-evaluate the branch condition because the corrected k may move the problem into a different regime. Only after the correct branch is active should the late multiplication be rechecked—because the line containing that multiplication may no longer even belong to the valid route.

A worked sequencing pattern: derivative, coordinate, classification

Suppose f′(x) contains a confirmed coefficient error, the stationary x-value is wrong, and the final point is mislabeled a maximum.

Repair f′ first. Regenerate stationary candidates. Re-evaluate y-values from the original function. Then classify the corrected stationary point. The classification is last because it depends on the corrected local state.

A worked sequencing pattern: exactness, calculator, final rounding

Suppose an exact surd was prematurely rounded, the calculator input then used the rounded value incorrectly, and the final answer was rounded to the wrong number of significant figures.

Restore the exact or high-precision state first. Re-enter the correct calculator expression. Only then apply final answer rounding. Fixing final formatting before repairing numerical provenance is wasted work.

A worked sequencing pattern: two independent faults

Suppose Branch A contains a confirmed endpoint omission while Branch B contains a wrong coordinate substitution. Neither depends on the other. If time is short, repair whichever branch carries more remaining marks or has lower repair cost first. There is no mathematical need to force an upstream/downstream order where none exists.

Repair sequencing and State Versioning

State Versioning is essential during multi-fault repair because corrected and stale states often coexist on the page. Every major repair should explicitly establish which state is CURRENT and which is RETIRED.

Repair sequencing and Solution Transactions

Solution Transactions can reduce repair scope by containing speculative work. If a fault remains inside an uncommitted transaction, roll back locally instead of invalidating the trusted main solution.

Repair sequencing and Parallel-Route Isolation

When one of two routes fails, Parallel-Route Isolation helps preserve the unaffected route. Do not invalidate a clean independent route merely because another route needs repair.

Repair sequencing and Error Cancellation

When faults compensate, repair order must be chosen by dependency and authority rather than by which correction keeps the endpoint looking good. The endpoint may become less plausible halfway through a correct repair sequence.

Repair sequencing and Working-State Synchronisation

After each major correction, synchronize mind, page and tool state before proceeding. Otherwise the student may repair the written state while continuing mentally from a stale value, creating a new fault during the repair itself.

Repair Sequencing Under Full-Paper Pressure

Repair sequencing matters most when time is scarce. During a full paper, the student rarely has enough time to rebuild an entire long solution every time a fault is found. The purpose of sequencing is to recover marks while controlling recomputation cost.

The repair budget

Every repair consumes time, attention and page clarity. The student should spend more repair effort when the fault is high-leverage and less when the remaining mark return is small.

Increase repair investment when:

• the fault controls several later parts;
• the repair source is easy to identify;
• the affected question carries substantial marks;
• a single upstream correction could restore many later states;
• the route is otherwise sound;
• the last trusted state is clear.

Reduce repair investment when the dependency graph is hopelessly contaminated, the remaining marks are few, or a clean restart elsewhere offers better expected return.

The three repair modes

The restart threshold

Restart is justified when local repair becomes more expensive than clean re-execution.

• the last trusted state cannot be identified;
• several coupled faults cross the same region;
• stale and current states are visually inseparable;
• branch identity is uncertain;
• tool and page states disagree in several places;
• repair radius covers almost the whole remaining solution;
• the student cannot tell which downstream states remain authoritative.

The rule is not “never restart.” It is “restart after the dependency economics justify it.”

Under time debt

When behind time, simplify the repair queue.

1. Repair the highest-fan-out fault first.
2. Ignore cosmetic or final-format faults until structural faults are closed.
3. Preserve independent correct branches.
4. Use one regression checkpoint after each major repair.
5. If a section becomes too contaminated, mark the last trusted state and move on rather than repeatedly patching.

Under fatigue

Fatigue increases a specific repair hazard: the student may create new faults while fixing old ones.

Late-paper repair should therefore become more explicit:

• cross out or label retired states;
• rewrite the corrected authoritative state clearly;
• avoid mental-only corrections;
• re-enter calculator values rather than relying on stale memory;
• restate the current branch before continuing;
• keep exact/decimal authority visible.

After interruption

Returning to a partially repaired question is high-risk because the repair queue may no longer be mentally active.

Before resuming, reconstruct four things:

1. Which faults were already confirmed?
2. Which faults have been repaired?
3. Which dependents were invalidated?
4. What is the current authoritative state?

If any of these cannot be reconstructed cheaply, restart from the nearest clearly trusted state rather than blending old and new versions.

Repair sequencing in linked questions

Linked questions create repair leverage because one early state may feed several later parts. They also create repair risk because a wrong anchor can contaminate an entire chain.

When a linked part fails:

1. check whether the imported anchor is confirmed wrong;
2. if wrong, repair the anchor before any later part;
3. invalidate only parts that actually consumed it;
4. preserve independent subparts;
5. recompute in dependency order;
6. recheck the answer contract for every regenerated part.

Repair sequencing in “hence” questions

“Hence” structures often create strong dependency. If the supplied or previously established result is valid, it becomes a trusted anchor. If the student’s own earlier derivation of that result is wrong but the question permits using the given result, the repair strategy may differ from ordinary linked work.

Keep the official problem state distinct from the student’s faulty derivation. Do not let one failed derivation unnecessarily invalidate a later section that is allowed to start from the stated result.

Repair sequencing when method choice changes

A repair can reveal that the current method is no longer economical. For example, correcting a parameter may destroy the simplification that made the original route attractive.

In that case:

1. repair the authoritative state;
2. reassess method viability;
3. retire the old route if its advantage disappeared;
4. switch method from the last trusted state;
5. do not carry stale provisional outputs into the new route.

Repair sequencing when a constraint changes

If a correction alters the domain, interval, branch or admissibility condition, every downstream candidate must be reconsidered under the new constraint state.

A candidate that was previously valid may become inadmissible; a previously rejected candidate may become valid. Constraint changes therefore deserve early repair because they can redefine the entire answer set.

Repair sequencing when notation was overloaded

Suppose the same symbol was accidentally used for two different objects, creating several downstream inconsistencies. Fix the notation authority first. Rename or restore symbol roles, then reevaluate only the lines whose meaning depended on the collision.

Repair sequencing when precision was mixed

If exact and approximate states were mixed, establish one authoritative precision state before correcting late decimals. Otherwise every numerical repair remains vulnerable to another rounding pass.

Repair sequencing when calculator state was wrong

A wrong calculator mode can contaminate many numerical outputs while leaving symbolic work intact. Repair the tool state first, then re-run only the numerical dependents. Preserve symbolic derivations that did not depend on the tool.

Repair sequencing when the original representation was wrong

If the student translated the problem incorrectly at the start, downstream repairs are usually low-value. A wrong model, equation or diagram interpretation sits above the entire route.

Return to the original wording or diagram, correct the representation, and then decide whether any downstream work survives. Often the repair radius is global.

The full-paper repair audit

The repair heatmap

The colours are training shorthand, not official assessment categories.

A one-week repair sequencing cycle

Day 1: dependency precedence

Order confirmed faults in simple one-chain solutions.

Day 2: independent versus coupled faults

Classify fault pairs before deciding repair order.

Day 3: invalidation radius

Label recompute, revalidate, preserve and retire states after source corrections.

Day 4: masking-aware repair

Repair compensating faults without restoring known errors when the endpoint temporarily worsens.

Day 5: branch-changing corrections

Practise retiring invalid regimes and rebuilding only the new branch.

Day 6: timed repair economics

Choose between local repair, section restart and abandoning the question temporarily.

Day 7: full-paper repair audit

Review all corrections made in a fresh timed paper for order, wasted recomputation and stale-state survival.

A four-week repair sequencing cycle

1. Week 1: dependency graphs, precedence and last-trusted-state recovery.
2. Week 2: invalidation radius, independent branches and state retirement.
3. Week 3: masking-aware repair, branch changes, tool-state corrections and restart thresholds.
4. Week 4: timed linked questions, late-paper repair economics and full-paper regression.

The repair sequencing readiness gate

Repair Sequencing is approaching examination readiness when fresh representative work shows that:

• confirmed faults are mapped before major repair begins;
• upstream governing faults are usually repaired before downstream symptoms;
• independent branches are preserved;
• stale dependents are reliably retired;
• students distinguish recomputation from revalidation;
• branch-changing corrections trigger branch re-selection;
• masking does not cause verified repairs to be reversed;
• repair spirals are stopped by timely section restart;
• late-paper repairs create few new errors;
• the final repaired chain receives a regression check;
• the student can explain why the chosen repair order was efficient.

Repair Sequencing in final revision

Close to the examination, compress the system into eight triggers:

• multiple confirmed errors? → map who depends on whom;
• one fault feeds many? → repair it first;
• independent branch? → preserve it;
• source corrected? → retire dependents before rebuilding;
• endpoint worsens? → check for unmasked second fault;
• branch changed? → retire old branch;
• repair radius exploding? → consider section restart;
• repairs finished? → regression-test the whole local chain.

Repair Sequencing on examination day

When several errors are confirmed, do not attack the page randomly. Find the fault that governs the most later work. Fix it. Cross out or retire stale dependents. Recompute only what actually used the corrected state. Keep independent work. If the answer becomes worse, do not restore a known mistake—look for the second fault that had been masking it.

The repair sequencing operating loop

The complete loop is:

Confirm Faults → Map Dependencies → Separate Independent and Coupled Faults → Rank by Precedence/Fan-out/Criticality/Masking → Repair Governing Fault → Invalidate Dependents → Recompute or Revalidate → Reopen Fault List → Repair Next → Regression-Test → Close.

Confirm what is genuinely wrong. Map which states depend on which faults. Separate errors that can be repaired independently from those whose effects are coupled. Rank the coupled faults by dependency precedence, fan-out, state criticality, masking risk and repair cost. Repair the governing fault first. Retire stale dependents and regenerate only the affected region. Then reassess the remaining faults because some may disappear and others may become newly visible. Continue until every confirmed fault is closed, then regression-test the rebuilt chain before restoring full trust.

Advanced Repair Sequencing Casebook

The following casebook moves beyond short demonstrations. Each case contains multiple confirmed faults and forces a sequencing decision. The purpose is not merely to reach the correct answer. It is to rebuild authority with the least unnecessary work while preserving states that were never damaged.

Case 1: the corrupted quadratic pipeline

A quadratic parameter problem produces four confirmed faults. First, the coefficient of x was copied incorrectly from the question. Second, the discriminant was calculated from that copied equation and is therefore wrong. Third, one candidate parameter was filtered using the wrong inequality boundary. Fourth, the final parameter was substituted into a later expression with an arithmetic slip.

The repair sequence begins with the copied coefficient because it is the earliest governing state. The discriminant is not an independent error anymore; it must be regenerated from the corrected equation. The candidate parameter set must then be rebuilt because the discriminant relation changed. Only after the candidate set is valid should the boundary filter be reconsidered. The final substitution arithmetic is last because the accepted parameter may differ from the one used originally.

Notice what is preserved: any independent symbolic identity derived from the original givens but not using the corrupted coefficient can remain. Notice what is retired: the old discriminant, all candidate values derived from it, and the old final substitution. The repair is upstream-first because the first copied coefficient controls the entire downstream chain.

Case 2: trigonometric equation with two different kinds of fault

A student solves a trigonometric equation. The identity conversion is correct. The transformed quadratic in sin θ has one arithmetic coefficient error. Later, the student also forgets one valid quadrant when converting a correct sine value back to θ. Both are confirmed faults.

The coefficient error must be repaired first because it controls the candidate sine values. There is no point repairing the quadrant omission using candidate values that may themselves change. After the quadratic is corrected, regenerate all valid sine candidates. Only then repair the angle-generation stage and interval filtering.

This case illustrates an important principle: even when two faults occur in different conceptual layers—algebra and trigonometric solution generation—the earlier mathematical layer has precedence if the later layer consumes its output. Topic labels do not determine order. Dependency does.

Case 3: calculus with correct differentiation but wrong return path

Alicia differentiates correctly and finds the correct stationary x-values. She then evaluates y using f′(x) instead of the original f(x). She also misclassifies one stationary point because she copied the wrong y-coordinate into her sketch. Both faults are confirmed.

The y-evaluation fault has precedence over the classification fault. The correct x-values and derivative state should be preserved. Recompute y from the original function. Then rebuild the stationary point coordinates. Only after the points are correct should the graph classification be repaired.

This is a good example of selective preservation. There is no reason to redo the differentiation. The repair radius begins at the return-to-original-function interface, not at the top of the calculus route.

Case 4: coordinate geometry with shared and independent errors

A coordinate problem has three confirmed faults: Point A was copied with the wrong y-coordinate; the gradient of AB was then calculated from that wrong point; and a completely separate distance CD was calculated incorrectly using correct coordinates.

Repair A first, because the gradient fault is coupled to it. Retire the old gradient and any equation of AB derived from it. The distance CD fault is independent and can be repaired before or after the A→gradient chain depending on mark value and time. It should not be invalidated merely because it appears later on the page.

This case is useful because students often confuse chronological order with dependency. The CD calculation may appear below the corrupted AB work yet remain mathematically independent.

Case 5: two compensating faults in an optimisation question

Tricia differentiates an objective function but drops a factor of 2. Later she accidentally doubles a substituted dimension. The final numerical optimum is close to the correct answer. Both errors are later confirmed.

Repair the derivative coefficient first because it determines the stationary condition. The old stationary candidate and every later quantity depending on it must lose authority. When the second doubling error is later encountered, repair it too. Do not reintroduce the first error merely because the endpoint temporarily becomes less plausible after the derivative is corrected.

This case demonstrates masking-aware sequencing. The correct repair order is determined by dependency, not by which intermediate endpoint looks closest to the answer key.

Case 6: piecewise function with a threshold correction

A parameter k was solved incorrectly as 3 when it should be 1. The student then selected the branch x≥2 and derived a correct local formula within that branch. After correcting k, the relevant condition moves the solution into x<2.

The local formula in the old branch may be algebraically perfect but is now irrelevant. Repair sequencing requires retiring the branch, not merely substituting k=1 into the old formula. Re-evaluate the branch condition, activate the correct branch and rebuild its local states.

This case teaches that repair can invalidate work without making that work intrinsically algebraically wrong. The mathematics may be correct under a branch that no longer applies.

Case 7: exactness and calculator mode

Kai Kai converts an exact surd to 1.41 too early. He later enters a trigonometric calculation in degree mode when the problem is in radians. The final answer is then rounded incorrectly to two decimal places instead of three significant figures. All three faults are confirmed.

Restore the exact or sufficiently precise state first because it is the numerical source. Then repair calculator mode and rerun tool-dependent calculations using the corrected value. Final rounding is last because it is an output formatting operation that depends on the corrected numerical result.

Notice that a calculator-mode fault and a precision fault may coexist but are not always strictly dependent. In this example they both feed the same numerical result, so it is efficient to restore precision and tool state before regenerating the output once.

Case 8: linked parts with one official anchor

Part (a) asks the student to show that a certain expression equals R. The student’s derivation contains a confirmed algebraic error, but the question itself explicitly provides R for use in part (b). Part (b) then contains a separate arithmetic slip.

The failed derivation in part (a) should be repaired for its own marks, but it does not automatically invalidate part (b) if the examination structure authorizes R as a given result. Repair sequencing must distinguish the student’s faulty route from the official problem state. The arithmetic slip in part (b) can be repaired locally from the authoritative R.

This prevents an unnecessary global invalidation caused by confusing “my derivation is wrong” with “the stated anchor is unavailable.”

Case 9: notation collision creates several apparent faults

A student uses a for both a fixed coefficient and a temporary substitution variable. Later lines contain inconsistent values of a, and two numerical results appear wrong. The notation collision is confirmed.

Do not repair the two numerical results first. Restore symbol identity. Rename the temporary variable, reassign the fixed coefficient and trace which lines used which meaning. Some apparent numerical errors may disappear once the notation state is disambiguated.

The governing fault is semantic rather than arithmetic. Repair sequencing must therefore restore meaning before numbers.

Case 10: wrong representation at the start

A word problem was translated into the wrong equation. Downstream algebra contains one additional arithmetic slip and one rounding error. All three are confirmed.

The representation error dominates because it invalidates the route’s foundation. Repairing the arithmetic slip inside the wrong model has no value. Return to the original wording, build the correct equation, then determine whether any generic algebraic manipulation survives. Usually most downstream work must be regenerated.

This case defines a near-global repair radius. It is one of the strongest reasons to restart a region instead of patching locally.

Case 11: proof route with a hidden assumption and a late notation slip

A proof-style solution uses an unjustified assumption x≠0 before dividing by x. Later, the student also writes one symbol incorrectly in the conclusion. Both are confirmed faults.

The hidden assumption has precedence. Repairing the final symbol while leaving the illegal division untouched would produce neat but invalid reasoning. Reopen the case x=0, determine whether it must be treated separately, then rebuild the proof structure. Only after logical validity is restored should the notation slip be corrected.

This case shows that logical authority outranks cosmetic correctness.

Case 12: three independent local faults under time pressure

Suppose three separate questions each contain one confirmed local arithmetic slip. There is no dependency between them. Repair sequencing now becomes an exam-economics problem rather than a mathematical precedence problem.

Repair the fault with the highest expected mark return per unit time first. A one-line sign correction in a five-mark question may outrank a three-minute recomputation in a one-mark subpart. Once dependencies are independent, strategic time allocation becomes legitimate.

Repair precedence classes

A useful training classification is:

The classes are a training heuristic, not a formal mathematical taxonomy. A local error can still deserve urgent repair if it blocks many marks; a foundational fault may be left temporarily if the student strategically moves to another question.

Topological repair order

In a pure dependency graph with no time pressure, the cleanest repair order resembles a topological order: repair ancestors before descendants. Once an ancestor is corrected, regenerate descendants from the corrected state.

Real examinations add constraints: time, marks, uncertainty and fatigue. The ideal topological order may therefore be interrupted strategically, but the mathematical dependency principle remains the baseline.

Repair sequencing and correction confidence

A repair should enter the chain only when the corrected state is itself sufficiently trustworthy. Replacing one confirmed wrong state with an uncertain guess merely changes the shape of uncertainty.

When confidence in a proposed repair is low, keep it provisional or isolate it in a transaction until verified. Multi-fault repair should not become a cascade of speculative edits.

Repair sequencing and proof obligations

When a repair changes an assumption, branch or candidate set, reopen any proof obligations that depended on the old state. A repaired numerical value does not automatically close logical obligations created earlier.

Repair sequencing and error signatures

After repairing an upstream fault, observe which error signatures disappear. If a family of wrong outputs resolves together, the repair probably addressed a shared ancestor. If one signature remains, it may belong to a separate fault family and should enter the next position in the repair queue.

Repair sequencing and contradiction closure

When a contradiction was the signal that exposed several faults, do not declare success merely because the first contradiction disappears. Recompute the repaired chain and test whether the system remains consistent under the original constraints. A second contradiction may have been hidden behind the first.

Repair sequencing and working legibility

Legible working lowers repair cost because dependencies, branches and stale states are easier to see. When correcting under pressure, use visible replacement states, arrows or concise labels rather than dense overwriting. The purpose is not decoration; it is to preserve a recoverable source of truth.

Advanced Repair Architecture

Simple repair sequencing assumes a clean chain: A causes B, B causes C, so fix A first. Real examination working is often less tidy. A result may feed two branches, return through a substitution, merge with another route, enter a calculator, and then become the basis for a linked part. Advanced repair therefore needs a more precise model of how trust moves through the solution.

Repair graphs are not always simple chains

A long Additional Mathematics solution can have forks, joins, repeated reuse and local loops of reasoning.

• Fork: one parameter feeds two different branches.
• Join: two independently derived quantities combine in one final formula.
• Reuse: one intermediate result is used in several non-adjacent parts.
• Return: a transformed variable is converted back to the original variable.
• Cross-check: one route tests a result produced by another.
• Tool handoff: a written state enters calculator work and returns as a numerical output.

Repair sequencing must follow this architecture rather than the physical order of lines on the page.

The repair frontier

The repair frontier is the boundary between states already restored to trust and states still invalid, provisional or unreviewed.

During multi-fault repair, keep the frontier moving outward from trusted sources. Do not leap far downstream and patch isolated outputs while the middle of the chain remains contaminated.

A clean frontier answers two questions at any moment: “What can I currently trust?” and “What is the next state whose authority must be rebuilt?”

Repair barriers

A repair barrier is a checkpoint that must be crossed before downstream work can regain authority. Typical barriers include:

• the corrected governing equation;
• a validated parameter value;
• a restored branch condition;
• a candidate set checked against the original equation;
• a corrected exact state before numerical approximation;
• a synchronized calculator input;
• a reconciled parallel-route output.

Do not propagate trust past a barrier that has not been revalidated.

Rollback repair versus forward repair

There are two broad repair directions.

Rollback repair returns to an earlier trusted state and recomputes forward. Forward repair modifies the current state and attempts to preserve as much downstream work as possible.

Rollback is safer when the fault is structural, high-fan-out or branch-changing. Forward repair is efficient when the fault is local, well-isolated and downstream dependencies are simple.

The last trusted checkpoint

Rollback should not be vague. The student needs an exact restart point: the last state known to be valid and relevant.

A useful rule is: rollback to the latest state that is both mathematically valid and independent of the fault being repaired.

If the last valid line still depends on the corrupted parameter, it is not truly independent and cannot serve as the restart point.

Repair commutativity

Two independent repairs commute when doing A then B produces the same valid state as doing B then A.

For example, a local arithmetic slip in one branch and a final-unit formatting error in another branch may commute. The order can then be chosen by time or mark value.

Coupled repairs do not commute. Correcting a branch condition before correcting the governing parameter may produce different intermediate work from correcting the parameter first. When order changes the valid state space, precedence matters.

Repair batches

Independent faults can be grouped into a repair batch if they do not alter one another’s dependencies. This reduces context switching.

Example: after stabilizing the main parameter chain, the student may batch three independent output repairs—units, rounding and one isolated arithmetic correction—before the final regression check.

Do not batch coupled structural faults merely because they are nearby on the page.

Repair cycles

Sometimes two apparent faults refer back to each other: the student used an inferred graph feature to justify an algebraic branch, then used that branch to justify the same graph feature. Repair cannot simply start “upstream” because the working has become cyclic.

Break the cycle by returning to an external trusted anchor: original equation, original diagram, stated condition, or independently verified result. Rebuild one direction from that anchor. A cycle without an external anchor is a strong restart signal.

Shared-root faults

Several confirmed errors may all be descendants of one deeper fault. Before repairing them individually, ask whether a common ancestor explains all of them.

If yes, repair the shared root and regenerate the subtree. This is often the highest-leverage sequencing move available.

Sibling faults

Two faults may share the same parent but not depend on each other. After repairing the shared parent, they remain separate siblings. The student can then repair them independently.

For example, a corrected parameter may feed one coordinate calculation and one trigonometric evaluation. If both still contain separate local arithmetic errors, neither has precedence after the parameter is stabilized.

Fault descendants that cease to exist

Some confirmed downstream errors disappear structurally after an upstream repair. A candidate value may no longer be generated; an invalid branch may no longer be entered; a final formula may no longer be relevant.

Do not “repair” a state that the corrected solution no longer contains. Retire it. This is a major source of wasted recomputation in students who treat the old route as fixed architecture.

Repair-induced topology changes

A repair can change the shape of the solution graph itself.

• a branch disappears;
• two branches merge;
• a special case must be added;
• a transformed variable is no longer needed;
• a previously independent route becomes dependent on a corrected shared state;
• a shortcut becomes invalid and a longer method is required.

When topology changes, re-map before continuing. Old dependency assumptions may no longer hold.

Repair debt

Repair debt accumulates when known faults are left active while new work is built on top of them. The student may plan to “fix it later,” but every new dependent state increases the eventual correction cost.

High-criticality known faults should therefore be repaired early unless examination strategy requires temporarily abandoning the question. Continuing on top of a known bad state is usually worse than leaving the question and returning later.

Repair saturation

A repair process reaches saturation when each new correction reveals another stale dependency, another overwritten state or another branch inconsistency. At that point the local patching strategy has failed economically.

Repair saturation is a strong signal to restart from a stable checkpoint or abandon the question temporarily. Continuing to patch can consume time while reducing confidence.

The repair cut

A repair cut is a chosen boundary across the dependency graph: everything before the boundary is retained as trusted; everything after it is regenerated.

A good repair cut should be:

• easy to identify on the page;
• based on a trusted state;
• upstream of the confirmed contamination;
• small enough to avoid unnecessary restart;
• large enough to prevent stale-state mixing.

Minimal repair cut versus safe repair cut

The mathematically minimal repair cut may sit immediately before the fault. Under exam pressure, a slightly earlier but clearer cut can be safer. For example, returning to the start of a subpart may cost two extra lines but dramatically reduce confusion.

Efficiency is not always the smallest possible edit. Sometimes a wider clean boundary reduces cognitive overhead enough to be faster overall.

Repair provenance

After several corrections, a student should be able to answer: “Where did this current value come from?”

If the answer is unclear because the value was mentally edited, copied from an old line or partly inherited from a retired branch, the repair lacks provenance. Rewrite the current authoritative state explicitly before reuse.

Repair monotonicity

An ideal repair sequence increases trust monotonically: each step reduces the set of known invalid states and does not reintroduce earlier confirmed errors.

The endpoint may move numerically away from an expected answer during the process, especially when masking breaks. Trust can still be increasing even while apparent correctness decreases. Measure repair progress by validity, not by temporary answer closeness.

Repair invariants

During a complex repair, preserve invariants that remain true throughout the correction. These stable relationships reduce recomputation.

• a geometric incidence relation unaffected by a parameter correction;
• an identity proven independently of the wrong candidate;
• a domain restriction from the original question;
• a derivative rule applied correctly to unaffected terms;
• a coordinate relation that does not use the corrupted point.

Marking such invariants helps the student distinguish what must be rebuilt from what can safely survive.

Repair and candidate sets

Candidate sets deserve special care because a repair can add, remove or reorder candidates. Do not keep filtering an old candidate set after an upstream equation changes. Regenerate the set, then apply constraints again.

Repair and exceptional cases

A generic repair may fail at an exceptional value. If the corrected state changes whether a denominator is zero, whether a coefficient vanishes or whether two roots coincide, reopen the exceptional-case analysis. The correction may move the problem across a mathematical type boundary.

Repair and proof structure

In proof or “show that” work, repairing a premise or assumption can invalidate the logical route even if many equations remain algebraically correct. Restore the premise set first, then ask which implications still follow. Proof repair is therefore often structural rather than numerical.

Repair and answer contracts

After multi-fault repair, re-read the answer contract. A corrected route can still fail by returning the wrong object: decimal instead of exact form, one root instead of all roots, coordinate instead of equation, or local result instead of global conclusion.

Output repair should be last because the contract must be applied to the final authoritative state.

Repair and partial-credit preservation

Clear repair sequencing also protects assessable working. When correcting on paper, preserve visibly correct independent derivations where possible. Do not turn a mostly valid solution into an unreadable page of overwritten states.

A concise correction marker, a clean restarted line and a clear current state make the mathematical story easier to follow for both the student and the marker.

Repair sequencing versus correction aesthetics

A beautifully rewritten page is not automatically a better repair. The goal is valid, traceable mathematics under realistic time constraints. Clean enough to establish authority is sufficient; rewriting every unaffected line wastes exam capacity.

Repair sequencing and cognitive load

Every live old/new version increases working-memory demand. After major repairs, aggressively retire stale states. The fewer competing versions remain visible or mentally active, the lower the chance of accidentally reusing an old value.

Repair sequencing and decision latency

Strong students do not merely repair correctly; they identify the repair order quickly. Training should therefore measure decision latency: how long it takes to identify the governing fault, the last trusted state and the invalidation radius.

Repair sequencing and performance headroom

Complex repair consumes spare cognitive capacity. Students with little performance headroom should prefer clearer, slightly wider repair cuts over delicate minimal edits. Robustness matters more than theoretical elegance late in a paper.

Repair sequencing and fatigue curve

Because fatigue increases stale-state reuse, repair strategy should adapt by paper position. Early in the paper, local surgical repair may be efficient. Late in the paper, restarting a short subpart from a clean trusted state may be safer than maintaining several edited versions.

Repair sequencing and working legibility

Legible working is a repair technology. Branch labels, vertical state progression, clear correction markers and visible source values reduce the cost of determining what survives after a fault.

Repair sequencing and notation integrity

When a symbol’s role changes during repair, rewrite the symbol definition. Do not assume the mind will remember that an old a is retired and a new a has different authority. Symbol ambiguity can recreate the very fault the student is trying to fix.

Repair sequencing and case coverage

If a repair changes a branch condition, re-audit case coverage. A corrected threshold may create a missing case, remove an old case or change boundary ownership. The repair is not complete until the valid possibility space is covered exactly once.

Repair sequencing and step granularity

After a repair, students sometimes over-compress the regenerated work because they feel they have “already done it once.” That can hide a new error. Use ordinary safe step granularity during recomputation, especially near the repaired source and first few dependents.

Repair sequencing and contradiction localization

If a repaired chain still produces an incompatible state, return to Contradiction Localization. Do not assume the repair order was wrong; there may simply be another independent fault that was previously hidden.

Topic-by-Topic Repair Sequencing

Repair order becomes easier when students understand where authority usually sits inside each topic. The exact mathematics varies by syllabus, but the dependency patterns are remarkably stable: foundational representation first, structural transformations second, candidate generation third, validation fourth, and output formatting last.

Quadratic equations

Typical fault stack: wrong coefficient copied from the question, wrong discriminant, wrong root, wrong substitution into a later expression.

Repair order:

1. restore the original quadratic;
2. recompute discriminant or factorisation from the corrected equation;
3. regenerate roots;
4. restore domain or contextual filters;
5. recompute later substitutions;
6. repair final formatting.

A wrong root is often not worth repairing directly because it may simply disappear when the corrected quadratic is solved.

Quadratic inequalities

Typical fault stack: wrong critical values, wrong sign chart, wrong interval union, wrong endpoint inclusion.

Critical values have precedence because the entire interval structure depends on them. Repair roots first, rebuild the sign chart, then reconstruct intervals and finally boundary ownership. Do not patch the final interval while the critical values remain wrong.

Simultaneous equations

Typical faults include a wrongly transcribed equation, incorrect elimination multiplier, arithmetic slip in one variable, and wrong back-substitution.

Repair the equation transcription before elimination. Repair the elimination state before back-substitution. If one variable was actually solved correctly through an independent relation, preserve it only if its derivation does not consume the corrupted equation.

Indices and surds

These topics often create compact-looking chains where a small exponent or sign error propagates widely. Typical fault order is: representation of powers/surds → law application → simplification → rationalisation → final form.

Repair the first illegal law application rather than late numerical simplification. If the symbolic form is corrupted, every later decimal check may be misleading.

Logarithms

Typical faults: domain restriction omitted, log law misapplied, transformed equation wrong, candidate accepted despite invalid domain.

Repair the domain ledger early because it governs admissibility. Then repair the log transformation. Regenerate candidates. Finally filter them against the original logarithmic domain. A candidate that survives the transformed equation but violates the log domain has no authority.

Exponentials

Typical faults: incorrect common-base conversion, wrong logarithm application, calculator mode/input error, premature rounding.

Repair symbolic equivalence before calculator work. Once the exact or structurally correct equation is restored, rerun numerical evaluation using the correct tool state. Round only after the final authoritative quantity is obtained.

Polynomials

Typical faults: wrong coefficient, wrong factor theorem substitution, synthetic-division slip, incorrect quotient, lost factor.

Repair the original polynomial first. If a factor claim depends on substitution, verify that claim next. Re-run division if necessary. Do not repair quotient coefficients independently while the divisor/factor status is still uncertain.

Partial fractions

Typical faults: wrong decomposition form, missing repeated-factor term, wrong coefficient equations, arithmetic slip solving constants.

The decomposition architecture has precedence. If the form is wrong, every coefficient calculation is built on the wrong basis. Repair the form, regenerate coefficient equations, solve constants, then check by recombination.

Binomial expansion

Typical faults: wrong general term, wrong index, wrong coefficient, wrong power tracking, arithmetic slip.

Repair the general-term structure before specific coefficient arithmetic. If the index mapping is wrong, every later term label may shift. Once the term architecture is restored, recompute only the affected coefficients.

Sequences and series

Typical faults: wrong common difference/ratio, wrong nth-term formula, wrong summation formula, wrong substitution for n.

Repair the sequence type and governing parameter first. Then repair the nth-term or sum relation. Final substitution is last. A wrong common ratio can make every later term and sum wrong while preserving superficially neat algebra.

Coordinate geometry

Typical faults: point copied wrongly, gradient sign reversed, line equation wrong, intersection calculated from stale line.

Repair point data first. Regenerate gradient from corrected points. Rebuild the line. Only then solve intersections. Preserve independent geometric constraints that do not consume the faulty coordinates.

Circle geometry and coordinate circles

Typical faults: center/radius extracted incorrectly, tangent gradient wrong, perpendicular relation mishandled, point-of-contact check omitted.

Restore the circle state before tangent work. If center or radius changes, any tangent or distance relation depending on it must be reconsidered. A correct-looking tangent line has no authority if it was derived from the wrong center.

Trigonometric identities

Typical faults: identity misapplied, sign lost, common denominator wrong, cancellation performed across addition.

Repair legality before simplification. If a transformation was not equivalent, later neat expressions cannot rescue it. Rebuild from the last equivalent state and keep branch/domain conditions visible where relevant.

Trigonometric equations

Typical faults: transformed equation wrong, principal value wrong, quadrant mapping wrong, interval filtering wrong.

The transformed equation comes first. Principal values and general solutions depend on it. Quadrant/periodicity generation comes next. Interval filtering and endpoint treatment are last.

Radian measure and arc/sector problems

Typical faults: degrees used instead of radians, radius/diameter confusion, formula factor omitted, calculator mode wrong.

Repair angle unit authority first. Repair geometric quantity identity second. Then recalculate formula outputs. Tool mode should be synchronized before numerical evaluation.

Differentiation

Typical faults: wrong rule selection, wrong chain/product coefficient, sign error, then wrong evaluation.

Repair rule structure before coefficient arithmetic. If the derivative formula changes, retire all stationary points, gradients and classifications derived from the old derivative.

Applications of differentiation

Typical fault stack: wrong objective function, wrong derivative, wrong stationary point, wrong classification, wrong contextual interpretation.

Repair the objective model first. If the model is wrong, even a perfect derivative is irrelevant. Then differentiate, solve, classify and interpret in that order.

Integration

Typical faults: wrong antiderivative rule, missing constant, wrong bounds, wrong substitution into the antiderivative.

Repair the antiderivative before bounds. For indefinite integration, restore the constant of integration before applying conditions. For definite integration, ensure the integrand and bounds are authoritative before numerical evaluation.

Area under a curve

Typical faults: wrong intersection limits, wrong top-minus-bottom relation, wrong integral, wrong sign handling.

Repair geometry/limits before integration. Then repair the integrand relation. Only after the area model is correct should integration arithmetic be recomputed. An integral evaluated perfectly over the wrong interval is still the wrong problem.

Kinematics with calculus

Typical faults: displacement/velocity/acceleration relation confused, derivative/integral wrong, initial condition wrong, sign convention wrong.

Repair the physical quantity mapping and sign convention first. Then repair calculus. Apply initial conditions after the correct functional relation is restored. Context interpretation is last.

Functions and inverse functions

Typical faults: domain/range wrong, inverse procedure wrong, branch restriction omitted, composition evaluated with stale function.

Repair domain and function definition first. Then repair inversion. Restore any branch restriction needed for invertibility. Only then evaluate compositions or graph consequences.

Composite functions

Typical faults: order of composition reversed, inner function copied incorrectly, domain transfer ignored, final substitution wrong.

Repair composition order before algebra. Then restore the inner function state, propagate domain restrictions and recompute outputs. A late numerical repair cannot fix a reversed composition.

Modulus equations and inequalities

Typical faults: branch split wrong, sign condition wrong, candidate duplicated, boundary ownership wrong.

Repair the branch architecture first. Then solve locally inside each valid branch. Validate candidates against branch conditions. Finally reconcile coverage and remove duplicates.

Proof-style and “show that” questions

Typical faults: hidden assumption, circular use of target, invalid equivalence, notation slip, conclusion stronger than proven statement.

Repair logical premises and transformation legality first. Then rebuild the implication chain. Cosmetic notation and final phrasing are last. A proof cannot be repaired from the bottom upward if its logical entitlement is broken near the top.

Mixed-topic questions

Mixed-topic questions are where repair sequencing becomes most valuable because one topic often hands a state to another. Treat each handoff as a dependency boundary.

Example: algebra generates a parameter, trigonometry generates an angle, calculus uses that angle inside an objective. If the parameter is wrong, repair it before touching downstream trigonometry. If only the calculus interpretation is wrong, preserve earlier stages.

Repair sequencing across topic handoffs

At every topic transition, ask three questions:

1. What state is being exported?
2. Is that state confirmed trustworthy?
3. Which later topic stages consume it?

If an exported state is later repaired, invalidate every downstream topic stage that consumed it, but preserve topic-local work that depended on different inputs.

Repair sequencing in graph-based reasoning

Graphs often contain both generated and interpreted information. A wrong equation may produce a wrong graph; a correct graph may then be interpreted incorrectly.

Repair generated structure before interpretation. If the graph itself changes after an equation repair, all readings from the old graph must be reconsidered. If the graph is correct but one interpretation is wrong, preserve the graph.

Repair sequencing with numerical solvers

When numerical solving is permitted, a wrong input equation can produce perfectly consistent numerical output. Repair the input expression before questioning the solver. If the solver input is correct but one numerical root is copied wrongly, preserve the tool result and repair the transcription locally.

Repair sequencing with repeated constants

A shared constant that appears in many formulas behaves like a parameter node. If it changes, recompute every dependent formula once rather than patching outputs one by one. Mark the corrected constant visibly so stale copies are not reused.

Repair sequencing with diagrams

If a diagram label was copied wrongly, repair the diagram state before equations derived from it. If the diagram is not drawn to scale, do not “repair” valid algebra simply because the sketch looks inconsistent. Authority belongs to stated conditions and derived mathematics, not appearance.

Repair sequencing with constraints

A constraint correction can invalidate candidates without altering the equations that generated them. In that case, preserve the generation route but rerun the filtering stage. This is revalidation rather than recomputation.

Repair sequencing with exact versus approximate answers

If an exact answer exists but a decimal was produced too early, restore exact authority before later calculations. If the exact derivation is correct and only final rounding is wrong, repair locally. Precision faults should be classified by where approximation first entered the dependency chain.

Repair sequencing with multiple candidate roots

When a repair changes candidate generation, discard the old candidate list completely and regenerate. When only a domain condition changes, preserve the generated candidates and rerun filtering. The difference saves time and avoids mixing old and new candidate authority.

Repair sequencing with repeated substitution

One wrong value may be substituted into several places. Correct the source value, identify all substitution sites, and rebuild them as one batch. Do not rely on memory to find them later; a missed stale substitution can recreate inconsistency.

Repair sequencing with dimensional or unit errors

Units may be output labels or may change numerical scale. If the error is purely a final label, repair late. If a conversion factor changed the number, repair before any formula that consumed the converted quantity.

Repair sequencing with symmetry

Symmetry can preserve some outputs even after a sign or orientation correction. Do not assume unchanged symmetric outputs need recomputation; revalidate whether the invariant truly protects them. This is another place where preserve-versus-recompute judgment matters.

Repair sequencing with special cases

If a correction reveals that a denominator can be zero, a coefficient can vanish or two roots can coincide, reopen the exceptional-case branch before applying generic formulas. Special-case repairs often have structural precedence over late arithmetic.

Repair sequencing with answer-set union

In case-based problems, repair branches locally first, then recombine the final answer set. Do not reconcile branches while one still contains a confirmed fault. Global union belongs after local validity.

Repair Economics: Marks, Time and Expected Return

Once repair dependencies are understood, examination strategy adds another layer: not every mathematically valid repair is worth doing immediately. Students need a disciplined way to decide whether to repair now, postpone, restart locally, or move to another question.

Repair value

A useful training concept is repair value: how much trustworthy score potential a correction can recover relative to its time and risk cost.

Repair value tends to be high when one upstream fault controls many marks and the corrected route is easy to regenerate. It tends to be low when the fault affects one small output, the search/rebuild cost is high, or the student risks creating more errors under fatigue.

A practical repair-value model

For training, think:

Repair Value ≈ Recoverable Marks × Probability of Clean Repair ÷ Time Cost.

This is not a formal examination formula. It is a decision aid. A two-minute correction that can restore five linked marks deserves attention. A six-minute repair for one uncertain mark may not.

Repair urgency versus repair importance

A fault can look urgent because it sits next to the final answer, yet have low importance. Another fault may look distant but control the entire route.

Repair importance comes from dependency and mark leverage. Repair urgency comes from immediate blocking of progress. Strong students distinguish the two.

Blocking faults

A blocking fault prevents meaningful continuation. Examples include a wrong parameter required for every later part, an unknown branch, or a corrupted equation that all remaining work uses.

Blocking faults usually deserve immediate repair or strategic abandonment of the question. Building further on them creates repair debt.

Non-blocking faults

A non-blocking fault can be postponed because the student can continue valid work elsewhere. Final units, one isolated arithmetic slip, or a local formatting issue may wait until structural work is complete.

Repair queue under marks pressure

When several independent faults remain, order them by expected score return rather than visual order.

1. high-mark, short repair;
2. high-mark, moderate repair;
3. low-mark, short repair;
4. high-risk or low-return repair;

Dependency precedence still overrides this list when faults are coupled.

The abandon-and-return decision

Sometimes the best repair sequence includes leaving the question. If a structural fault is confirmed but clean repair requires concentration that is currently unavailable, mark the last trusted state, move on, and return later with fresh attention.

Abandonment is strategic when it protects the rest of the paper. It is not the same as giving up permanently.

Repair checkpoints before leaving a question

• circle or label the confirmed source fault;
• mark the last trusted state;
• cross out or retire known invalid dependents;
• write one short note describing the next repair action;
• avoid leaving several ambiguous candidate states alive.

These re-entry cues reduce reconstruction cost when the student returns.

Repair risk

Some repairs are more error-prone than others. A simple sign correction is low risk; rebuilding a multi-branch derivation late in the paper is high risk.

When two possible repairs have similar mark value, prefer the one with lower risk and clearer last trusted state.

Repair certainty

A confirmed fault does not guarantee the proposed correction is correct. Before propagating a repair widely, verify the new source state. The larger its fan-out, the stronger this confirmation should be.

Repair amplification

A repair has positive amplification when one source correction fixes many downstream states. It has negative amplification when one uncertain edit forces large recomputation and may introduce new errors.

Prefer high positive-amplification repairs early.

Repair latency

Repair latency is the delay between detecting a fault and correcting it. High-criticality faults should have low latency because every new dependent built in the meantime increases repair debt.

Low-criticality cosmetic faults can tolerate higher latency and may safely be batched near the end.

Repair visibility

A repair should leave a visible authoritative state. Hidden mental corrections are dangerous because the page still presents stale information. When time permits, rewrite the corrected equation or value cleanly rather than relying on memory.

Repair compression

Experienced students may compress obvious recomputation after a repair, but compression should increase only after the first few regenerated states confirm that the chain is stable. Immediately after a structural correction, expose enough working to detect fresh divergence.

Repair escalation

If a local repair reveals new inconsistencies, escalate deliberately:

1. local repair;
2. widen repair radius;
3. return to earlier trusted checkpoint;
4. restart subsection;
5. restart question only if the foundation is uncertain.

Do not jump from one small fault directly to full-question restart unless the evidence justifies it.

Repair de-escalation

The opposite can happen too. An apparently large failure may collapse after one upstream correction. Once the governing fault is repaired, reassess the remaining error list. If downstream symptoms vanish, shrink the repair plan rather than continuing with a prewritten global rebuild.

Repair stopping rule

Stop repairing when:

• all confirmed faults are closed;
• all affected states have been recomputed or revalidated;
• constraints and branches are synchronized;
• the final answer contract is met;
• one regression check passes;
• additional checking has low expected value.

When a repair should not be attempted

Do not begin a complex repair merely because the student feels uncomfortable with the answer. The owner here is sequencing confirmed faults. If the problem is only uncertainty, use verification or diagnostic checking first. Repairing an unconfirmed “maybe-error” can destroy correct work.

The danger of answer-key anchoring

When students know an expected answer, they may sequence repairs toward reproducing that number rather than restoring valid mathematics. This can create compensating edits and symptom patches.

The repair target should be the correct state, not merely the expected endpoint.

The danger of teacher-hint anchoring

A hint such as “check your sign” may identify one fault but not its place in the repair order. If an upstream parameter is also wrong, the sign correction may be secondary. Students should still map dependencies before rebuilding.

The danger of overcorrecting

Students sometimes distrust all subsequent working after finding one error. This converts a local fault into a time crisis. Repair sequencing protects correct work by requiring evidence of dependency before invalidation.

The danger of undercorrecting

The opposite failure is changing one number and leaving formulas that contain the old number untouched. Every repair should be followed by a dependent-state sweep.

Repairing under uncertainty about downstream work

If the student cannot tell whether a later state depends on the correction, mark it UNCERTAIN rather than automatically preserving it. Revalidate uncertain states once the high-priority repair is stable.

Repair ordering with multiple high-criticality faults

If two confirmed faults both have high fan-out, compare dependency. If one is ancestor of the other, repair the ancestor first. If independent, choose the one with larger recoverable mark value, lower repair cost, or clearer source state.

Repair ordering with one structural and one numerical fault

Structural faults usually precede numerical faults because they define what should be calculated. A wrong interval, branch, equation or model should be repaired before arithmetic performed inside that structure.

Repair ordering with two numerical faults

If one wrong number feeds the other, repair upstream. If the two numbers are independent, use exam economics. If they compensate, use masking-aware order and expect temporary endpoint deterioration.

Repair ordering with one logical and one notational fault

Repair logical validity first. A beautifully notated invalid argument remains invalid. Once the reasoning is sound, clean the notation that affects readability or marks.

Repair ordering with one domain fault and one candidate fault

If the candidate was generated correctly but accepted under the wrong domain, repair domain filtering first. If the candidate itself came from an invalid transformation, repair generation first. The exact dependency determines order.

Repair ordering with multiple branches

Repair global branch architecture before local branch arithmetic. Then repair branches independently. Reconcile the union only after every surviving branch is locally valid.

Repair ordering with shared calculator states

If multiple outputs came from one stored calculator value, correct that stored state first and rerun the dependent outputs. Do not correct each displayed answer independently.

Repair ordering after a copied-value cascade

One copied value can propagate across the page. Correct the source occurrence, identify every reuse site, retire stale copies, then recompute the affected chain in one pass.

Repair ordering after a method switch

If the student abandoned Method A and switched to Method B, faults remaining only inside retired Method A usually do not need repair unless they affect marks already earned or contaminated Method B. Repair the live authoritative route first.

Repair ordering after a false parallel merge

If two routes were merged prematurely, first restore route isolation. Identify which states came from which route, then repair local faults inside each. Reconcile again only after both sides reach comparable trustworthy states.

Repair ordering after a contradiction

Once contradiction localization identifies several confirmed causes, order repairs by shared ancestry and fan-out. Do not simply fix the two states that happened to form the visible contradiction if a deeper shared fault created both.

Repair ordering after an error signature

If error-signature analysis identifies a global sign fault plus one independent branch omission, repair the global sign source first because it affects many states. Then repair the local omission.

Repair ordering after masking breaks

When one repair exposes a second fault, preserve the first correction as a new trusted anchor. Add the newly exposed fault to the queue rather than reopening already-validated states without evidence.

Repair economics under severe time pressure

In the final minutes, use an emergency hierarchy:

1. one-line high-mark structural correction;
2. high-confidence correction restoring several linked marks;
3. clear final-answer contract fixes such as units or exactness;
4. short independent arithmetic repairs;
5. avoid deep uncertain rebuilds unless nothing else remains.

Repair economics during review versus examination

During review, the goal is learning, so a full reconstruction can be worthwhile even when it is slow. During the examination, the goal is score under time constraints, so repair sequencing must include opportunity cost.

Students should train both modes: deep post-paper forensic repair and compressed exam-day repair.

Repair evidence log

During review, maintain a short log for complex repairs:

• confirmed faults;
• dependency order;
• repair sequence chosen;
• states preserved;
• states recomputed;
• new faults exposed;
• restart decisions;
• final regression outcome.

The log is not for exam use. It is a training instrument for making repair decisions faster later.

Repair sequencing maturity levels

These levels are training shorthand rather than official assessment categories.

Repair Sequencing Practice System

Repair sequencing should not be learned only after a real exam goes wrong. It can be trained deliberately. The practice system below moves from visible dependency chains to mixed full-paper repairs until ordering decisions become fast enough for examination use.

Drill 1: rank three confirmed faults

Present three faults and ask the student to rank them FIRST, SECOND, THIRD with one-sentence justification. Use simple chains first: wrong equation, wrong root, wrong substitution.

Do not allow “because it comes first on the page” as sufficient justification. The student must name dependency.

Drill 2: preserve or invalidate

After one source repair, present ten later states. The student labels each PRESERVE, RECOMPUTE, REVALIDATE or RETIRE.

Score false invalidation as well as missed invalidation. Over-repair and under-repair are both performance defects.

Drill 3: find the last trusted state

Show a solution with one confirmed structural fault halfway down. Ask the student to point to the exact line from which clean recomputation should restart.

Then compare with restarting from the top and measure the saved work.

Drill 4: branch retirement

Correct a threshold that moves the solution into a different branch. Ask the student to identify every branch-local state that must be retired and every global state that survives.

Drill 5: masking break

Give two compensating faults and ask the student to repair the upstream one first. When the endpoint worsens, observe whether the student preserves the confirmed repair or reflexively reverses it.

Drill 6: independent-fault batching

Give four confirmed faults, two coupled and two independent. The student must repair the coupled pair in dependency order, then batch the independent faults efficiently.

Drill 7: section restart decision

Provide several repair scenarios with estimated local-repair times and restart times. Ask the student to choose the cheaper reliable option, then justify the boundary selected.

Drill 8: linked-part anchor

Make an early anchor wrong and show three later parts, only two of which actually use it. Ask the student to invalidate only the affected parts.

Drill 9: official given versus student derivation

Use a “show that” question where the student’s derivation is faulty but the stated result is available for the next part. Ask what can be preserved and what must be repaired separately.

Drill 10: calculator dependency map

Identify which outputs came from a shared stored calculator value. Correct the stored value and regenerate only tool-dependent outputs.

Drill 11: notation authority

Introduce a notation collision that creates several apparent numerical faults. Ask the student to repair symbol meaning first, then reassess which numerical faults remain real.

Drill 12: candidate regeneration versus refiltering

Use two variants. In Variant A, the governing equation changes; the student must regenerate candidates. In Variant B, only the domain changes; the student preserves candidates and refilters them.

This drill builds a crucial distinction between recomputation and revalidation.

Drill 13: proof repair

Provide a proof with one illegal assumption and one late notation mistake. Ask the student to explain why logical validity must be repaired before notation.

Drill 14: repair frontier tracking

During a long repair, pause every few lines and ask the student to mark the current frontier between trusted and untrusted states. This prevents premature trust propagation.

Drill 15: repair saturation

Give a deliberately tangled solution where every local patch reveals another stale state. Ask the student to decide the moment when section restart becomes cheaper than continued repair.

Drill 16: repair under a two-minute budget

Give three independent confirmed faults worth different marks. The student has two minutes. Score the order chosen and marks recovered, not just mathematical correctness.

Drill 17: late-paper fatigue simulation

Place a repair task at the end of a timed mixed set. Require explicit state retirement and one regression check. The goal is to see whether repair discipline survives fatigue.

Drill 18: interruption and return

Interrupt a repair after the first correction. Resume later with only the student’s page as evidence. Can the student reconstruct fault list, completed repairs, invalidated dependents and current authoritative state?

Drill 19: cross-topic repair

Use an algebra → trigonometry → calculus chain. Corrupt the algebraic export and one independent calculus arithmetic line. Ask the student to repair the algebraic source, regenerate dependent trigonometry/calculus states, then fix the independent calculus slip.

Drill 20: full-paper repair audit

After a timed paper, review every correction the student made. For each one record: source fault, chosen repair order, invalidation radius, work preserved, duplicate work, newly exposed faults and final outcome.

Tutor protocol: do not repair for the student too early

When teaching repair sequencing, a tutor should resist immediately pointing to the best repair order. First ask the learner to state:

1. Which faults are definitely confirmed?
2. Which one is upstream of another?
3. What work depends on each?
4. What would become stale after the first repair?
5. What can survive unchanged?

The learner needs to practise the sequencing decision itself, not merely observe a correct repair.

Tutor protocol: separate diagnosis from sequencing

Early training should sometimes give the student the fault list explicitly. This removes diagnostic difficulty and isolates the repair-order skill. Later, diagnosis and sequencing can be recombined.

Tutor protocol: ask what survives

Tutors often ask “What needs to be redone?” Add a second question: “What definitely does not need to be redone?”

This trains preservation discipline and reduces the learner’s tendency to restart globally.

Tutor protocol: expose masking safely

Use deliberate compensating errors to show that a correct endpoint can deteriorate after a valid first repair. The tutor should make explicit that temporary endpoint worsening is compatible with increasing route validity.

Tutor protocol: fade the repair labels

At first, use explicit labels such as FAULT A, FAULT B, DEPENDENT, INDEPENDENT, CURRENT and RETIRED. Later, fade the labels until the student can manage repair authority with ordinary examination working.

Tutor protocol: measure duplicate work

A correct repair can still be inefficient. Track how many lines were recomputed unnecessarily because the order was poor. Efficiency feedback should be evidence-based rather than aesthetic.

Tutor protocol: train restart judgment

Students need examples where restart is the correct decision. Otherwise “preserve correct work” can become another rigid rule. Include heavily contaminated solutions where a clean section restart is faster and safer than delicate local repair.

Student self-talk for repair sequencing

Useful internal prompts are short:

• “Confirmed or guessed?”
• “What depends on this?”
• “Which error is upstream?”
• “What stays valid?”
• “Where is the last trusted state?”
• “Did this correction change the branch?”
• “Did the worse answer expose another fault?”
• “Am I patching a symptom?”
• “Is restart cheaper now?”

Repair sequencing review sheet

Repair sequencing scoring rubric

A two-week intensive repair programme

For students who already know the mathematics but lose marks during correction, a short intensive cycle can isolate repair control.

1. Days 1–2: simple dependency chains and upstream-first repair.
2. Days 3–4: independent versus coupled faults.
3. Days 5–6: invalidation radius and stale-state retirement.
4. Day 7: mixed review.
5. Days 8–9: masking-aware repair and worse-after-fix scenarios.
6. Days 10–11: branch-changing and precision/tool-state repair.
7. Day 12: restart economics.
8. Day 13: timed linked problem set.
9. Day 14: full-paper audit and compressed exam-day triggers.

A twelve-week repair-development programme

1. Week 1: dependency maps.
2. Week 2: upstream versus downstream faults.
3. Week 3: independent branch preservation.
4. Week 4: recompute versus revalidate.
5. Week 5: branch-changing corrections.
6. Week 6: precision and calculator-state repairs.
7. Week 7: masking and compensation.
8. Week 8: repair cuts and section restart.
9. Week 9: linked-question repair.
10. Week 10: time/mark repair economics.
11. Week 11: fatigue and interruption.
12. Week 12: full-paper reliability testing.

Practice progression: visible to invisible support

Start with faults highlighted in different colours and arrows showing dependency. Next remove arrows but keep fault labels. Then remove labels and give only a confirmed fault list. Finally, use ordinary student scripts where the learner must diagnose and sequence repairs independently.

Practice progression: untimed to pressured

Do not begin with late-paper pressure. First make the sequencing logic accurate. Then add time limits, mixed topics, interruptions and fatigue. Speed should compress a reliable process rather than replace it.

Practice progression: one fault family to mixed faults

Early tasks can use one upstream error plus one downstream symptom. Later tasks should combine structural, arithmetic, branch, precision and masking faults so students must classify relationships rather than apply one memorized pattern.

Practice progression: artificial scripts to authentic scripts

Injected-error worksheets are useful because the repair architecture can be controlled. Authentic past-paper scripts are essential because real errors are messier, handwriting is less clean and dependency is not pre-labelled.

What a strong repair explanation sounds like

“I will repair the parameter first because the branch and two later substitutions depend on it. The coordinate branch is independent, so I will keep it. After changing the parameter I need to recheck the branch threshold before recomputing the substitutions. The final rounding error can wait until the end.”

This explanation is stronger than “I’ll fix this one first because it looks most wrong.” It reveals dependency reasoning.

What a weak repair explanation sounds like

“I’ll redo everything to be safe.” Sometimes a full restart is justified, but without evidence of contamination it may simply reflect poor state control. Safety is not the same as maximal rewriting.

Repair sequencing for high-performing students

Strong students often make fewer errors but can lose disproportionate time when one appears because they are unused to repair. Their training should include complex multi-fault scripts and deliberate masking so correction becomes a practiced skill rather than an emergency improvisation.

Repair sequencing for developing students

Developing students may need simpler visual dependency maps and stronger tutor scaffolds. The priority is not advanced repair economics at first; it is learning that one wrong upstream state can create many downstream symptoms and that correct independent work should not automatically be discarded.

Repair sequencing for students who erase everything

Some students respond to uncertainty by erasing or rewriting the whole page. Train them to mark the last trusted state and draw a repair cut instead. The goal is to make preservation visible and legitimate.

Repair sequencing for students who never restart

Other students patch endlessly. Train restart thresholds explicitly. Give them contaminated examples where every local patch creates another stale dependency. They need to experience that a clean section restart can be the efficient option.

Repair sequencing for students who chase the answer key

Hide the answer during repair training. Require state-level justification before revealing the endpoint. This reduces the tendency to manipulate later steps until the expected number appears.

Repair sequencing for students who make mental corrections

Require visible write-through: when a high-criticality state changes, write the new state and mark the old one retired. This builds synchronization and prevents the mind from continuing with a different version from the page.

Repair Sequencing Reference Manual

This reference section is designed for difficult edge cases: the moments when “fix the upstream error first” is directionally correct but not detailed enough. Each scenario focuses on a specific sequencing decision and explains what should receive authority.

Scenario 1: two faults share one parent state

Suppose Fault A is a wrong coordinate and Fault B is a wrong gradient, but both were caused by one earlier copied point. The copied point has precedence. Repairing A and B independently would duplicate work because both should be regenerated from the corrected parent.

Rule: when several faults share one confirmed wrong ancestor, repair the shared ancestor before the siblings.

Scenario 2: two faults are both upstream but independent

Suppose one wrong coefficient controls Branch A while a separate wrong parameter controls Branch B. Neither depends on the other. There is no mathematical precedence between them. Use mark return, repair time and ease of re-entry to choose which to repair first.

Scenario 3: an early error has tiny fan-out, a later error has huge fan-out

Chronology alone does not decide priority. If the early error affects one disposable local line while the later error becomes a shared input for five subsequent parts, the later high-fan-out error may deserve repair first—provided the two faults are independent.

Rule: precedence applies within dependency relationships; otherwise criticality and repair value can dominate.

Scenario 4: a late correction changes a global condition

A condition discovered late may invalidate earlier-looking work if it actually has global scope. For example, learning that a parameter must be positive may invalidate a candidate used several lines earlier.

Repair scope follows mathematical authority, not discovery time. Once a global condition is established, revalidate every state that should have obeyed it.

Scenario 5: one confirmed error is only cosmetic

A notation typo that does not change meaning may be confirmed as an error but should not outrank a structural fault. Repair it after state authority is restored unless the notation ambiguity itself threatens later interpretation.

Scenario 6: a cosmetic error becomes semantic

If the notation slip changes what a symbol refers to, it is no longer cosmetic. It becomes a state-definition fault and can deserve early repair. The same visible typo can therefore have different repair priority depending on whether meaning changed.

Scenario 7: one fault is mathematically wrong but irrelevant

A retired route may contain a confirmed error. If that route contributes nothing to the submitted or surviving solution and does not contaminate another state, repairing it may have zero exam value.

During learning review, repair it if the misconception matters. During the examination, prioritize the live route.

Scenario 8: the wrong route contains useful partial work

An abandoned route may still contain one independently valid lemma, identity or coordinate. Do not automatically discard it. Verify whether that state was derived before the route-specific fault and can be exported cleanly.

Scenario 9: one repair changes only interpretation

Suppose a derivative and stationary point are correct, but the student called the point a maximum instead of a minimum. Repair interpretation locally. Do not rebuild the derivative chain.

Scenario 10: one repair changes the mathematical object

If the student thought the target was a gradient but the question asked for an equation of a tangent, the representation of the task is incomplete. The gradient may survive as an intermediate, but downstream answer construction must be rebuilt around the actual object requested.

Scenario 11: an answer is numerically right but the state is wrong

Do not preserve the endpoint merely because it matches. If the route contains confirmed compensating faults, repair upstream states and regenerate the answer. Numerical coincidence has no precedence over validated state.

Scenario 12: a repair removes the need for another method

A corrected identity may make a previously necessary numerical route redundant. Retire the redundant route rather than repairing every fault inside it. Repair sequencing includes deciding what no longer needs repair.

Scenario 13: a repair creates a new exceptional case

Correcting a coefficient may make a denominator zero or make a quadratic degenerate into a linear equation. Reopen type classification before applying the old generic route.

Rule: if the repair changes mathematical type, repair the classification before continuing execution.

Scenario 14: a repair removes an exceptional case

The opposite can occur. A previously treated special branch may disappear after the governing parameter is corrected. Retire the branch and any branch-local faults rather than repairing them unnecessarily.

Scenario 15: two candidate values swap authority

A corrected domain may reject the candidate previously accepted and admit another previously rejected candidate. Refilter the entire candidate set. Do not simply “fix” the old final candidate.

Scenario 16: one repair changes only a final unit conversion

If the mathematics is in correct base units and only the requested output unit was mishandled, repair locally at the conversion layer. Preserve the mathematical quantity.

Scenario 17: the unit error entered before the formula

If centimetres were entered into a formula expecting metres without conversion, the numerical state is corrupted upstream. Repair the input unit and recompute every dependent quantity. Same topic, different sequencing.

Scenario 18: a calculator result was copied incorrectly

If the calculator computation is correct and only the page transcription is wrong, preserve the tool result, repair the copy and recompute page dependents. If the calculator input itself was wrong, the tool result has no authority and must be regenerated.

Scenario 19: a graph sketch is wrong but algebra is right

Repair the sketch or interpretation locally if it did not feed the algebra. If later route choices were based on the sketch, those choices become dependents and need revalidation.

Scenario 20: algebra is wrong but the graph was independently correct

Preserve the independent graph evidence. It can become a regression check after algebra is repaired. This is one reason true route isolation improves repair efficiency.

Scenario 21: one error exists in a reusable formula

A wrong formula copied repeatedly has extreme fan-out. Repair the formula source first, then locate every use. Treat downstream wrong values as stale dependents rather than separate arithmetic faults unless evidence shows additional local errors.

Scenario 22: several local errors happen after one correct source

If the shared source is verified and each downstream branch has its own arithmetic mistake, the faults are siblings. Repair can be batched branch by branch without touching the source.

Scenario 23: an upstream fault and downstream independent fault coexist

Repair the upstream chain first if it blocks major progress. The independent fault can wait, but it should remain on the repair queue so it is not forgotten after the main route is restored.

Scenario 24: a repair changes the number of solutions

If a corrected discriminant, domain or trigonometric equation changes candidate count, retire the old candidate structure completely. Regenerate before filtering or interpretation.

Scenario 25: a repair changes only one candidate value

If candidate architecture remains valid and one local arithmetic step changed only one root, recompute that branch and then rerun duplicate/domain checks. Do not unnecessarily regenerate unrelated candidates.

Scenario 26: one confirmed fault sits inside an uncommitted transaction

Roll back the transaction locally. The main trusted solution does not need invalidation if no provisional state leaked out. This is a major advantage of keeping speculative routes isolated.

Scenario 27: the provisional fault already leaked

If an uncommitted value was already reused by the main solution, repair scope expands to every leaked dependent. First restore the trusted base, then purge contaminated imports.

Scenario 28: one branch is correct only because of a stale assumption

Once the assumption is retired, the branch loses authority even if its numerical outputs remain plausible. Repair the assumption/branch relation before local arithmetic.

Scenario 29: one fault appears after a clean correction

Do not assume the correction created the new fault. It may simply have exposed it. Add the new confirmed fault to the queue and determine whether it is independent or was previously masked.

Scenario 30: a repaired answer now conflicts with the answer contract

Perhaps the value is now correct but not exact, lacks units, misses another root or answers the wrong variable. Output-contract repair belongs after the mathematics is stable. Do not alter the route merely to fix formatting.

Scenario 31: the repair requires changing method

If the corrected state destroys the old method’s assumptions, switch route from the last trusted state. Do not force the old method to survive simply because much work has already been invested.

Scenario 32: sunk-cost repair

Students may keep patching a failing route because they have already spent five minutes on it. Repair sequencing should ignore sunk cost. The decision is based on future repair cost and recoverable marks, not past effort.

Scenario 33: a short clean restart is safer than a minimal patch

If the mathematically minimal edit requires remembering several stale/correct distinctions, restart the short subpart from a clean boundary. Robustness can be more efficient than surgical precision.

Scenario 34: full restart is unnecessary

If the original representation, governing equation and branch structure are all trusted, a late local fault rarely justifies rebuilding everything. Use the last trusted checkpoint and preserve earlier work.

Scenario 35: two errors cancel exactly

Repair the upstream fault first, invalidate compensated outputs, then repair the second. The temporarily wrong endpoint is expected. Do not use endpoint closeness as the sequencing criterion.

Scenario 36: two errors partially cancel

The endpoint is near-correct. Treat near-correctness as weak evidence. Repair by dependency, then check whether residual error disappears or reveals an additional independent fault.

Scenario 37: one repair fixes three apparent errors

Remove those three symptoms from the queue unless they remain independently wrong after recomputation. Do not repair ghosts left over from the old state.

Scenario 38: one repair creates three new required states

A branch correction may open a previously omitted case. Add the new branch work to the repair plan. Repair sequencing is dynamic; the task graph can expand as well as contract.

Scenario 39: the student cannot identify dependency

Do not guess the repair order. Reconstruct the mathematical relationship: which equation generated which value, which branch supplied which condition, and which output reused which state. If dependency remains opaque, a wider clean restart may be safer.

Scenario 40: every line seems dependent on everything

This often indicates illegible working rather than truly global dependency. Identify the original givens and the last unquestionably valid transformation. Use that as a repair cut. In post-paper review, improve working legibility so future repair radius can be mapped more precisely.

Expanded FAQ: Why not just redo the whole question?

Because most long solutions contain valid work worth preserving. Full restart consumes time, creates new error opportunities and may erase useful partial-credit evidence. It is appropriate when the foundation or state history is too contaminated, not as the default response to every mistake.

Expanded FAQ: Why not always fix the earliest error chronologically?

Because chronology is not dependency. An early isolated arithmetic slip may be irrelevant to the live route, while a later branch error may control many marks. The rule is earliest governing fault within the relevant dependency structure.

Expanded FAQ: Can a later fault ever be repaired first?

Yes, when it is independent and offers better immediate mark return or lower repair cost. Mathematical precedence constrains coupled faults; strategic order can choose among independent faults.

Expanded FAQ: What if I am not sure whether two faults are independent?

Trace their immediate inputs. If they share a suspect ancestor or one consumes the other’s output, treat them as coupled until proven otherwise. If their derivations separate cleanly from the trusted base, they can be repaired independently.

Expanded FAQ: Does every dependent state need full recomputation?

No. Some need only revalidation. If the algebraic form is unchanged but a domain condition changed, the derivation may survive while admissibility must be checked again. Recompute when the actual input state changed.

Expanded FAQ: What if the correct repair is ugly?

Validity outranks elegance. A corrected route may become longer or less neat. Do not preserve an invalid shortcut merely because it produced prettier working.

Expanded FAQ: What if the answer key suggests my old answer was correct?

If a confirmed fault exists, keep the valid correction and investigate masking or an additional error. Matching the answer key does not turn a known invalid step into a valid one.

Expanded FAQ: How do I know a repair is confirmed?

Use an independent check appropriate to the state: substitution, identity, domain condition, derivative check, geometric relation, calculator re-entry or comparison with the original problem. High-fan-out repaired states deserve stronger confirmation.

Expanded FAQ: Should I cross out old work?

Retire it clearly enough that it cannot be mistaken for current authority. A neat strike-through, label or clean restart line is often better than erasing all evidence. The page should show which state is current.

Expanded FAQ: Can I use the corrected answer from one branch in another?

Only if the state is genuinely global or exported through a valid bridge. Branch-local corrections should not silently become global assumptions.

Expanded FAQ: What if one repair changes my method?

Reassess method choice. A method is not entitled to survive a correction. Start the new method from a trusted shared state and retire stale outputs from the old route.

Expanded FAQ: What if I discover another error after finishing the repair?

Reopen the fault list. Determine whether the new error is independent, a remaining descendant, or previously masked. Then sequence it using the same rules rather than assuming the entire repair failed.

Expanded FAQ: How many regression checks are enough?

Enough to re-establish trust at the critical points: corrected source, major branch/constraint state, and final answer contract. Rechecking every arithmetic line is usually unnecessary if dependencies are clear and high-value states pass.

Expanded FAQ: Can repair sequencing itself become too slow?

Yes. That is why training should compress it. In the exam, the internal questions should become rapid: upstream? shared? branch-changing? high fan-out? masking? restart cheaper? The full framework belongs in training; exam use is a compact version.

Expanded FAQ: Is this only for strong students?

No. Developing students often benefit even more from learning not to restart globally. The sophistication of the dependency map can be scaled to the learner. The core idea—fix the cause before the symptoms and preserve independent correct work—is broadly useful.

Expanded FAQ: What is the single most important repair habit?

Before changing a downstream line, ask whether any confirmed upstream state will force you to recompute it again. That one question prevents a large amount of duplicate work.

Expanded FAQ: What is the single most dangerous repair habit?

Changing the final answer to match expectation while leaving the source mathematics untouched. That is symptom patching, not repair.

Expanded FAQ: What is the single most important masking habit?

If a verified correction makes the answer worse, keep the correction and search for the second error. Do not restore a known fault merely to regain a familiar endpoint.

Expanded FAQ: What is the single most important restart habit?

Restart from a clear trusted boundary, not from an emotional impulse. A good restart has a reason: contamination, lost authority, branch confusion or lower cost than continued patching.

Compact glossary

The 30-second repair router

1. Confirmed faults only.
2. Which one is ancestor of another?
3. Which one has the biggest fan-out?
4. Which branches are independent?
5. Will fixing one expose another?
6. Where is the last trusted state?
7. What becomes stale?
8. Recompute, revalidate, preserve or retire?
9. Is restart now cheaper?
10. Regression-test once the chain is rebuilt.

The 10-second emergency router

Upstream first. Keep independent work. Kill stale dependents. If the answer gets worse, check masking. If patching explodes, restart from a trusted boundary.

Final mastery standard

A student has mastered repair sequencing when a multi-error solution no longer produces panic or indiscriminate rewriting. The student can identify confirmed faults, see who depends on whom, restore the governing state, preserve independent mathematics, retire stale versions, handle masking without reversing valid corrections, and choose a clean restart when local repair ceases to be economical.

The visible page may still contain crossed-out work. Mastery is not a pristine page. Mastery is a trustworthy mathematical state recovered with controlled cost.

Final operating principle

Repair the mathematics in the order that authority flows, not the order that mistakes become emotionally noticeable.

Final Advanced Case Layer: Repair Sequencing Under Complex Dependency

The final cases focus on compressed, examination-like situations in which several faults coexist and the student must decide quickly what deserves authority. Each case is deliberately small enough to recognize under pressure but rich enough to test dependency reasoning.

Case A: wrong denominator, correct numerator, wrong final decimal

A fraction is built from a correct numerator and a denominator containing a confirmed sign error. The student then rounds the resulting decimal incorrectly. Repair the denominator first because it changes the actual value. Recompute the quotient. Final rounding is last. There is no value in correcting the old decimal because it belongs to a retired numerical state.

Case B: correct factorisation, wrong domain, wrong final root list

The factorisation is verified. The domain restriction was copied wrongly, causing one root to be rejected incorrectly. Preserve factorisation and candidate generation. Repair the domain state, then refilter the candidate list. This is revalidation, not full recomputation.

Case C: wrong graph scale, correct algebraic roots

The algebraic roots are independently verified. The graph was drawn with an incorrect vertical scale and a later interpretation based on the sketch is wrong. Preserve the roots. Repair the graph representation and re-evaluate only conclusions that depended on visual geometry.

Case D: wrong derivative term, correct root by coincidence

A derivative contains one confirmed wrong term, yet one stationary x-value happens to match the correct answer. Do not preserve that candidate merely because it is lucky. Repair the derivative, regenerate stationary candidates and then determine whether the same x-value survives legitimately.

Case E: wrong branch label, correct branch mathematics

The mathematics written under “x≥0” actually belongs to “x<0,” and the formulas themselves are correct for that negative branch. Repair branch identity first. Reassign the local work only if its derivation genuinely matches the correct condition. Then audit coverage and boundary ownership.

Case F: correct calculator answer, wrong stored variable name

The numerical result is correct, but the calculator variable label on the page is wrong. If later work uses the numeric state and not the semantic label, repair notation locally. If the wrong label causes later substitution into the wrong formula, the notation fault becomes upstream and its invalidation radius expands.

Case G: wrong angle unit, independent exact identity

The exact trigonometric identity is correct. Numerical evaluation used degrees instead of radians. Preserve the identity. Repair calculator mode and regenerate only the numerical stage. This is a classic example of a tool-state fault with limited symbolic radius.

Case H: wrong intersection point, correct line equations

Both line equations are verified. The simultaneous solving contains an arithmetic slip. Preserve both lines. Recompute the intersection only. Do not rebuild gradient or equation derivations that are already trusted.

Case I: wrong line equation caused by wrong gradient

The point is correct, the gradient is confirmed wrong, and the line equation is therefore also wrong. Repair gradient first, then regenerate the line. The line fault is a descendant, not an independent item.

Case J: wrong gradient caused by reversed coordinate order

If both numerator and denominator coordinate differences were reversed, the gradient may actually remain correct. Do not “repair” the gradient without checking. The visible coordinate-order issue may be harmless because the two reversals compensate. Repair semantic clarity, then test whether the numerical gradient needs change.

Case K: wrong constant of integration, correct definite difference

In a definite difference, an omitted constant may cancel and leave the final value correct. If later work requires the full antiderivative, the constant matters. Repair sequencing should consider future dependencies, not only the current endpoint.

Case L: wrong condition in one linked part, official next-part value supplied

Repair the faulty part for its own logic and marks. If the next part explicitly supplies the correct value, use that official state as the downstream anchor. Do not contaminate the later part with the student’s failed derivation.

Case M: wrong sign chart, correct interval by luck

A sign chart contains two wrong signs that happen to produce the correct final interval. Repair the chart from the critical values rather than preserving the lucky interval. Then refilter boundaries and confirm the final set.

Case N: wrong parameter but invariant ratio survives

A parameter is wrong, but a ratio derived from two quantities containing the same parameter cancels and remains correct. Repair the parameter and revalidate the ratio rather than automatically recomputing it. If the ratio is genuinely invariant, preserve it.

Case O: one corrected input changes all calculator table values

A table of numerical outputs was generated from one wrong stored constant. Correct the constant once, regenerate the table as a batch, and retire the entire old table. Do not edit cells individually.

Case P: wrong table entry, correct model

The model is verified and only one table entry was transcribed wrongly. Repair locally. A global recomputation would be unnecessary unless the entry fed later calculations.

Case Q: wrong candidate generated by squaring

The transformation introduced an extraneous candidate. The candidate itself is not an arithmetic fault; it is a validation-state issue. Preserve the transformed equation if it was used legitimately for candidate generation, then validate every candidate against the original equation.

Case R: illegal division lost a valid special case

Dividing by an expression that can be zero removed a possible solution. Repair transformation legality before final candidate filtering. Reopen the zero case separately, then combine it with the generic solution set.

Case S: one branch uses a stale parameter after correction

The main page shows the corrected parameter, but one side branch still uses the old value. Repair the stale branch by resynchronizing its input. Preserve branches that already use the current parameter.

Case T: two independent correct routes, wrong reconciliation

Route A and Route B are each correct, but the student compares unlike outputs—exact versus rounded, local versus global, or transformed variable versus original variable—and concludes disagreement. Repair the reconciliation interface, not the routes.

Case U: one route is wrong, the shared base is correct

Preserve the shared trusted base and the correct route. Repair or retire only the faulty route. Do not invalidate shared input merely because one descendant failed.

Case V: shared base is wrong, both routes are contaminated

Agreement between the routes is irrelevant because both inherit the same bad source. Repair the shared base first, retire both route-local outputs, then rerun each route as needed.

Case W: corrected state changes answer precision but not value

The numerical value is effectively unchanged, but the official answer requires exact form. Preserve the mathematical magnitude, restore exact representation and update only dependent work that needs exact authority.

Case X: wrong exact form but correct decimal

A decimal matches because of rounding, but the symbolic exact form is wrong. Repair the exact state first. Any later exact manipulation must be regenerated; purely approximate downstream checks may only need revalidation.

Case Y: one arithmetic repair changes nothing downstream

A wrong intermediate was written but never reused; the student independently recalculated the correct value later. Repair the local record for clarity, but there may be no downstream invalidation radius.

Case Z: the written state is wrong but the calculator state was right

If later numerical work came directly from the correct calculator state, the page error may not have propagated. Repair the written source, then audit provenance before deciding whether later values need recomputation.

Case AA: the page state was right but the calculator state was wrong

Preserve symbolic work. Correct the calculator input/mode and regenerate only tool outputs. This is why mind-page-tool synchronization matters during repair.

Case AB: a repair changes a coefficient but not the qualitative graph

The graph may preserve root count or monotonic shape even though exact locations change. Preserve qualitative invariants after revalidation, but recompute numerical coordinates and any location-dependent conclusions.

Case AC: a repair changes qualitative graph structure

If root count, turning points or asymptotic behaviour changes, old graph interpretation loses authority broadly. Widen the repair radius and rebuild qualitative conclusions from the corrected equation.

Case AD: one repair changes a proof from generic to case-based

A corrected condition reveals an exceptional value. Retire the single generic proof route, split into cases and close each obligation separately. The repair changes architecture, not merely one line.

Case AE: one repair collapses several cases into one

If the corrected condition makes multiple branches equivalent, merge only after confirming that boundary and domain conditions also align. Then retire duplicate branch work.

Case AF: the repair order affects page clarity

Two independent repairs are mathematically commutative, but one is located near the current working and the other requires returning several pages. Under time pressure, repair the nearby one first if mark value is comparable, then batch the distant repair on re-entry.

Case AG: one fault is worth fixing only during review

A subtle notation inconsistency may have negligible exam-mark impact but reveal a conceptual weakness. During the exam, prioritize live scoring faults. During review, repair and train the notation issue because future problems may make it consequential.

Case AH: one fault is easy to repair but high risk to propagate

A one-symbol parameter correction looks trivial but feeds many later equations. Because propagation is large, verify the corrected parameter strongly before recomputing. Cheap source repair does not mean cheap downstream consequences.

Case AI: one repair has uncertain scope

Mark downstream states as UNCERTAIN until their dependency is resolved. Do not automatically preserve or destroy them. Once the source is stable, inspect each uncertain state’s provenance and classify it.

Case AJ: one repair changes the interpretation of earlier evidence

A corrected graph or parameter may show that an earlier “check” was actually testing the wrong regime. Reassess the evidential value of that check rather than treating every previously passed checkpoint as permanently authoritative.

Case AK: the repair itself introduces a new typo

This is common under pressure. After rewriting a corrected source, run one immediate local verification before propagating it. Otherwise the repair sequence may amplify a fresh transcription error.

Case AL: two independent faults compete for the last minute

Choose by expected mark return and repair confidence. A certain one-mark unit correction can outrank an uncertain three-mark rebuild if the latter cannot be completed reliably. Strategy begins only after mathematical independence is established.

Case AM: a high-mark repair is too uncertain

Do not sink the remaining paper into an uncertain rebuild. Mark the last trusted state, preserve partial work and move to cleaner marks. Repair sequencing includes knowing when not to proceed.

Case AN: a low-mark repair unlocks a later high-mark part

Its effective repair value is high because it is a gateway. Mark value should be counted across downstream dependence, not only at the local line.

Case AO: correct work is visually below wrong work

Preserve it if independent. Physical location on the page does not create dependency. This is one of the most important habits in long written solutions.

Case AP: wrong work is visually above correct work

Do not assume everything below is invalid. Trace actual inputs. Later work may have restarted from the original givens or an independent branch.

Case AQ: repair after teacher annotation

During review, teacher marks may identify several errors but not dependency. The student should still reconstruct which annotation points to source and which points to consequence. Repair in mathematical order, not annotation order.

Case AR: repair after automated checking

An automated system may flag wrong final outputs without revealing shared ancestry. Use the flagged outputs as evidence, then map dependencies before repairing. Multiple red marks do not necessarily mean multiple independent faults.

Case AS: repair after partial credit

Partial credit may reveal that early method and setup were accepted while later execution failed. Treat that as evidence that the last trusted state lies later than the start. Preserve accepted structure and localize repair.

Case AT: repair after zero credit

Zero credit does not automatically imply the entire route is unusable, but it lowers confidence. During review, inspect the representation and method choice before investing in local arithmetic repair.

Case AU: repair when several errors come from one misconception

During post-exam learning, repair the conceptual model, not only the script. The on-page sequence may be fixed quickly, but recurrence will continue unless the underlying misconception is retrained.

Case AV: repair when several errors come from fatigue

If the conceptual route is sound but late-paper signs, copies and calculator entries degrade, the script repair should be followed by fatigue-resistant execution training rather than reteaching the entire topic.

Case AW: repair when the fault is method selection

If the chosen route is fundamentally inefficient but still valid, this is not automatically a repair fault. During the exam, preserve valid progress. During review, train method selection separately. Do not confuse suboptimal with invalid.

Case AX: repair when the route is valid but too expensive

Again, no mathematical repair may be needed. The improvement target is efficiency. Repair sequencing applies to confirmed invalid states, not every route that could have been shorter.

Case AY: repair when uncertainty remains after all known faults are fixed

Switch from repair mode to verification mode. Do not keep changing valid states merely because confidence has not emotionally returned. Use independent evidence to decide whether the repaired solution is trustworthy.

Case AZ: the solution is repaired but the page is unreadable

If the mathematics is valid but authority is impossible to reconstruct, rewrite the final decisive portion cleanly if time allows. Legibility supports both re-entry and marking. Do not rewrite unaffected early work merely for aesthetics.

The final repair sequencing doctrine

Repair sequencing is not a preference for early lines, a fetish for neat pages or a command to restart less. It is a control system for restoring mathematical authority in the cheapest safe order.

• Repair causes before consequences when dependency exists.
• Preserve correct work when independence exists.
• Expect masking to distort what the endpoint looks like during repair.
• Retire stale states aggressively.
• Regenerate candidates after source equations change.
• Refilter rather than recompute when only constraints change.
• Restart when contamination makes local repair uneconomical.
• Switch methods when the repaired state invalidates the old route.
• Use mark return and time only after mathematical precedence is resolved.
• Regression-test before closing.

The final student question

When several things are wrong at once, the expert question is not “Which mistake annoys me most?” It is:

Which correction restores authority to the largest valid part of the solution, and what exactly should survive when I make it?

Post-Repair Handoff: How a Corrected State Becomes Authoritative Again

Repair sequencing does not end when the last known mistake has been edited. A corrected state must be handed back into the main solution cleanly. Otherwise the page can contain several versions of the same quantity, and the student may accidentally continue from the wrong one.

The post-repair handoff should answer four questions. First: what is the current authoritative state? Second: which older states are now retired? Third: which downstream states have already been regenerated from the correction? Fourth: which states still require revalidation?

The authoritative-state declaration

After a major repair, write the corrected equation, parameter, branch or value clearly enough that there is no ambiguity about what the rest of the solution should use. This declaration can be as small as one clean rewritten line. Its purpose is not presentation polish. It is state control.

The stale-state sweep

Scan the repaired region for old values that remain visually active. A stale value may survive in a margin, calculator memory, substituted expression, graph label or later branch. Retire or replace it before continuing. One overlooked stale copy can recreate the same fault after the repair was mathematically correct.

The dependency sweep

Now follow the corrected state outward. Recompute direct dependents first. Revalidate high-value indirect dependents. Preserve independent branches. If a corrected state changes branch, domain or candidate status, reopen those checks before treating later work as current.

The masking sweep

If the endpoint became worse after repair, do not immediately distrust the correction. Ask whether an earlier error had been compensating for a second fault. Search the newly exposed region rather than undoing a verified fix. A clean repair sequence may temporarily make the solution look less correct while making the mathematics more valid.

The answer-contract sweep

Once the repaired chain is stable, return to the actual demand of the question. Check exactness, units, interval, number of solutions, required variable, requested form and interpretation. Output formatting belongs at the end because it must be applied to the final authoritative state rather than to a stale pre-repair answer.

The final repair handoff loop

Declare Current State → Retire Old Versions → Recompute Direct Dependents → Revalidate Important Indirect Dependents → Check Masking Exposure → Reapply Constraints → Match Answer Contract → Continue.

This final handoff closes the repair system. The student is no longer merely changing wrong lines. The student is restoring one coherent mathematical source of truth and ensuring that every later step is connected to it.