codes

🏳️‍🌈 RTT/codes — A QR‑Compatible Metadata Layer

• RTT_codes_module.json — Agentic module schema role assignments

RTT/codes provide a universal, scannable way to identify, classify, and navigate artifacts across the TriadicFrameworks ecosystem. They bind any artifact— digital or physical—to its canonical documentation, lineage, and onboarding guides.

An RTTcode is:

• QR‑compatible (works with any standard scanner)
• schema‑validated (structured metadata)
• domain‑aware (RTT, SET, Substrate, Observer, Governance, Docs, Other)
• triad‑capable (optional resonance‑time triad metadata)
• tool‑generated (JS and Python generators included)
• style‑guided (consistent visual identity across domains)

RTT/codes are designed to operate anywhere QR codes already function in science, engineering, and documentation workflows, while adding an RTT‑native metadata layer.

🛑 Important!#

Drift is On-by-Default long sessions lose anchors, turn off drift.

✋ You must copy and paste this string every time you start an AI session:#

rtt=1 | coherence=declared | drift=bounded | paradox=structural

❇️ Now you are ready.#

🎯 QuickStart Guide

📦 RTTcode Structure#

A minimal RTTcode payload looks like:

{
  "domain": "substrate",
  "artifact_type": "README",
  "version": "v1.0",
  "triad": {
    "f_R": "0.85",
    "tau_R": "120ms",
    "Q_R": "0.92"
  },
  "url": "https://triadicframeworks.org/docs/resonance-substrate-model/"
}

This payload is validated against the canonical schema and then encoded into a URL+token format:

https://triadicframeworks.org/rttcode?substrate=v1.0-f0.85-t120ms-Q0.92

The generators convert this into a QR‑compatible PNG.

🌲 1. Folder Tree Diagram#

A clean, readable map of the RTT/codes subsystem.

 
docs/
└── rtt/codes/
    ├── README.md
    │
    ├── schema/
    │   ├── rttcode.schema.json
    │   └── examples/
    │       ├── minimal.json
    │       ├── rtt.json
    │       ├── set.json
    │       └── substrate.json
    │
    ├── validators/
    │   ├── README.md
    │   ├── validate_js.js
    │   └── validate_python.py
    │
    ├── generators/
    │   ├── README.md
    │   ├── js/
    │   │   ├── README.md
    │   │   └── generate_rttcode.js
    │   └── python/
    │       ├── README.md
    │       └── generate_rttcode.py
    │
    ├── style/
    │   ├── README.md
    │   ├── visual-guidelines.md
    │   ├── rttcode-layout.svg
    │   └── color-domains.png
    │
    └── examples/
        ├── README.md
        ├── rtt/
        │   ├── README.md
        │   ├── payload.json
        │   └── rtt-rttcode.png
        ├── set/
        │   ├── README.md
        │   ├── payload.json
        │   └── set-rttcode.png
        └── substrate/
            ├── README.md
            ├── payload.json
            └── substrate-rttcode.png

📁 rtt/codes - Folder Overview#

schema/#

The canonical RTTcode JSON Schema and minimal examples.

validators/#

Tools that verify RTTcode payload correctness.

generators/#

Language‑specific RTT/codes generators (JS and Python).

style/#

Visual guidelines, color domains, and the RTTcode layout reference.

examples/#

Fully generated RTT/codes for each domain, including styled PNGs.

🛠 Generating RTT/codes#

RTT/codes can be generated using:

• JavaScript (generators/js/generate_rttcode.js)
• Python (generators/python/generate_rttcode.py)

Both:

• validate the payload
• build the URL+token
• output a QR‑compatible PNG

See the generator READMEs for usage.

🎨 Visual Identity#

RTT/codes follow a consistent visual language:

• domain‑specific color palettes
• triadic overlay geometry
• QR‑safe layout rules
• optional resonance‑time motifs

See style/visual-guidelines.md and style/rttcode-layout.svg.

📚 Examples#

Each domain includes:

