ULD Is a High-Resolution Diagnostic (Read Before Applying)
Universal Learning Diagnostics (ULD) is a high-resolution diagnostic system. Like all precision diagnostics, it requires correct sequencing, controlled testing, and verification through retests.
ULD is designed to diagnose capability states, not to provide instant labels or one-off judgements. When applied correctly, it identifies the exact bottleneck that causes learning plateaus or performance failure. When applied incorrectly, it may produce unstable or misleading results.
This does not invalidate ULD. It reflects misuse of the protocol.
ULD is only useful if it is run consistently. This protocol exists to prevent guesswork, opinion, and “framework drift”.
The protocol is universal because it does not depend on subject content. It depends on three actions:
- Define the task interface
- Test Depth, then Load, then Transfer
- Repair the limiting axis, then verify using retests
If you follow this protocol, ULD becomes measurable and repeatable across school, work, and life.
Protocol Reminder (Non-Negotiable)
If any step in this protocol is skipped:
- diagnosis must be treated as provisional
- repair should not be escalated
- retesting is required
ULD remains reliable only when the protocol is respected.
Why Protocol Discipline Matters
ULD works only when the diagnostic order is respected:
Depth → Load → Transfer
Skipping this order is the most common source of misdiagnosis. For example:
- Testing under pressure before confirming understanding can mislabel Load issues as lack of ability.
- Jumping straight to Transfer without verifying Depth can mistake unfamiliarity for incapacity.
The protocol exists to prevent these errors.
Capability States vs Causes (Critical Distinction)
ULD measures capability states:
- Depth (understanding integrity)
- Load (performance stability under constraint)
- Transfer (generalisation across contexts)
ULD does not diagnose causes such as motivation, anxiety, attention, language background, sleep, or health. These are upstream factors that express themselves by weakening Depth, Load, or Transfer.
Stopping at the cause story without diagnosing the capability state leads to ineffective repair
Verification Is Not Optional
A ULD diagnosis is valid only if it predicts retest outcomes.
Every diagnosis must be verified by:
- simplifying to confirm Depth
- adding constraints to confirm Load
- varying formats or contexts to confirm Transfer
Assigning bands or conclusions from a single observation violates the protocol and reduces diagnostic reliability.
Step 0: Define the Task Interface (Non-Negotiable)
ULD must be applied to a defined task interface. Otherwise, diagnosis is meaningless.
Before testing, define:
- the task (what must be done)
- the format (written, spoken, practical)
- the language (English, bilingual, technical)
- the environment (calm, timed, observed)
- the constraint level (time, complexity, stakes)
ULD does not “judge the human”.
ULD measures the human’s capability within a specified interface.
If the interface changes, Load and Transfer are expected to move.
Step 1: Run Depth First
Depth is tested by removing scaffolding.
Depth test rules
- simplify the task
- remove hints and templates
- ask for explanation in the human’s own words
- require reconstruction, not recognition
- check if the human can detect an error
Depth pass condition
The human can explain and reconstruct without prompts.
If Depth fails, do not test Load or Transfer yet. Repair Depth first.
Depth page:
https://edukatesg.com/uld-depth/
Step 2: Run Load Second
Load is tested by adding constraints while holding content stable.
Load test rules
- add time pressure
- add multi-step density
- simulate real conditions (exam, interview, live execution)
- observe error rate under constraint
Load pass condition
Performance remains stable as constraints tighten.
If Depth passes but Load fails, repair Load before testing Transfer.
Load page:
https://edukatesg.com/uld-load/
Step 3: Run Transfer Third
Transfer is tested by changing the distribution, not increasing difficulty.
Transfer test rules
- change format (same concept, different representation)
- change context (same structure, different setting)
- remove cues (force independent recognition of structure)
- recombine familiar elements in unfamiliar ways
Transfer pass condition
The human adapts successfully to new forms.
Transfer page:
https://edukatesg.com/uld-transfer/
Step 4: Identify the Limiting Axis (The Bottleneck Rule)
ULD assumes a bottleneck exists.
Most humans do not fail everywhere. They fail at the boundary where a capability breaks.
After testing, identify the limiting axis:
- If the human cannot explain or reconstruct → Depth bottleneck
- If the human collapses under constraint → Load bottleneck
- If the human collapses under novelty → Transfer bottleneck
A human may have more than one bottleneck, but always repair in this order:
Depth → Load → Transfer
Never reverse the order. Reversing the order creates false improvements.
Step 5: Repair the Bottleneck (ULD Does Not Prescribe Methods)
ULD does not prescribe teaching methods. It enforces repair logic.
Repair rules
- Repair Depth by strengthening structure and explanation
- Repair Load by training stability under constraint
- Repair Transfer by training variation and recombination
Do not repair “everything at once”. Repair the bottleneck first.
Repair page:
https://edukatesg.com/uld-repair/
Step 6: Verify With Retests (The Falsifiability Rule)
ULD requires verification. Without verification, diagnosis is opinion.
A diagnosis is valid only if it predicts retest outcomes:
- Simplify to confirm Depth effects
- Constrain to confirm Load effects
- Vary to confirm Transfer effects
If retest outcomes do not match, the diagnosis is wrong and must be rerun.
This is how ULD remains watertight.
The ULD Minimal Test (When Time Is Limited)
When you cannot run a full diagnostic, run this minimal sequence:
- One Depth test (explain + reconstruct)
- One Load test (timed / constraint)
- One Transfer test (new format / new context)
This reveals the primary bottleneck in most cases.
Common Protocol Errors (Avoid These)
Error 1: Testing Transfer before Depth
This produces false conclusions and unnecessary confusion.
Error 2: “More practice” without diagnosis
This amplifies drift and increases burnout.
Error 3: Changing content while testing Load
Load requires stable content. Only constraints change.
Error 4: Increasing difficulty to test Transfer
Transfer requires novelty and distribution shift, not harder repetition.
Error 5: No retesting after repair
No verification means no measurement.
Self-Use vs Guided Use
ULD can be self-applied for low-stakes clarity and personal insight. However, guided interpretation is recommended when:
- decisions are high-stakes (exams, certification, promotion)
- repeated failure or plateau has occurred
- multiple axes appear weak
- institutional or training outcomes are affected
Guided use ensures correct sequencing, disciplined verification, and accurate repair targeting.
How ULD Fails Safely When Misused
ULD is designed to degrade conservatively.
When misused, it tends to produce:
- inconsistent results
- unstable bands
- uncertainty rather than false certainty
It does not:
- assign permanent labels
- predict long-term outcomes
- rank human intelligence
This safety characteristic is intentional and protects against over-interpretation.
How ULD Connects to the Rest of eduKateSG
ULD Overview:
https://edukatesg.com/uld/
ULD makes Education OS measurable because it identifies which capability breaks:
https://edukatesg.com/education-os/
ULD makes Vocabulary OS measurable because vocabulary failures also map to Depth, Load, Transfer:
https://edukatesg.com/vocabulary-os/
Next Page
After protocol, you need the repair loop that turns diagnosis into improvement:
https://edukatesg.com/uld-repair