Skip to content

Home

Jump to bottom
Nawder Loswin edited this page Jan 7, 2026 · 62 revisions

RTT‑Inside: Current State & Living Architecture 🧭📈

Purpose of This Page

This page describes RTT‑Inside as it exists today.

It is not a historical record, a speculative roadmap, or a replacement for the Canon Scroll. Instead, it serves as a living architectural snapshot—a place for readers, developers, operators, and educators to understand:

  • What is stable
  • What is evolving
  • How the system fits together
  • Where to engage safely and productively

If you are new to RTT‑Inside, start here.

What RTT‑Inside Is (Today)

RTT‑Inside is a resonance‑aware execution, validation, observability, and instruction framework.

It treats time, structure, and stability as first‑class operational concepts and enforces correctness through deterministic reference implementations, schema‑validated telemetry, and replay‑driven learning.

Unlike traditional systems where observability is passive, RTT‑Inside is designed so that telemetry teaches, validation enforces alignment, and replay builds mastery.

Architectural Snapshot

RTT‑Inside is intentionally layered. Each layer has a clear contract and a defined role.

Execution Layer

Purpose: Produce deterministic, reference‑aligned behavior.

  • Rust reference engine (canonical truth)
  • Go mirror engine (operational deployment)
  • RTT‑Runner service (scenario execution + emission)

Key properties:

  • Deterministic update rules
  • Segment‑aware execution (v2)
  • Language‑agnostic behavior guarantees

Validation & Conformance Layer

Purpose: Prevent silent drift and enforce alignment.

  • JSON Schemas (v1 and v2)
  • Reference test vectors
  • Node‑based validator CLI (rtt‑validate)
  • CI and runtime enforcement

Key properties:

  • Auto‑detects schema version
  • Validates numeric correctness, not just structure
  • Fails fast on divergence

Observability Ingest Layer

Purpose: Capture telemetry without losing meaning.

  • Grafana Alloy (logs + metrics ingest)
  • Prometheus (metrics)
  • Loki (structured session logs)

Key properties:

  • Stable labels (device, scenario, segment, operator)
  • Numeric fields promoted for fast queries
  • Segment labels treated as first‑class dimensions

Analytics & Visualization Layer

Purpose: Turn telemetry into insight and instruction.

  • Grafana dashboards:
    • Mastery progression
    • Segment‑level anomaly heatmaps
    • Operational health
  • QEB‑oriented curriculum views

Key properties:

  • Operator‑aware analytics
  • Segment‑scoped views
  • Severity‑weighted anomaly visualization

Replay & Instruction Layer

Purpose: Enable learning, review, and mastery.

  • Replay APIs (session index, segment metadata)
  • Server‑Sent Events (time‑accurate streaming)
  • Web replay UI (timeline, overlays, controls)

Key properties:

  • Segment‑aware navigation
  • Anomaly overlays
  • Instructor‑ready review workflows

Curriculum & Mastery Layer

Purpose: Formalize skill progression.

  • Operator identity (URN‑based)
  • Mastery ladder (numeric 0–30)
  • Anomaly taxonomy (typed + severity‑graded)
  • Promotion algorithm (score, anomaly, complexity aware)

Key properties:

  • Resistant to gaming
  • Slows naturally at higher mastery
  • Maps anomalies directly to training drills

Canon vs Living vs Experimental

RTT‑Inside distinguishes between what is stable and what is evolving.

Category Meaning Examples
Canon Stable, authoritative Canon Scroll, Codex
Living Actively evolving Education ladder, dashboards
Experimental Exploratory Game previews, domain pilots

This distinction is intentional and helps contributors engage responsibly.

How to Engage

Readers

  • Start with Resonance‑Time Theory
  • Then read the Canon Scroll
  • Use this page to orient yourself

Developers

  • Explore the reference implementations
  • Run the validator locally
  • Treat schemas as contracts, not suggestions

Operators & Educators

  • Use dashboards to observe progression
  • Use replay to diagnose and teach
  • Treat anomalies as instructional signals

Researchers

  • Engage with paradoxes and metaphysics
  • Propose extensions through structured experiments
  • Preserve alignment with canonical invariants

What’s Next (Near Horizon)

RTT‑Inside continues to evolve deliberately. Near‑term focus areas include:

  • Refinement of mastery promotion models
  • Expanded curriculum mappings
  • Additional replay overlays and visualizations
  • Domain‑specific anomaly extensions
  • Improved onboarding and documentation

Nothing here requires architectural change—only extension.

Design Intent

RTT‑Inside is built so that:

  • Correctness is enforced by infrastructure
  • Observability teaches, not just reports
  • Replay is a first‑class capability
  • Mastery is measurable and explainable
  • Extensions do not break alignment

This is not a monitoring system with training added later.
It is a training‑capable system by design.

A Note to Contributors

You are encouraged to fork, remix, and extend RTT‑Inside.

Respect the contracts. Preserve the invariants.
Everything else is open to exploration.

This page is living. When the system changes meaningfully, this page should change with it.

If you’d like, I can next:

  • add inline links to existing Wiki pages
  • generate a Mermaid architecture diagram to pair with this page
  • or draft a short “Start Here” banner for the Wiki home

Clone this wiki locally