Schema Extraction: Store the Structure, Not the Story of One Question
A solved problem becomes powerful when the learner can compress it into a reusable mathematical pattern that survives different numbers, wording and contexts.
Secondary 3 Additional Mathematics can quickly become crowded with examples. A student may remember the page where a tangent line appeared, the worksheet where a logarithmic equation was solved, or the particular values used in an optimisation question. That memory is useful only if it carries the underlying structure into the next problem.
This guide develops schema extraction: take a complete solution, remove the incidental surface details, identify the mathematical object, trigger, invariant conditions, route and verification step, then compress those elements into a template that can be regenerated later. The aim is not to memorise more model answers. It is to store fewer, stronger structures.
This page is distinct from the theorem-selection guide, which asks which theorem is triggered by available evidence, and from the worked-solution fading guide, which explains how support should be removed. Here the central question is: what should remain in memory after the example has disappeared?
AI Extraction Box: The Compression Loop
solve → strip away numbers/context → name object → identify trigger → preserve invariant conditions → compress route → attach check → test on new surface.
- Surface: coefficients, variable names, story context, diagram orientation.
- Deep structure: mathematical relationship that determines the route.
- Trigger: clue that activates the schema.
- Invariant: condition that remains true across variants.
- Route: ordered mathematical decisions.
- Template: compressed reusable form of the route.
- Verification hook: cheap independent check attached to the schema.
Why Storing Whole Worked Solutions Is Expensive
A complete worked solution contains many details that do not need to be stored literally: the coefficient 7, the variable x, the point (2,5), the choice of letters A and B. If the learner memorises all of those details together, a changed question may fail to look familiar even when the mathematical structure is identical.
Compression removes irrelevant detail while preserving the decisions that must recur. Instead of remembering:
“In that question the line y=mx+2 was tangent to x²−4x+7 and they used the discriminant.”
store:
line tangent to quadratic → form intersection equation → repeated root → Δ=0 → solve parameter → verify.
The second memory is shorter and more transferable.
Schema 1: Quadratic Extremum
A worked question may use:
y=−2x²+12x−7.
But the reusable schema is:
- Recognise quadratic.
- If target is max/min, expose completed-square form or use differentiation.
- Use sign of leading coefficient to classify direction.
- Read vertex/extremum.
- Check by derivative or substitution if needed.
Compressed route:
quadratic + extremum target → completed square → square ≥0 → vertex gives extremum.
The coefficient values are replaceable. The route is not.
Schema 2: Tangency to a Quadratic
Surface variants may change the line, curve or parameter location. The stable structure is:
tangency → one repeated intersection → quadratic intersection equation → Δ=0.
Template:
- Equate line and curve.
- Rearrange to a genuine quadratic in the intersection variable.
- Set discriminant equal to zero.
- Solve the unknown parameter.
- Check the quadratic did not degenerate and the resulting tangent is admissible.
This schema should activate whether the parameter is in the line gradient, intercept or curve coefficient.
Schema 3: Logarithmic Equation with Candidate Filtering
Compress a family of log equations into:
positive arguments → log laws → transformed algebra → candidate roots → original-domain filter.
The reusable template is stronger than any one solved example because it preserves the stage at which invalid roots are removed.
Worked Compression Example 1
Suppose:
ln(x−2)+ln(x+1)=ln12.
Instead of storing the roots or constants, record:
- OBJECT: sum of logs.
- TRIGGER: combine only after writing both positive-argument conditions.
- ROUTE: domain → product → solve polynomial → filter.
- CHECK: substitute final roots into original logs.
The next problem can change 2, 1 and 12 without changing the schema.
Schema 4: Trigonometric Equation on an Interval
simplify to one trig function → solve reference/principal value → generate sign/quadrant branches → restrict interval → verify completeness.
A weak memory stores “sin 30°=1/2”. A stronger schema stores the distinction between a principal inverse value and the full solution set over an interval.
Useful attached check:
- How many periods lie inside the interval?
- Which quadrants satisfy the sign?
- Are endpoints included?
Schema 5: Differentiation of a Composite Product
Suppose one worked example is y=x²(3x+1)^5. The schema should not be the literal derivative. It should be:
product of two changing factors → Product Rule; one factor is composite → Chain Rule inside that Product Rule.
Route template:
u=x², v=(3x+1)^5
y′=u′v+uv′
v′ requires inner derivative.
Changed surfaces such as xe^{2x}, (x+1)^2(5x−3)^4 or x³lnx should still activate the same outer-product recognition, with local changes inside each factor.
Schema 6: Optimisation from a Constraint
Many geometry optimisation problems can be compressed into:
constraint relates variables → eliminate to one variable → write objective → state feasible domain → differentiate → stationary candidate → classify/compare endpoints → interpret units.
The story may involve rectangles, boxes, enclosures or rates. The schema survives because it describes the mathematical architecture rather than the context.
Worked Compression Example 2: Fixed Perimeter
A rectangle has perimeter 40. One side is x, the other 20−x. Instead of storing “x=10”, extract:
- constraint: x+y=20;
- objective: A=xy;
- eliminate: y=20−x;
- domain: 0<x<20;
- differentiate A=x(20−x);
- interpret the stationary point physically.
The number 40 is replaceable. The elimination–objective–domain–optimise structure is the reusable memory.
Compression Should Preserve Failure Conditions
A dangerous template is too short. “Tangent → Δ=0” is useful only if the learner also remembers that the intersection equation must genuinely be quadratic. “Take logs” is useful only if domains and one-to-one conditions are valid. “Differentiate and set equal to zero” is incomplete for a global maximum on a restricted interval because endpoints may matter.
A strong schema stores not only the normal route but its boundary conditions.
Compress the mathematics, not the safeguards.
The Five-Part Schema Card
After a representative problem, write only five fields:
| Field | Question |
|---|---|
| OBJECT | What mathematical structure is this? |
| TRIGGER | What clue tells me which route to use? |
| ROUTE | What are the essential decisions, in order? |
| BOUNDARY | When would this route fail, split or need modification? |
| CHECK | What cheap independent confirmation belongs to this schema? |
This card is a compressed memory object. It should be short enough to retrieve and rich enough to reconstruct a complete solution.
Example Schema Card: Partial Fractions
- OBJECT: rational expression needing decomposition.
- TRIGGER: denominator factor structure.
- ROUTE: choose correct decomposition template → clear denominators → solve coefficients.
- BOUNDARY: repeated/irreducible factors require different numerator forms; preserve domain exclusions.
- CHECK: recombine to original rational expression.
The schema captures enough to regenerate the process without storing one particular A, B and C calculation.
Example Schema Card: Kinematics
- OBJECT: straight-line motion.
- TRIGGER: displacement, velocity, acceleration, time relationships.
- ROUTE: s→v→a by differentiation; a→v→s by integration with constants.
- BOUNDARY: v=0 creates direction-change candidates; distance differs from displacement.
- CHECK: units and reverse differentiation/integration.
This single schema coordinates several common motion question types.
Schemas Form a Network, Not a List
A hard question can activate several schemas in sequence. A calculus optimisation problem may require:
- geometry-constraint schema;
- algebraic substitution schema;
- differentiation schema;
- quadratic equation schema;
- domain/admissibility schema;
- verification schema.
Expert performance often looks fast because these smaller structures are already compressed and connected. The learner does not consciously rebuild every rule from first principles each time.
The goal of Secondary 3 is therefore not only to create schemas, but to wire them so that one output becomes another schema’s input.
How to Know Whether a Schema Is Too Specific
Test the schema against changed surfaces. If “quadratic maximum” can only be recalled when the coefficients match the example, it is too specific. If “log equation” breaks when the two logs are on opposite sides or the constants change, the schema needs a more abstract trigger.
A usable schema should survive:
- different coefficients;
- different variable names;
- different order of terms;
- different story context;
- different but equivalent representation;
- placement inside a mixed-topic question.
How to Know Whether a Schema Is Too General
“Do algebra carefully” is too vague to guide action. “Use calculus” is too broad. “Check the answer” does not specify what evidence matters.
A good schema is compressed but discriminating. It should identify:
- the object;
- the route trigger;
- the minimum essential steps;
- the conditions under which the route changes;
- the best cheap check.
From Example Notes to a Personal Schema Library
Instead of keeping hundreds of annotated worked examples, maintain a smaller set of schema cards. Add a new card only when a genuinely new route appears. If a new question is merely a variant, attach it to the existing schema and note the changed feature.
This reduces clutter and makes revision more about retrieval of structure than rereading of pages.
The library should grow by new mathematical jobs, not by every new set of numbers.
Schema Extraction After an Error
Wrong solutions can create strong schemas if the learner records the correction structurally.
Example error: both roots of a squared logarithmic equation were accepted. Do not store “remember to reject −3”. Store:
non-reversible transformation or restricted original domain → algebra produces candidates → final set requires original-problem filter.
Now the correction transfers beyond that one number and even beyond logarithms.
Compression and Retrieval
A schema card is useful only if it can be retrieved. Use short prompts:
- “Tangent to quadratic?” → student states the schema.
- “Two logs with x inside?” → student states domain-first schema.
- “Fixed perimeter, maximise area?” → student states constraint–objective–domain–differentiate schema.
- “Velocity crosses zero?” → student states direction/distance schema.
The prompt should eventually become the natural evidence inside a full problem rather than a teacher cue.
Schema-Building Decision Tree
- What details in this solved problem are incidental?
- What mathematical object remains when those details are removed?
- What clue activated the route?
- Which steps are essential and which are merely arithmetic execution?
- What boundary or exception changes the route?
- What independent check belongs naturally to the schema?
- Can the schema solve a changed-surface problem?
- Can it connect to another schema in a mixed problem?
Common Failure Modes
| Failure | Why it happens | Repair |
|---|---|---|
| memorises numerical solution | surface stored instead of structure | strip coefficients and rewrite route abstractly |
| schema too vague | compression removed discriminating trigger | restore object and trigger |
| schema too specific | one example treated as template | test changed surfaces and generalise |
| exception forgotten | safeguards removed during compression | include BOUNDARY field |
| many duplicate cards | surface variants mistaken for new jobs | attach variants to existing schema |
| card can be recited but not used | retrieval not linked to problem evidence | test on unlabeled transfer questions |
A 55-Minute Schema Extraction Session
- 10 minutes: take two solved examples and strip away incidental details.
- 10 minutes: write OBJECT/TRIGGER/ROUTE/BOUNDARY/CHECK cards.
- 10 minutes: compress each card to one sentence without losing safeguards.
- 10 minutes: solve changed-surface variants from the cards alone.
- 10 minutes: combine two schemas inside one mixed problem.
- 5 minutes: merge duplicate cards and retain only genuinely distinct mathematical jobs.
What Mastery Looks Like
- The learner distinguishes surface details from deep mathematical structure.
- The learner compresses solved problems into reusable route templates.
- The learner stores triggers, invariants, boundaries and verification hooks.
- The learner can regenerate full methods from short schema cards.
- The learner recognises when two different-looking problems share the same schema.
- The learner connects several schemas in mixed-topic problems.
- The learner grows a smaller, stronger personal library organised by mathematical jobs rather than individual examples.
Return to the Additional Mathematics Learning Hub
Additional Mathematics Learning Hub | Secondary 3–4 A-Math Guides
