V2.0 Digital Coordination Layer v0.1 — CH/ai Runtime for EducationOS (Live Directories + Scheduling + Repair Routing)

TITLE: V2.0 Digital Coordination Layer v0.1 — CH/ai Runtime for EducationOS (Live Directories + Scheduling + Repair Routing)
SCOPE: CivOS V2.0 (“Digital Coordination of Civilisation”)
VERSION: CivOS Unified Spec v1.x
MODE: Almost-Code / Runtime template / WordPress paste-ready
OWNER: eduKateSG Fence Learning Systems + ChronoHelmAI (CH/ai)
PLACE: SG (canonical), exportable to any PlaceID
ZOOM: Z0–Z6 (runtime indexing)
GOAL: Turn the EducationOS stack into a live coordination runtime:
      - directories/registries become a computable graph
      - CH/ai schedules sensors, repairs, and upgrades
      - FenceOS enforces boundaries to prevent irreversible thresholds
      - outputs are “actions”, not essays
========================================================
0) V2.0 PREMISE (LOCK)
========================================================
V2.0 Claim:
- Once an OS is specified (nodes/edges/sensors/signatures/protocols),
  it can be run as a coordination runtime.
- CH/ai = scheduler + envelope guard + repair router + upgrade sequencer.
- The runtime’s job is to keep learners/schools/systems inside Phase envelope
  by controlling:
  (a) what to do next,
  (b) when to do it,
  (c) what not to do (truncate),
  (d) how to repair (stitch),
  (e) when to widen.
========================================================
1) RUNTIME ID GRAMMAR (ALREADY LOCKED)
========================================================
StableID := Place×Lane×Zoom×Role×Type×ID
Examples (already used):
- SG×ENG×Z0×Learner×Node×ENG-PARA-CORE
- SG×SCI×Z6×Tutor×Sensor×SENS-MR-90
- SG×VL×Z6×Operator×Protocol×PROT-VL-TRACE-ENFORCE
- SG×EDU×Z4×Operator×Panel×SG-NESP-v0.1
Rule:
- IDs never renamed; only version forward.
========================================================
2) DATA MODEL: LIVE DIRECTORY RUNTIME
========================================================
RuntimeEntities:
- Actor := {actor_id, role, place_id, zoom_scope, capacity_hours_per_week}
- Learner := {learner_id, band, current_phase_by_lane, buffers, constraints}
- Task := {task_id, task_type, linked_id, duration_min, due_by, status}
- Observation := {sensor_id, timestamp, metrics, notes}
- Event := {signature_id, triggered_by, severity, timestamp}
- Action := {protocol_id, truncation_steps, stitching_steps, retest_plan, exit_conditions}
Core Stores:
- RegistryStore (static, versioned): Nodes/Edges/Sensors/Signatures/Protocols/Panels/Prompts
- StateStore (dynamic): learner states + cohort states + compliance + buffers
- LogStore (append-only): backtests + deltas + decisions
========================================================
3) CH/ai CORE FUNCTIONS (V2.0)
========================================================
CH/ai := {
  Scheduler,
  EnvelopeGuard,
  RepairRouter,
  UpgradeSequencer,
  CapacityAllocator,
  BacktestLogger
}
3.1 Scheduler:
- schedules weekly packs + retests based on time windows and capacity
3.2 EnvelopeGuard (FenceOS runtime):
- monitors triggers (NIT/NITS/NITA, CompletionRate, TracePresent%)
- selects fence mode: TRUNCATE / STITCH / WIDEN
- blocks unsafe upgrades when exit conditions unmet
3.3 RepairRouter:
- maps signatures → root nodes → protocols
- outputs actions with retest + exit conditions
3.4 UpgradeSequencer:
- chooses the next best node upgrades after stability restored
- prioritises high-coupling edges first (ENG inference, MATH graph meaning, VL trace)
3.5 CapacityAllocator:
- assigns limited tutor hours to highest-impact protocols
- ensures repair load does not exceed repair capacity
3.6 BacktestLogger:
- logs before/after sensors + signature deltas for learning the system
========================================================
4) RUNTIME CONTRACT: INPUT → OUTPUT (NO PROSE DRIFT)
========================================================
Input:
- RegistryPack IDs (static)
- Latest Observations (sensor metrics)
- Active Events (signatures)
- Capacity + constraints (time, stress, tools)
- Goal horizon (weeks)
Output:
- A queue of Tasks for next 7 days:
  - sensor tasks
  - protocol tasks
  - timed mini tasks
  - rest/buffer tasks
