Bukit Timah Tutor Secondary Mathematics

WhatsApp Us Here

EducationOS Corridor Pack — Starter Set (12 Corridors) v1.0

(Matches your 12–16 week repair protocol: Depth → Structure → Load → Transfer. Publish as a runnable pack.)

Canonical One-Liner

EducationOS succeeds when learners run a small set of stable corridors repeatedly under load, with fast repair loops and transfer gates—so competence becomes durable and portable, not template-bound.

0) Pack Metadata

PackID: EDU×Z0×Pack×Starter12×v1.0
Scope: individual learner / tutor intervention (Z0–Z1), generalisable to Z2 implementations
Roles: Operator corridors (execution) gated by Oracle tests (truth)

1) The 12 CorridorIDs (Enumerated)

A) Depth Building (Phase 1) — 3 Corridors

  1. Input Capture Corridor
    EDU×Z0×Op×Plan×InputHarvest15×v1.0
    Purpose: extract 15 usable nodes/binds from reading/listening weekly.
  2. Node→Bind Expansion Corridor
    EDU×Z0×Op×Explain×NodeBindExpand×v1.0
    Purpose: convert words/ideas into collocations + connectors + usage constraints.
  3. Micro-Output Corridor (Daily)
    EDU×Z0×Op×Write×MicroOutput6×v1.0
    Purpose: 6-sentence daily output with connector discipline (low choice).

B) Structure & Planning (Phase 2) — 3 Corridors

  1. Scope Lock Corridor (Question Understanding)
    EDU×Z0×O·Op×Audit×ScopeLockQ×v1.0
    Purpose: prevent scope drift; define what is included/excluded before work begins.
  2. Plan-First Corridor (5-Box / Outline)
    EDU×Z0×Op×Plan×5BoxPlan×v1.0
    Purpose: reduce choice explosion by fixing structure early.
  3. Explain-Back Corridor (Teach It Simply)
    EDU×Z0×Op×Explain×ExplainBack3×v1.0
    Purpose: learner explains concept in 3 steps (definition→mechanism→example).

C) Load Training (Phase 3) — 3 Corridors

  1. Timed Output Corridor (Core Work)
    EDU×Z0×Op×Write×TimedCoreOutput×v1.0
    Purpose: produce under time with stable structure and minimal forks.
  2. Checklist Sweep Corridor (Operator Stabiliser)
    EDU×Z0×Op×Audit×ChecklistSweep×v1.0
    Purpose: reduce variance by enforcing a short SOP checklist.
  3. One-Paragraph Rewrite Corridor (Targeted Repair)
    EDU×Z0×Op×Repair×RewriteWeakestPara×v1.0
    Purpose: repair the single weakest segment (highest ROI), not everything.

D) Transfer & Exam Application (Phase 4) — 3 Corridors

  1. Transfer Variant Corridor (Context Swap)
    EDU×Z0×O·Op×Solve×TransferVariant3×v1.0
    Purpose: run 3 variants with different surface forms; pass transfer gate.
  2. Full Simulation Corridor (Monthly)
    EDU×Z0×Op×Write×FullSimPaper×v1.0
    Purpose: real exam conditions; measure stability/variance.
  3. Backtest & Calibration Corridor (Loop Closure)
    EDU×Z0×O×Audit×BacktestCalibrate×v1.0
    Purpose: update plan based on sensors; adjust buffers, targets, and repair focus.

2) Pack-Wide Sensors (Minimum)

Every corridor run logs:

  • TimedVariance
  • TransferPassRate
  • RepairLatency
  • ExceptionCount (special cases / forks)
  • CompletionRate
  • ρ_proxy (choices injected ÷ capacity proxy)

3) Pack-Wide Gates (Promotion Rules)

A learner is “stable” when:

  • TimeGate: can complete core outputs within time
  • TransferGate: passes 3 variants without collapsing
  • OperatorGate: can run checklist + rewrite without tutor prompts
  • VarianceGate: volatility drops over 3–4 weeks

Only then scale difficulty.

4) Failure Mode Trace (Pack Level)

No scope lock → forks explode → timed variance rises → repair comes late → transfer fails → false competence → drift baseline → exam shock → P0 event.
Repair: truncate choices → rerun plan corridor → targeted rewrite → transfer variants → recalibrate.

Copyable Almost-Code Block

