SG EducationOS Digital Coordination Spec v0.1 (Z6) — Machine-Readable Registries + Graph IDs + Repair Routing

TITLE: SG EducationOS Digital Coordination Spec v0.1 (Z6) — Machine-Readable Registries + Graph IDs + Repair Routing
VERSION: CivOS Unified Spec v1.x
MODE: Almost-Code / Executable Directory Spec / WordPress paste-ready
OWNER: eduKateSG Fence Learning Systems
PLACE: SG
ZOOM: Z6 (Digital Coordination Layer)
GOAL: Turn Singapore EducationOS into a routable, machine-readable coordination system:
      registries (nodes/edges/sensors/protocols), stable IDs, dashboards, and automated repair routing.
CANONICAL CLAIM:
- Z6 is not “more content.”
- Z6 is making coordination computable: what breaks, where, why, who fixes, what to do next.
========================================================
0) CORE OBJECT MODEL (THE 6 ENTITIES)
========================================================
Entity Types:
E1) Node        (a capability or skill unit)
E2) Edge        (a dependency or coupling)
E3) Sensor      (a measurement / micro-test / metric)
E4) Signature   (a detectable failure pattern)
E5) Protocol    (truncation + stitching repair loop)
E6) Panel       (dashboard output schema)
All Z6 artifacts are stored as registries with stable IDs.
========================================================
1) ID GRAMMAR (LOCKED, FOR ALL Z6 RECORDS)
========================================================
ID := Place×Lane×Zoom×Role×Type×ID
Place: SG
Lane: EDU | MATH | ENG | SCI | HUM | VL | HGW
Zoom: Z0..Z6
Role: Learner | Parent | Tutor | Teacher | Operator | Oracle | Visionary
Type: Node | Edge | Sensor | Signature | Protocol | Panel | Registry | PromptPack
ID: stable string (never rename; version forward only)
Example:
SG×ENG×Z0×Learner×Node×ENG-PARA-CORE
SG×EDU×Z2×Operator×Panel×HGW-COHORT-v0.1
========================================================
2) REGISTRY LAYER (CANONICAL FILES / PAGES)
========================================================
RegistryIndex:
- /sg/z6/registry/                   (hub)
- /sg/z6/registry/nodes/             (NodeRegistry)
- /sg/z6/registry/edges/             (EdgeRegistry)
- /sg/z6/registry/sensors/           (SensorRegistry)
- /sg/z6/registry/signatures/        (SignatureRegistry)
- /sg/z6/registry/protocols/         (ProtocolRegistry)
- /sg/z6/registry/panels/            (PanelRegistry)
- /sg/z6/registry/prompts/           (PromptRegistry)
- /sg/z6/registry/version/           (Unified version log)
Rule:
- Registries are “almost-code tables” (copyable blocks) + minimal prose.
- Each record is machine-readable and linkable.
========================================================
3) NODE REGISTRY RECORD (SCHEMA)
========================================================
NodeRecord := {
  id,
  title,
  lane,
  level_band,              # P1–P6 / Sec1–Sec4/5 / JC1–JC2
  prereq_nodes[],          # list of node ids
  output_nodes[],          # list of node ids
  phase_targets,           # {by_time: P2, excellence: P3}
  transfer_tests[],        # links to Sensor ids
  sensors[],               # sensor ids
  signatures[],            # signature ids (failure patterns)
  repair_protocols[],      # protocol ids
  coupling_edges[],        # edges to other lanes
  fence_rules[],           # stop-loss rules
  tags[]                   # e.g., "core", "prereq", "high-coupling"
}
========================================================
4) EDGE REGISTRY RECORD (SCHEMA)
========================================================
EdgeRecord := {
  id,
  from_node,
  to_node,
  edge_type,              # prereq | coupling | amplification
  weight,                 # VH | H | M | L
  signature_links[],      # which signatures indicate edge is failing
  notes
}
Edge types:
- prereq: within-lane dependencies
- coupling: cross-lane dependencies (ENG→MATH WP)
- amplification: when weakness multiplies under load (AI reliance → plausible-wrong)
========================================================
5) SENSOR REGISTRY RECORD (SCHEMA)
========================================================
SensorRecord := {
  id,
  name,
  lane,
  duration_min,
  input_format,           # what learner submits
  scoring_rules,          # rubric or classification
  metrics_output[],       # e.g., TR, ERC, NIT_w, SII
  phase_mapping_rules,    # how sensor updates P0–P3
  retest_frequency,       # weekly/biweekly
  thresholds,             # triggers
  linked_nodes[],
  linked_signatures[]
}
Core metrics (shared):
- TR  = transfer reliability
- ERC = error repeat count
- SII = speed instability index
- NIT_w / NITS_w / NITA_w = weekly threshold trigger count
- CRS = collapse risk score
========================================================
6) SIGNATURE REGISTRY RECORD (SCHEMA)
========================================================
SignatureRecord := {
  id,
  category,               # coupling | nit | nits | speed | buffer | drift | ai
  severity,               # S1/S2/S3
  markers[],              # observable patterns
  likely_root_cause_nodes[],
  predicted_next_failure_nodes[],
  fence_action,           # truncate/stitch
  required_retest_sensors[],
  notes
}
========================================================
7) PROTOCOL REGISTRY RECORD (SCHEMA)
========================================================
ProtocolRecord := {
  id,
  name,
  trigger_signatures[],
  truncation_steps[],     # stop list
  stitching_steps[],      # repair loop steps
  re_test_plan[],         # sensors + schedule
  exit_conditions,        # when widen again
  linked_nodes[],
  linked_edges[]
}
Rule:
- Every protocol must include an “exit condition” to prevent infinite truncation.
========================================================
8) PANEL REGISTRY RECORD (SCHEMA)
========================================================
PanelRecord := {
  id,
  zoom,                   # Z0/Z1/Z2/Z4
  inputs_required[],       # which registries/metrics feed it
  display_fields[],        # what to show
  alert_rules[],           # stop-loss triggers
  output_format            # strict template block
}
Panels already defined:
- HGW Dashboard v0.1 (Z0–Z2)
- SG Education Stability Panel v0.1 (Z4)
========================================================
9) PROMPT REGISTRY (RUNNABLE AUTOMATION PROMPTS)
========================================================
PromptRecord := {
  id,
  purpose,                # forecast | dashboard | backtest | cohort | routing
  required_inputs[],
  strict_output_schema,
  safety_rules[],
  version
}
Prompts already defined:
- HGW-A / HGW-B / HGW-C / HGW-D
- DASH generation prompt
========================================================
10) ROUTING ENGINE (CH/ai EDUCATION ROUTER v0.1)
========================================================
Router Input:
- learner/cohort metrics (TR, ERC, NIT_w, TTC, BN, volatility)
- active signatures (top 5)
- node registry (prereqs + protocols)
Router Output:
- Top 3 upstream nodes to repair
- Protocol selection (truncate + stitch)
- Weekly plan allocation (minutes per node)
- Re-test schedule
Routing rule (core):
- Repair upstream prerequisite nodes before downstream practice.
- If coupling-edge failing, route to upstream lane repair (e.g., ENG inference → MATH WP).
Pseudo-routing:
1) Detect active signatures (S2/S3 first)
2) Map signatures → root cause nodes
3) Rank nodes by:
   ImpactWeight(edge weights) × Severity × TTC factor × Recurrence