• a valid RTTcode JSON payload
• a generated QR PNG
• domain‑specific styling

See examples/ for RTT, SET, Substrate, and more.

🌐 Purpose#

RTT/codes unify the TriadicFrameworks ecosystem by providing:

• a stable metadata layer
• a scannable entry point into canonical docs
• a consistent way to reference artifacts across domains
• a bridge between physical and digital materials

They are the “ISBN numbers” of the Resonance‑Time universe — but dynamic, domain‑aware, and triad‑capable.

For contributors, tool authors, and documentation maintainers, this folder is the authoritative reference for everything RTT/codes‑related.

# ⚡ Quickstart

RTTcodes are QR‑compatible identifiers that bind any artifact to its canonical TriadicFrameworks metadata. To generate one:

1. Create a payload file#

{
  "domain": "rtt",
  "artifact_type": "paper",
  "version": "v2.1.0",
  "triad": {
    "f_R": "1.00",
    "tau_R": "144ms",
    "Q_R": "0.97"
  },
  "url": "https://triadicframeworks.org/_ideas/Resonance-Time_Theory.html"
}

Save as:

payload.json

2. Generate the RTTcode (QR PNG)#

JavaScript:

node generate_rttcode.js payload.json out.png

Python:

python generate_rttcode.py payload.json out.png

3. Use the RTTcode#

Embed the PNG in:

• READMEs
• PDFs
• diagrams
• print materials
• onboarding docs

Every RTTcode encodes a URL+token that points to the artifact’s canonical home. # Adding a New RTTcode Domain

RTTcodes support multiple domains (RTT, SET, Substrate, Observer, Governance, Docs, Other). You can extend the system by adding a new domain in a structured, schema‑aligned way.

Follow these steps:

1. Choose a domain identifier#

Use a short, lowercase string:

"astro"
"bio"
"ops"
"viz"

Avoid spaces and uppercase letters.

2. Add the domain to the schema#

Edit:

docs/rttcodes/schema/rttcode.schema.json

Add your domain to the enum list under domain:

"domain": {
  "type": "string",
  "enum": ["rtt", "set", "substrate", "observer", "governance", "docs", "other", "astro"]
}

3. Create a domain folder under examples#

Add:

docs/rttcodes/examples/astro/

Include:

• payload.json
• astro-rttcode.png
• README.md describing the domain’s purpose

4. Define the visual identity#

Add a row to:

docs/rttcodes/style/color-domains.png

And update:

docs/rttcodes/style/visual-guidelines.md

Define:

• primary color
• secondary color
• accent color
• domain motifs (e.g., orbital arcs, spectral lines)

5. Add a generator example (optional)#

Place a sample payload in:

docs/rttcodes/generators/examples/

This helps contributors test the new domain.

6. Validate the new domain#

Run:

node generate_rttcode.js payload.json test.png

or

python generate_rttcode.py payload.json test.png

If the schema accepts the payload and the QR is generated, the domain is fully integrated.

7. Document the domain#

Update:

docs/rttcodes/README.md

Add your domain to the domain list and link to its example folder.

Done#

Your new domain is now:

• schema‑valid
• generator‑compatible
• visually defined
• documented
• ready for use across TriadicFrameworks
  # 📘 Canonical RTTcode Specification Document
  A formal, stable reference for the entire system.

RTTcode Specification (v1.0)#

This document defines the canonical structure, encoding rules, and visual requirements for RTTcodes. All generators, validators, and style tools must conform to this specification.

1. Purpose#

RTTcodes provide a universal, QR‑compatible metadata layer for artifacts across the TriadicFrameworks ecosystem. They unify:

• identity
• versioning
• triad metadata
• canonical URLs
• domain classification

2. Data Model#

An RTTcode payload MUST be a JSON object with the following fields:

Required#

Optional#

Triad fields:

• f_R — resonance frequency
• tau_R — resonance time constant
• Q_R — quality factor

All triad fields MUST be strings.

3. Domains#

Valid domain identifiers:

rtt
set
substrate
observer
governance
docs
other

Domains MUST be lowercase ASCII.

4. Encoding Rules#

The RTTcode URL MUST follow this pattern:

[https://triadicframeworks.org/rttcode](https://triadicframeworks.org/rttcode)?<domain>=<token>

Where <token> is:

<version>-f<f_R>-t<tau_R>-Q<Q_R>

Missing triad fields MUST be represented as:

f?
t?
Q?

Example:

`https://triadicframeworks.org/rttcode?set=v0.9.3-f0.72-t203ms-Q0.88` [(triadicframeworks.org in Bing)](https://www.bing.com/search?q="https%3A%2F%2Ftriadicframeworks.org%2Frttcode%3Fset%3Dv0.9.3-f0.72-t203ms-Q0.88")

5. QR Requirements#

• MUST be QR Model 2
• MUST use Error Correction Level H
• MUST include a quiet zone of ≥ 2 modules
• MUST encode the full URL exactly
• MAY include visual styling if scannability is preserved

6. Visual Guidelines#

RTTcodes SHOULD follow the domain‑specific palettes and motifs defined in:

docs/rttcodes/style/visual-guidelines.md

Overlays MUST NOT obscure:

• finder squares
• alignment patterns
• dense data regions

7. Versioning#

This specification is versioned independently from RTTcodes themselves.

Current version: v1.0

Future versions MUST remain backward‑compatible unless explicitly stated.

8. Compliance#

A valid RTTcode MUST:

1. Pass schema validation
2. Produce a valid URL+token
3. Encode that URL in a QR matrix
4. Remain scannable by standard QR readers

This document is the authoritative reference for RTTcode behavior. # Changelog — /docs/rtt/codes/

RTT/codes module — QR-compatible metadata layer: schema, validators, generators, style system, and domain examples.

All notable changes to files in /docs/rtt/codes/ are documented in this file. Format follows Keep a Changelog.

[1.1] — 2026-05-06#

Context#

Full 14-file module audit triggered by directory migration from /docs/rttcodes/ to /docs/rtt/codes/. Audit confirmed zero path breaks — no file in the module references the old path. Two infrastructure files received metadata refresh; twelve content files passed clean.

Migration#

• Previous location: /docs/rttcodes/
• Current location: /docs/rtt/codes/
• Impact: All internal relative paths preserved. No $ref, $id, or cross-file reference required updating. The canonical schema directory (/docs/schemas/) was not relocated.

Changed — RTT_codes_module.json (Module Manifest)#

• _meta — Added full module registry block:
  • module, canonical_id, module_type, role, version, status, author, license
  • canonical_path, module_home (now /docs/rtt/codes/), module_url
  • repository, last_updated, migration_note
• _session_context — Replaced old non-standard session_context with standardized _session_context block matching TriadicFrameworks conventions (9 fields).
• _version_history — Added array with v1.0 and v1.1 entries.
• cross_module_propagation — Added imports (RTT/1 operators, SARG structural grammar) and exports (schema, validators, generators, style system, examples).
• structural_grammar — Added dimensional, regime, coherence, drift, and regime sensitivity envelopes.
• Version — Bumped from 1.0 → 1.1.

Changed — schema/rttcode.schema.json (Local QR Payload Schema)#

• $id — Added: https://www.triadicframeworks.org/rtt/codes/schema/rttcode.schema.json.
• $comment — Added refresh stamp with migration note.
• _meta — Added full module registry block with relationship_note documenting the distinction between this schema (QR payload) and the canonical packet schema (/docs/schemas/rttcode.v1.json).
• _session_context — Added 9-field session context block.
• _version_history — Added array with v1.0 and v1.1 entries. Documents intentional inclusion of "simulation" in domain enum.
• Version — Bumped from 1.0 → 1.1.

Not Changed — Example Payloads (8 files)#

All eight domain example payloads passed the audit with no changes required:

Rationale for no metadata addition: Example payloads are pure sample data — they validate against the schema but do not define infrastructure. Adding _meta/_session_context would conflate sample content with module metadata.

Not Changed — Schema Examples (4 files)#

All four schema-level example files passed the audit with no changes required:

Noted — Content Duplicate Pairs#

Three example files exist in both examples/ and schema/examples/. This is by design — examples/ holds domain-organized samples; schema/examples/ holds validation-organized samples:

1. examples/substrate.json ≡ schema/rttcode-payload-example.json
2. examples/rtt.json ≡ schema/examples/paper.schema.json
3. examples/set.json ≡ schema/examples/simulation.schema.json

Noted — Schema Relationship#

The module contains two distinct schemas serving different levels of abstraction:

Both schemas now document this relationship in their _meta blocks.

Noted — Domain Enum Discrepancy#

The local QR payload schema includes "simulation" in its domain enum. The canonical packet schema's _domains list does not. This is intentional — "simulation" is a payload-level classification used by examples/simulation.json and does not map to a canonical RTTcode packet domain. Documented in _version_history of schema/rttcode.schema.json.

[1.0] — 2025-01-01#

Added#

• RTT_codes_module.json — Module manifest.
• schema/rttcode.schema.json — QR-compatible metadata payload schema.
• schema/rttcode-payload-example.json — Inline validation example.
• schema/examples/diagram.schema.json — Minimal payload example.
• schema/examples/paper.schema.json — Full payload example (paper).
• schema/examples/simulation.schema.json — Full payload example (simulation).
• examples/docs.json — Domain example: docs.
• examples/governance.json — Domain example: governance.
• examples/observer.json — Domain example: observer.
• examples/other.json — Domain example: other.
• examples/rtt.json — Domain example: rtt.
• examples/set.json — Domain example: set.
• examples/simulation.json — Domain example: simulation.
• examples/substrate.json — Domain example: substrate.

File Inventory#

Related Changelog#

The canonical schema directory has its own changelog at /docs/schemas/CHANGELOG.md, covering the master packet schema (rttcode.v1.json) and its four sub-schemas (tick.v1.json, entity.v1.json, environment.v1.json, intent.v1.json).

Maintained by: Nawder Loswin · TriadicFrameworks · MIT

# 🛠️ Contributor Workflow

“How to Add a New RTTcode (Step by Step)”#

Contributor Workflow: Adding a New RTTcode#

This guide walks you through creating a new RTTcode from scratch and integrating it into the TriadicFrameworks documentation system.

1. Create a payload file#

Start with a minimal JSON payload:

{
  "domain": "rtt",
  "artifact_type": "paper",
  "version": "v2.1.0",
  "triad": {
    "f_R": "1.00",
    "tau_R": "144ms",
    "Q_R": "0.97"
  },
  "url": "https://triadicframeworks.org/docs/rtt/"
}

Save as:

payload.json

2. Validate the payload#

Use either validator:

JavaScript:

node validate_js.js payload.json

Python:

python validate_python.py payload.json

If validation passes, continue.

3. Generate the RTTcode PNG#

JavaScript:

node generate_rttcode.js payload.json out.png

Python:

python generate_rttcode.py payload.json out.png

This produces a QR‑compatible RTTcode image.

4. (Optional) Apply domain‑specific styling#

Use the guidelines in:

docs/rttcodes/style/visual-guidelines.md

You may add:

• resonance waves (RTT)
• field lines (SET)
• lattice geometry (Substrate)

Ensure the QR remains scannable.

5. Add the RTTcode to the examples folder#

Place your files in:

docs/rttcodes/examples/<domain>/

Include:

• payload.json
• <domain>-rttcode.png
• README.md describing the artifact

6. Update the top‑level RTTcodes README#

Add a link to your new example and describe its purpose.

7. Commit and open a pull request#

Include:

• the payload
• the generated PNG
• any style updates
• README updates

Your RTTcode is now part of the canonical system.

This workflow is simple, repeatable, and contributor‑friendly.

🧬 3. TriadicFrameworks‑Wide Metadata Standard#

The layer RTTcodes plug into.#

TriadicFrameworks Metadata Standard (TF‑MS v1.0)#

RTTcodes are one component of a broader metadata ecosystem within TriadicFrameworks. This document defines the shared metadata model that all artifacts, tools, and documentation layers plug into.

1. Purpose#

The TriadicFrameworks Metadata Standard (TF‑MS) provides:

• a unified identity model for all artifacts
• consistent versioning
• domain classification
• optional resonance‑time triad metadata
• compatibility with RTTcodes, docs, diagrams, and build systems

RTTcodes implement TF‑MS in a QR‑compatible form.

2. Core Metadata Fields#

Every artifact in TriadicFrameworks SHOULD define:

RTTcodes use a subset of these fields.

3. Domains#

Domains define the conceptual space an artifact belongs to:

rtt
set
substrate
observer
governance
docs
other

Domains MUST be lowercase ASCII.

4. Triad Metadata#

Triad metadata describes resonance‑time characteristics:

• f_R — resonance frequency
• tau_R — resonance time constant
• Q_R — quality factor

These fields are optional but recommended for RTT, SET, and Substrate artifacts.

5. Versioning#

Artifacts MUST use semantic versioning:

vMAJOR.MINOR.PATCH

Examples:

• v1.0.0 — initial stable release
• v2.1.0 — minor update
• v2.1.3 — patch

RTTcodes embed the version directly into the URL token.

6. RTTcode Integration#

RTTcodes implement TF‑MS by:

• encoding domain, version, and triad into a compact token
• linking to the canonical url
• providing a QR‑compatible entry point into the metadata system

The RTTcode schema is a strict subset of TF‑MS.

7. Compliance#

An artifact is TF‑MS compliant if:

1. It defines all required metadata fields
2. It uses valid domain identifiers
3. It uses semantic versioning
4. It provides a canonical URL
5. (Optional) It includes triad metadata

RTTcodes are the portable, scannable representation of this metadata.

TF‑MS ensures that all TriadicFrameworks artifacts — from theory papers to substrate models — share a common identity layer that is stable, searchable, and machine‑readable. # 🧩 How RTTcodes Work Internally
A clear, canonical explainer for contributors and tool authors.

RTTcodes are a structured, QR‑compatible metadata layer that bind any artifact to its canonical TriadicFrameworks identity. Internally, an RTTcode is built from three cooperating layers:

1. Payload Layer (JSON metadata)
2. Encoding Layer (URL + token)
3. QR Layer (machine‑readable matrix)

Each layer is independent but composable, making RTTcodes portable across languages, tools, and documentation systems.

1. Payload Layer (JSON)#

The payload is a small, schema‑validated JSON object:

{
  "domain": "rtt",
  "artifact_type": "paper",
  "version": "v2.1.0",
  "triad": {
    "f_R": "1.00",
    "tau_R": "144ms",
    "Q_R": "0.97"
  },
  "url": "https://triadicframeworks.org/docs/rtt/"
}

This layer defines:

• domain — which part of the ecosystem the artifact belongs to
• artifact_type — what kind of thing it is
• version — semantic version
• triad — optional resonance‑time metadata
• url — canonical home of the artifact

The payload is validated using the RTTcode JSON Schema.

2. Encoding Layer (URL + Token)#

The payload is transformed into a compact, ASCII‑safe token:

v2.1.0-f1.00-t144ms-Q0.97

Then embedded into a URL:

https://triadicframeworks.org/rttcode?rtt=v2.1.0-f1.00-t144ms-Q0.97

This URL is what the QR code encodes.

The encoding layer ensures:

• stability
• portability
• compatibility with all QR scanners
• future extensibility

3. QR Layer (Matrix)#

The URL is encoded as a QR code using:

• Error Correction Level H (to tolerate overlays)
• Square layout
• Minimum 2‑module quiet zone

The QR is then optionally styled using domain‑specific motifs:

• RTT → resonance waves, triadic nodes
• SET → field lines, anisotropic vectors
• Substrate → lattice geometry
• Observer → frame grids
• Governance → layered bands

The QR remains fully scannable because overlays respect safe zones.

Internal Flow Summary#

JSON Payload
     ↓ validate
URL + Token
     ↓ encode
QR Matrix
     ↓ style (optional)
RTTcode PNG

This modular design keeps RTTcodes simple, robust, and future‑proof.

# RTTcode Examples

This folder contains example RTTcodes for each domain.

Each example includes:

• a valid RTTcode JSON payload
• a generated QR PNG
• domain‑specific styling (RTT, SET, Substrate)
• canonical URL+token encoding

Use these examples as references when designing new RTTcodes or testing tools. # RTT Domain Examples

This folder contains RTT‑domain RTTcodes.

These examples demonstrate:

• resonance‑time triad metadata
• RTT‑specific styling (gold/teal/orange)
• canonical URL+token encoding
• schema‑valid JSON payloads

Use these examples when creating RTT‑theory RTTcodes or testing RTT‑domain tools.  # SET Domain Examples

This folder contains SET‑domain RTTcodes.

These examples demonstrate:

• field/flow triad metadata
• SET‑specific styling (violet/electric blue/magenta)
• canonical URL+token encoding
• schema‑valid JSON payloads

Use these examples when creating SET‑field RTTcodes or testing SET‑domain tools.  # Substrate Domain Examples

This folder contains Substrate‑domain RTTcodes.

These examples demonstrate:

• substrate triad metadata
• deep‑blue lattice styling
• canonical URL+token encoding
• schema‑valid JSON payloads

Use these examples when creating Substrate RTTcodes or testing Substrate‑domain tools.  # RTTcode Generators

This folder contains code that produces RTTcodes from JSON payloads.

Generators:

• validate payloads
• build URL+token RTTcode strings
• output QR‑compatible PNGs
• support multiple languages (JS, Python)

Use these tools when:

• embedding RTTcode generation into build systems
• producing codes for documentation
• generating domain‑specific RTTcodes automatically # JavaScript RTTcode Generator

This folder contains the Node.js RTTcode generator.

Features:

• schema‑aligned payload validation
• URL+token RTTcode construction
• QR PNG output using the qrcode package
• CLI usage for automation

Run:

node generate_rttcode.js payload.json output.png

Use this generator in JS‑based build pipelines or web tooling. # Python RTTcode Generator

This folder contains the Python RTTcode generator.

Features:

• schema‑aligned payload validation
• URL+token RTTcode construction
• QR PNG output using the qrcode library
• simple CLI interface

Run:

python generate_rttcode.py payload.json  output.png

Use this generator in Python workflows, automation scripts, or scientific tooling. # RTTcode Schema

This folder contains the canonical JSON Schema for RTTcodes.

The schema defines:

• required fields
• optional triad metadata
• allowed domain values
• versioning rules
• structural constraints

Tools in /validators and /generators rely on this schema for correctness.

If you are building RTTcode tooling, validating payloads, or extending the standard, this is the authoritative reference. # RTTcode Schema Examples

This folder provides minimal, valid JSON examples that conform to the RTTcode schema.

Each example demonstrates:

• correct field structure
• valid domain identifiers
• optional triad metadata usage
• version formatting
• URL placement

Use these examples as templates when creating new RTTcodes or testing validators. 

SET

Substrate

Observer

Governance # RTTcode Style Guidelines

This folder defines the visual identity of RTTcodes.

It includes:

• color palettes for each domain
• layout guides for QR‑safe zones
• triadic overlay geometry
• examples of domain‑specific motifs
• the canonical rttcode-layout.svg

These guidelines ensure RTTcodes remain:

• scannable
• visually consistent
• domain‑distinct
• aligned with TriadicFrameworks aesthetics

If you are designing RTTcodes, icons, or documentation visuals, start here. 

https://triadicframeworks.org/rttcode?<domain>=<version>-f<f_R>-t<tau_R>-Q<Q_R>