EducationOS.CorridorPack.Starter12.v1.0:
  Corridors:
    Phase1 Depth: InputHarvest15, NodeBindExpand, MicroOutput6
    Phase2 Structure: ScopeLockQ, 5BoxPlan, ExplainBack3
    Phase3 Load: TimedCoreOutput, ChecklistSweep, RewriteWeakestPara
    Phase4 Transfer: TransferVariant3, FullSimPaper, BacktestCalibrate
  Sensors: TimedVariance, TransferPassRate, RepairLatency, ExceptionCount, CompletionRate, ρ_proxy
  Gates: TimeGate, TransferGate, OperatorGate, VarianceGate
  Rule: scale only after gates pass; version forward only

Below are the 12 full corridor record pages (standard schema). Each is paste-ready as its own section/page. All IDs are frozen and versioned.

1) EDU×Z0×Op×Plan×InputHarvest15×v1.0

CorridorID: EDU×Z0×Op×Plan×InputHarvest15×v1.0
Definition: Weekly input harvesting corridor to capture 15 usable nodes/binds from reading/listening for downstream production.
OwnerRole: Op
Status: SOP
Version: v1.0

EntryConditions

  • One input source selected (article/story/video)
  • Timer available (20–30 min)

Steps

  1. Read/Listen pass (10–15 min) without stopping
  2. Harvest 10 nodes: verbs/nouns/adjectives with high utility
  3. Harvest 5 binds: connectors/collocations/phrases
  4. Tag usage: “when to use” + 1 sentence per item
  5. Store in bank (date + topic label)

ExitConditions

  • 15 items stored with at least 15 example sentences total

FailureModes

  • harvesting only “rare words” (low utility)
  • no example sentences (no bind)
  • inconsistent storage (lost bank)

Sensors

  • CompletionRate (weekly)
  • UtilityScore (self-rated 1–5: likely to use)
  • BindCoverage (# items with usage constraint)

Gates

  • OperatorGate: can run without prompts
  • TransferGate: items appear in writing within 7 days

Dependencies

  • Vocabulary bank template
  • Simple tagging rules (topic + utility)

2) EDU×Z0×Op×Explain×NodeBindExpand×v1.0

CorridorID: EDU×Z0×Op×Explain×NodeBindExpand×v1.0
Definition: Expand each harvested node into binds (collocations, connectors, constraints) to increase corridor geometry.
OwnerRole: Op
Status: SOP
Version: v1.0

EntryConditions

  • 5 nodes selected from bank
  • Dictionary/examples available (optional)

Steps

  1. For each node, write 2 collocations
  2. Write 1 synonym + 1 contrast (not equal; explain difference)
  3. Write 1 usage constraint (“use when…; avoid when…”)
  4. Write 2 sentences in different contexts
  5. Select 1 “best bind” per node

ExitConditions

  • 5 nodes expanded with ≥10 collocations + ≥10 sentences

FailureModes

  • synonyms treated as identical (semantic drift)
  • no constraints → misuse later
  • copying without understanding

Sensors

  • BindCount per node
  • ConstraintQuality (0/1 present)
  • TransferUse (appears correctly in output)

Gates

  • OracleGate (optional): tutor checks constraints correct
  • TransferGate: used correctly in 2 different outputs

Dependencies

  • Basic meaning lock discipline (definition + scope)

3) EDU×Z0×Op×Write×MicroOutput6×v1.0

CorridorID: EDU×Z0×Op×Write×MicroOutput6×v1.0
Definition: Daily 6-sentence micro-output corridor to stabilise production binds with low choice.
OwnerRole: Op
Status: SOP
Version: v1.0

EntryConditions

  • Choose 1 topic (day/event/scene)
  • Choose 2 nodes + 2 connectors

Steps

  1. Sentence 1: scene/claim
  2. Sentence 2: because
  3. Sentence 3: therefore
  4. Sentence 4: however
  5. Sentence 5: example/detail
  6. Sentence 6: closure/insight

ExitConditions

  • 6 sentences, connectors used correctly, no scope drift

FailureModes

  • connector misuse
  • too many topic changes (forks)
  • incomplete closure

Sensors

  • DailyCompletionRate
  • ConnectorAccuracy
  • TimedVariance (6 sentences within 8–10 min)

Gates

  • OperatorGate: can run in <10 min consistently
  • TransferGate: micro-output improves paragraph writing

Dependencies

  • connector list (because/therefore/however/etc.)

4) EDU×Z0×O·Op×Audit×ScopeLockQ×v1.0

CorridorID: EDU×Z0×O·Op×Audit×ScopeLockQ×v1.0
Definition: Lock scope before answering to prevent drift, wrong objective, and wasted work.
OwnerRole: O·Op
Status: SOP
Version: v1.0