- A fence decision (truncate/stitch/widen) with reasons
- A retest plan and exit conditions
- A backtest record template
========================================================
5) CH/ai SCHEDULING ALGORITHM (v0.1)
========================================================
HeuristicPolicy v0.1:
1) Safety first:
   If any NIT/NITS/NITA trigger OR TracePresent% low OR CompletionRate low:
      Mode := TRUNCATE or STITCH
      Run smallest effective repair protocol
2) Stabilise high-coupling edges:
   Priority order (default):
      VL → ENG inference → MATH WP → MATH graph meaning → SCI structured → HUM thesis/CEE
3) Maintain visibility:
   Minimum instrumentation per week:
      - 2 lane sensors + 1 VL micro + 1 timed mini (biweekly)
4) Widen only after exits:
   If exit conditions met for 2 cycles:
      Mode := WIDEN
      Increase variation/load by one step only
========================================================
6) DIGITAL DIRECTORY “LIVE PAGES” (WORDPRESS RUNTIME STYLE)
========================================================
Each live directory page includes:
- Registry blocks (copyable)
- “Run This Now” prompt blocks (PromptRegistry)
- “Weekly Tasks” blocks (Task schema)
- “Log Result” blocks (Backtest schema)
Example Page Types:
- SG×EDU×Z6×Operator×Directory×DIR-REGISTRY-HUB
- SG×EDU×Z1×Parent×Directory×DIR-PARENT-RUNBOOK
- SG×EDU×Z2×Tutor×Directory×DIR-COHORT-OPS
- SG×EDU×Z4×Operator×Directory×DIR-NATION-PANEL
========================================================
7) OUTPUT SCHEMAS (TASK QUEUE + DECISION)
========================================================
7.1 TaskQueue Schema:
[TASK-QUEUE v0.1]
Place: SG
Actor: <Parent/Tutor/Learner>
WeekOf: <YYYY-MM-DD>
Tasks:
- task_id: <...>
  task_type: <SENSOR|PROTOCOL|TIMED_MINI|BUFFER>
  linked_id: <SensorID|ProtocolID|PackID>
  duration_min: <n>
  due_by: <date>
  success_criteria: <metric or pass rule>
  log_to: <BACKTEST-RECORD>
7.2 FenceDecision Schema:
[FENCE-DECISION v0.1]
Mode: <TRUNCATE|STITCH|WIDEN>
Triggers: [<metric threshold>]
Actions: [<ProtocolID...>]
ReTest: [<SensorID + date>]
ExitConditions: [<...>]
========================================================
8) REQUIRED FAILURE TRACE (V2.0)
========================================================
Trace:
registries exist but not runnable →
no schedule →
no enforcement →
repairs late →
cascades.
Repair:
registries + prompts →
CH/ai schedules →
FenceOS enforces →
router repairs →
sequencer upgrades →
backtests refine →
stable flight at scale.
========================================================
9) MINIMUM VIABLE V2 DEPLOYMENT (SG) v0.1
========================================================
MVD-SG v0.1:
- Publish 4 live hubs:
  1) DIR-REGISTRY-HUB (Z6)
  2) DIR-PARENT-RUNBOOK (Z1)
  3) DIR-COHORT-OPS (Z2)
  4) DIR-NATION-PANEL (Z4)
- Enforce weekly packs + VL trace compliance
- Run biweekly exam minis
- Log 1 backtest per learner per 2 weeks
========================================================
END: V2.0 Digital Coordination Layer v0.1
========================================================