4) Choose protocol(s)
5) Emit plan + retests
========================================================
11) Z6 DEPLOYMENT TEMPLATE (WORDPRESS “ALMOST-CODE” PAGES)
========================================================
Each registry page must include:
A) Definition Lock
B) Record schema block
C) Record list (copyable)
D) Version line:
   UnifiedSpecVersion: v1.x
   RegistryVersion: v0.1
   Updated: YYYY-MM-DD
E) Failure trace + repair trace
Rule:
- No renaming IDs. Only version forward (v0.1 → v0.2).
- Deprecated records remain with status=deprecated, not deleted.
========================================================
12) MINIMUM VIABLE DIGITAL STACK (TO GO LIVE FAST)
========================================================
MVD (v0.1 live set):
- NodeRegistry for MATH/ENG/SCI/HUM (core nodes only)
- EdgeRegistry for core prereqs + 4 key couplings
- SensorRegistry with weekly minimum packs per lane
- SignatureRegistry with top 10 signatures per lane (start with S2/S3)
- ProtocolRegistry with 6 core protocols:
  (1) Emergency Coherence Mode (NIT)
  (2) Emergency Mechanism Mode (NIT-S)
  (3) WP Misread Repair (ENG→MATH)
  (4) Algebra/Graph Repair (MATH→PHY)
  (5) Speed Stability Ladder
  (6) Tool-with-Proof Enforcement (VL-OS)
- PanelRegistry: HGW dashboard + Z4 nation panel
- PromptRegistry: HGW-A/B + DASH prompt
========================================================
13) REQUIRED FAILURE TRACE (Z6)
========================================================
Trace:
No registries →
skills not addressable →
repairs inconsistent →
signals don’t aggregate →
drift hides →
late fencing →
collapse.
Repair:
Stable IDs + registries →
signals comparable →
router can target repairs →
dashboards show drift pockets →
truncation & stitching enforced →
backtests improve rules →
stable flight.
========================================================
END: SG EducationOS Digital Coordination Spec v0.1 (Z6)
========================================================