EntryConditions

  • Question/prompt visible

Steps

  1. Write: Task = _ (what must be produced)
  2. Write: Must include = _ (2–3 constraints)
  3. Write: Must not do = _ (common drift)
  4. Choose success check (1 sentence rubric)
  5. Start work only after scope lock written

ExitConditions

  • A 4-line scope lock exists

FailureModes

  • skipping scope lock under time
  • writing vague constraints
  • changing scope mid-run

Sensors

  • ScopeLockPresent (0/1)
  • ScopeDriftIncidents (# per piece)
  • RepairLatency when drift occurs

Gates

  • OracleGate: scope lock matches prompt
  • OperatorGate: done automatically before every task

Dependencies

  • definition/scope lock habit (LanguageOS)

5) EDU×Z0×Op×Plan×5BoxPlan×v1.0

CorridorID: EDU×Z0×Op×Plan×5BoxPlan×v1.0
Definition: Pre-plan structure to reduce forks and stabilise output under load (writing or explanation).
OwnerRole: Op
Status: SOP
Version: v1.0

EntryConditions

  • Scope lock done

Steps

  1. Box1: hook/intro
  2. Box2: build point 1
  3. Box3: peak point 2 / turning
  4. Box4: resolution
  5. Box5: reflection/lesson
  6. Assign 1 key phrase per box

ExitConditions

  • 5 boxes filled; 1 phrase each; total <7 minutes

FailureModes

  • over-planning (time blowout)
  • too many points per box
  • plan ignored during writing

Sensors

  • PlanTime
  • PlanAdherence (% paragraphs match box)
  • ForkCount during writing

Gates

  • TimeGate: plan created fast
  • OperatorGate: plan used in output

Dependencies

  • phrase bank + connectors

6) EDU×Z0×Op×Explain×ExplainBack3×v1.0

CorridorID: EDU×Z0×Op×Explain×ExplainBack3×v1.0
Definition: Learner explains back in 3 steps to prove binds exist (definition→mechanism→example).
OwnerRole: Op
Status: Gated
Version: v1.0

EntryConditions

  • Concept taught once

Steps

  1. Define in 1 sentence
  2. Explain mechanism in 2 sentences (because/therefore)
  3. Give 1 example and 1 “fails when” counterexample

ExitConditions

  • Explanation completed in ≤2 minutes

FailureModes

  • parroting definition only
  • no mechanism
  • example not aligned

Sensors

  • TimedCompletion
  • MechanismClarityScore (rubric 0–2)
  • TransferPassRate (variant)

Gates

  • TransferGate: passes 2 variants
  • OracleGate: tutor rubric ≥ threshold

Dependencies

  • connector discipline + scope lock

7) EDU×Z0×Op×Write×TimedCoreOutput×v1.0

CorridorID: EDU×Z0×Op×Write×TimedCoreOutput×v1.0
Definition: Produce core output under timed load with minimal forks and stable structure.
OwnerRole: Op
Status: SOP
Version: v1.0

EntryConditions

  • scope lock + 5-box plan done

Steps

  1. Write paragraph by paragraph following plan
  2. Use 1 connector per paragraph minimum
  3. Do not change plan mid-run
  4. Leave 3 minutes for checklist sweep

ExitConditions

  • complete draft within time

FailureModes

  • mid-run rewriting (time collapse)
  • plan abandonment
  • excessive forks (new plot points)

Sensors

  • CompletionRate
  • TimedVariance
  • ForkCount
  • ScopeDriftIncidents

Gates

  • TimeGate: finishes inside window 3 times in a row
  • VarianceGate: volatility drops over 2 weeks

Dependencies

  • checklist sweep corridor

8) EDU×Z0×Op×Audit×ChecklistSweep×v1.0

CorridorID: EDU×Z0×Op×Audit×ChecklistSweep×v1.0
Definition: Final stabiliser corridor to reduce variance and prevent avoidable losses.
OwnerRole: Op
Status: SOP
Version: v1.0

EntryConditions

  • draft completed

Steps (2–4 minutes)

  1. Check scope lock match
  2. Check paragraph structure
  3. Check tense consistency
  4. Check connectors used correctly
  5. Fix 3 errors max (avoid over-edit)

ExitConditions

  • sweep done; only high-ROI fixes applied

FailureModes

  • over-editing (time blowout)
  • skipping sweep
  • fixing low-impact details first

Sensors

  • SweepDone (0/1)
  • ErrorCatchRate
  • TimeUsed

Gates

  • OperatorGate: always used in timed runs

