Revision Is a Compiler, Not a Calendar
A revision timetable is only useful if the tasks inside it match the learner’s actual state. Equal time for every component can waste effort when one bottleneck is responsible for most of the lost performance.
The revision runtime is:
Diagnose → Select → Retrieve → Apply → Simulate → Repair → Recompile.
1. Diagnose Before Scheduling
Use recent schoolwork, practice papers and writing samples to locate the earliest recurring failure.
| Evidence | Possible revision target |
|---|---|
| Knows words but cannot use them | Vocabulary retrieval and transfer |
| Grammar fails only in long writing | Integration under load |
| Comprehension answers miss evidence | Reconstruction and evidence selection |
| Writing ideas are weak | Idea generation and route selection |
| Unfinished timed work | Time drift and execution |
| Same errors repeat after feedback | Repair and maintenance loop |
2. Select the Smallest High-Value Task
Do not automatically assign a full paper. If the weakness is pronoun reference, practise reference. If the weakness is route selection in composition, practise route selection.
Full tasks are for integration and simulation. Small tasks are for repair.
3. Retrieve Before Rereading
Revision becomes stronger when the learner has to produce information or a method from memory before checking notes.
- Explain a grammar relationship without the workbook open.
- Generate vocabulary from an intended meaning.
- Rebuild a composition skeleton from a topic.
- Summarise a passage after closing it.
4. Apply the Capability in Context
A rule remembered in isolation is not yet enough. Put it back into a sentence, passage, oral response or composition scene.
Know → Retrieve → Use → Transfer.
5. Simulate Only After the Pieces Are Stable
Timed papers are useful when the goal is to test integrated performance. They are inefficient when the learner is still relearning basic pieces during every simulation.
Use simulation to answer: What disappears when time, length and sustained attention are added?
6. Repair From the Earliest Cause
After a simulation, do not simply mark every error and repeat another paper. Cluster the errors and find the shared source.
One repaired bottleneck can remove several downstream symptoms.
7. Recompile the Revision Plan
A good revision plan changes when the learner changes. Once a weakness stabilises, reduce its share and move resources to the next bottleneck.
Do not continue yesterday’s plan just because it was written neatly.
8. Separate Practice Modes
| Mode | Main purpose |
|---|---|
| Learn | Install or clarify a capability |
| Retrieve | Make it available without prompts |
| Repair | Fix a specific failure |
| Transfer | Use it on a changed surface |
| Simulate | Test whole-system execution |
| Maintain | Check that it remains available after delay |
9. Parents Should Ask for the Reason Behind the Task
“Do another worksheet” is not a revision strategy by itself. A useful task should answer: What are we trying to repair or verify?
As the student becomes more independent, they should increasingly be able to choose and justify the next revision task themselves.
The Revision Compiler Card
DIAGNOSE — What is the current bottleneck?
SELECT — What is the smallest task that targets it?
RETRIEVE — Can I do it without looking?
SIMULATE — Does it survive real load?
REPAIR — What failed first?
RECOMPILE — What should tomorrow’s plan now contain?
The Exit Condition
Revision is working when the plan becomes more selective over time: weak capabilities are repaired, stable ones require less support, and simulation increasingly measures independent execution rather than exposing the same untreated errors.