Dependencies

  • small checklist (frozen)

9) EDU×Z0×Op×Repair×RewriteWeakestPara×v1.0

CorridorID: EDU×Z0×Op×Repair×RewriteWeakestPara×v1.0
Definition: Targeted repair corridor: rewrite only the weakest paragraph to raise output quality fastest.
OwnerRole: Op
Status: SOP
Version: v1.0

EntryConditions

  • feedback identifies weakest paragraph (or self-diagnosis)

Steps

  1. Mark the weakest paragraph
  2. Identify failure mode (scope/bind/clarity/detail)
  3. Rewrite using: topic sentence → 2 details → connector → closure
  4. Re-run checklist sweep on that paragraph only

ExitConditions

  • rewritten paragraph is clearer and aligned

FailureModes

  • rewriting everything (scope creep)
  • no diagnosis (random edits)
  • detail added without structure

Sensors

  • RepairLatency
  • ParagraphScoreDelta
  • FailureModeFrequency

Gates

  • TransferGate: same fix works on a new task

Dependencies

  • failure-mode labels + paragraph template

10) EDU×Z0×O·Op×Solve×TransferVariant3×v1.0

CorridorID: EDU×Z0×O·Op×Solve×TransferVariant3×v1.0
Definition: Run 3 context variants to prove competence transfers beyond template.
OwnerRole: O·Op
Status: Gated
Version: v1.0

EntryConditions

  • base corridor completed once successfully

Steps

  1. Variant A: new topic / same structure
  2. Variant B: new wording / same concept
  3. Variant C: new constraint (shorter time / different audience)
  4. Score each with the same rubric
  5. Repair only the weakest failure mode, then rerun C

ExitConditions

  • pass all 3 variants

FailureModes

  • works only on A (template)
  • collapses under constraint (timing)
  • scope drift on new wording

Sensors

  • TransferPassRate
  • VarianceAcrossVariants
  • RepairLatency

Gates

  • TransferGate: 3/3 pass
  • OracleGate: rubric threshold met

Dependencies

  • rubric + variant generator

11) EDU×Z0×Op×Write×FullSimPaper×v1.0

CorridorID: EDU×Z0×Op×Write×FullSimPaper×v1.0
Definition: Monthly full simulation corridor to measure stable competence under real exam load.
OwnerRole: Op
Status: SOP
Version: v1.0

EntryConditions

  • exam conditions set (timer, no help)

Steps

  1. Scope lock (fast)
  2. Plan (fast)
  3. Timed core output
  4. Checklist sweep
  5. Log sensors (variance, drift, transfer notes)

ExitConditions

  • full paper completed with logged metrics

FailureModes

  • skipping logs (no calibration)
  • panic rewriting mid-run
  • inconsistent routine

Sensors

  • TimedVariance
  • CompletionRate
  • ScopeDrift
  • ChecklistUse
  • ScoreTrend

Gates

  • VarianceGate: stability improving month to month
  • TransferGate: variant prompts within sim

Dependencies

  • the 4 SOP corridors (scope/plan/write/sweep)

12) EDU×Z0×O×Audit×BacktestCalibrate×v1.0

CorridorID: EDU×Z0×O×Audit×BacktestCalibrate×v1.0
Definition: Close the loop: analyse logs, detect drift causes, and adjust corridor schedule and buffers.
OwnerRole: O
Status: SOP
Version: v1.0

EntryConditions

  • at least 2 weeks of logs (or 1 full sim)

Steps

  1. Identify top failure mode (most frequent)
  2. Identify top sensor breach (ρ proxy / variance / transfer)
  3. Choose 1 repair corridor for next week
  4. Add buffer time and protect repair bandwidth
  5. Set a simple target: “reduce X by Y%”

ExitConditions

  • next-week plan updated with explicit repair focus

FailureModes

  • changing too many variables at once
  • ignoring transfer failure
  • no protected repair time

Sensors

  • FailureModeRank
  • SensorTrend
  • RepairCompletionRate
  • VarianceTrend

Gates

  • OracleGate: plan change justified by data
  • CadenceGate: no churn faster than 1-week window

Dependencies

  • logging template + rubric

Start Here: 

Start Here:

eduKateSG Learning Systems: 

Recommended Internal Links (Spine)

Start Here for Lattice Infrastructure Connectors

Start here if you want the full sequence:

Vocabulary OS Series Index:

Fence English Learning System: 

eduKateSG Learning Systems: 

Recommended Internal Links (Spine)

Start Here for Lattice Infrastructure Connectors