>[!warning]
>This content has not been peer reviewed.
# How we do applications
This document describes how RST applications are structured, coded, and documented so that **everything is documented relationally**: each piece links to the core theory, to the general engine, and to the other pieces of the same application.
**Tone of voice:** Application notes (and Code/Results notes) use **neutral, descriptive language** throughout the vault. Avoid first-person plural ("we", "our"); prefer passive or third-person ("the pipeline", "the script", "the framework"). This keeps the vault consistent and readable as reference documentation.
---
## 1. Goal: document everything relationally
The applied folder is intended as a **relational graph**:
- Every application **links up** to the core theory (axioms, Resource Triangle, Fidelity, Symbol Index).
- Every application **links across** to its own Code and Results.
- The **Applications Roadmap** is the hub: one place to see all applications and how they connect.
- Scripts **plug into the general engine** (same maths as core theory) so that applications are instances of one framework, not ad-hoc scripts.
So: one theory, one engine, many applications; each application is a node with clear relations to theory, code, and results.
---
## 2. Folder and file structure per application
### 2.1 Where things go: knowledge vs foundation vs further applications
**Knowledge content is restricted to established results.** Content is split by role:
| Layer | Location | What belongs there | Scripts |
|:---|:---|:---|:---|
| **Knowledge** | **`expanded theory/knowledge/`** (not under *applied*) | **Established results only** — peer-reviewed facts (Landauer, Bekenstein, Shannon, Planck scale, etc.). Each note states the result and cites sources; "How RST uses it" is the RST mapping. No speculative or invented "facts". | Scripts that **illustrate established math** (e.g. Planck units, Bekenstein bit density) sit in **`expanded theory/knowledge/`** next to the corresponding knowledge note. |
| **Foundation** | **`expanded theory applied/foundation/`** | **14 foundation topics**; the first 10 are the core building blocks (maths/physics needed to map any problem into RRT/RST). One folder per topic. | **`foundation/<Topic>/rst_*.py`** — script in that topic's folder. |
| **Further applications** | **`expanded theory applied/further applications/`** | **Concrete applications** — Millennium problems, total-ontology pillars (Solomonoff, Friston, Bejan, QEC), Grand Map (complexity scale), homeostasis, etc. The **Reality Engine** (ledger implementation) also lives here. One folder per application. | **`further applications/<ApplicationName>/rst_*.py`** — script in that application's folder. |
**Rule: scripts sit in the corresponding folder.** A script that illustrates a **foundation** topic lives in `foundation/<Topic>/`. A script that illustrates a **further application** lives in `further applications/<ApplicationName>/`. A script that only illustrates **established math** (e.g. computing Planck units from constants) lives in `expanded theory/knowledge/`. A further-application script is not placed in the knowledge folder, nor a foundation script in a further-app folder.
### 2.2 Folder layout: foundation vs further applications
- **Foundational** applications (the 10 maths/physics building blocks) live under **`foundation/`**. Example: `foundation/Information and Entropy/`.
- **All other** applications (Millennium problems, total ontology, Grand Map, chemistry, biology, physics/cosmology) live under **`further applications/`**, at the same level as `foundation/`. Examples: `further applications/Navier-Stokes Smoothness/`, `further applications/Grand Map/`, `further applications/Homeostasis/`.
So:
```
expanded theory applied/
Applications Roadmap.md ← Roadmap; links to every application (alias: Index)
How we do applications.md ← This guide
foundation/ ← Foundational building blocks (priority 1–10)
<FoundationalTopic>/ ← e.g. Information and Entropy
<Topic> (RST).md, rst_*.py, * - Code.md, * Results.md, *.png
further applications/ ← Millennium, total ontology, Grand Map, etc. (one folder per app)
<ApplicationName>/ ← e.g. Navier-Stokes Smoothness, Grand Map, Homeostasis
<ApplicationName> (RST).md
rst_*.py, * - Code.md, * Results.md, *.png
```
Scripts under **`foundation/<Topic>/`** and under **`further applications/<ApplicationName>/`** both use **three** levels up (`"..", "..", ".."`) to reach the workspace root (for `rst_engine`). Scripts under **`expanded theory/knowledge/`** use **two** levels up to reach the workspace root.
### 2.3 Per-application contents
Each application subfolder (whether under `foundation/` or `further applications/`) contains:
```
<ApplicationName> (RST).md ← Main application note (problem + RST reframe)
rst_<short_name>_<suffix>.py ← Python script (plugs into engine)
<ShortName> <Suffix> - Code.md ← Documents the script + embedded logic
<ShortName> <Suffix> Results.md ← What the script produced (figures, tables)
<output>.png ← Images produced by the script (optional)
```
**Naming:**
- Subfolder: short, readable (e.g. `Navier-Stokes Smoothness`, `BSD Conjecture`).
- Application note: `"<ApplicationName> (RST).md"` so the note is easy to find and link (e.g. `[[Navier-Stokes Smoothness (RST)]]`, `[[BSD Conjecture (RST)]]`).
- Script: `rst_<topic>_<role>.py` (e.g. `rst_navier_stokes_regulator.py`, `rst_bsd_solver.py`).
- Code note: `"<ShortName> <Suffix> - Code.md"` (e.g. `Navier-Stokes Regulator - Code.md`, `BSD Solver - Code.md`).
- Results note: `"<ShortName> <Suffix> Results.md"` (e.g. `Navier-Stokes Regulator Results.md`, `BSD Solver Results.md`).
**Paths for further applications:** Notes under `further applications/<ApplicationName>/` use `../../Applications Roadmap` for parent/related links (two levels up to `expanded theory applied/`). Scripts there use **three** levels up (`"..", "..", ".."`) to reach the workspace root for `rst_engine`.
---
## 3. The general engine — one implementation, scripts plug in
### Engine system
There are **two engines**:
| Engine | Location | Role |
|:---|:---|:---|
| **Fidelity engine** | `rst_engine/` at workspace root | $\mu(\eta,n)$, Resource Triangle, ledger; used by Navier–Stokes, BSD, MOND, SPARC, etc. |
| **Graph engine** | `rst_axiom_pure.py` in **Micro-Graph Generator** | Pure Axiom Substrate: parameter-free graph evolution; derives $n$, $d_B$; exports `run_cycle`, `omega_tot`, `neighbor_dict`, `protected_edges`. Used by **Nuclear Fusion** (Periodic Table), **Derivation Chain**. |
**Fidelity engine:** The **`rst_engine/`** package at the **workspace root** (the folder that contains `expanded theory`, `expanded theory applied`, and `rst_engine`).
**Layout:**
```
<workspace root>/
rst_engine/ ← Python engine (single implementation)
__init__.py ← Package entry; re-exports API
core.py ← Fidelity, Triangle, source helpers, solve_omega
README.md ← Engine system and how to plug in
expanded theory/
expanded theory applied/
```
There is **one** implementation of the core maths. All calculation scripts **plug into this package**; they do not redefine the engine. The **SPARC evaluation** layer (`expanded theory/sparc evaluation/rawt/interpolation.py`) also imports `mu_rst` and `solve_omega` from `rst_engine`, so applications and evaluation share the same core.
**Engine API (in `rst_engine`):**
- **Fidelity:** $\mu(\eta,n) = \eta/(1+\eta^n)^{1/n}$ → `mu_rst(eta, n)`
- **Resource Triangle:** $W = (\Omega^n + N^n)^{1/n}$ → `triangle_W(Omega, N, n)`
- **Source from triangle:** $I = \Omega^2/W$ → `source_from_triangle(Omega, N, n)`
- **Source from field equation:** $I = \Omega\cdot\mu(\Omega/N)$ → `source_from_rst(Omega, N, n)`
- **Solve for $\Omega$ given $I$, $N$:** → `solve_omega(I, N, n)`
Default $n \approx 1.24$ (derived; SPARC $1.25 \pm 0.05$ confirms); applications can pass a different $n$ (e.g. $4/3$ for Navier–Stokes) when appropriate.
**How scripts plug in:**
At the top of each script that uses the engine, add the **workspace root** to `sys.path` so that the `rst_engine` **package** is importable, then import:
```python
import os
import sys
_SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__))
_ROOT = os.path.abspath(os.path.join(_SCRIPT_DIR, "..", "..")) # 2 levels for expanded theory/...; use one more ".." for foundation/ or further applications/
sys.path.insert(0, _ROOT)
from rst_engine import mu_rst, triangle_W, source_from_triangle, source_from_rst, solve_omega
```
- Scripts in **`expanded theory/python calculations/`** use two levels up (`"..", ".."`) to reach the root.
- Scripts in **`expanded theory applied/foundation/<Topic>/`** (e.g. Information and Entropy) use **three** levels up (`"..", "..", ".."`) to reach the root.
- Scripts in **`expanded theory applied/further applications/<ApplicationName>/`** (e.g. Navier-Stokes, BSD, Homeostasis) use **three** levels up (`"..", "..", ".."`) to reach the root.
- **`expanded theory/sparc evaluation/rawt/interpolation.py`** (SPARC evaluation) uses **three** levels up from `rawt/` to reach the root and imports `mu_rst`, `solve_omega` from `rst_engine`.
**Each application script should:**
1. **Import from `rst_engine`** (do not redefine `mu_rst` / `triangle_W` in the script).
2. **Map the problem** into the same variables (signal, noise, request) and call the engine with problem-specific inputs.
3. **Produce outputs** (figures, tables) that illustrate the RST reading.
So: **one engine, one package** — all scripts resolve and stay in sync. See `rst_engine/README.md` for a short description of the engine system.
---
## 4. Code: script and Code note
### 4.1 Python script
- **Location:** Inside the application subfolder (e.g. `Navier-Stokes Smoothness/rst_navier_stokes_regulator.py`).
- **Outputs:** Prefer writing figures (and logs, if any) into the **same subfolder** so the application is self-contained. Example: `OUT_DIR = SCRIPT_DIR`, then `plt.savefig(os.path.join(OUT_DIR, "navier_stokes_regulator.png"))`.
- **Docstring:** One short paragraph: what problem, what RST idea, what the script does (e.g. “Applies the RST fidelity function to a vortex; classical blow-up vs regulated output”).
- **Parameters:** Use the same $n$ as in the core theory when appropriate (e.g. 1.25), or document why a different value (e.g. 4/3 for Navier–Stokes turbulence) is used.
### 4.2 Code note (`* - Code.md`)
- **Purpose:** Explain the **calculation logic** and how it uses the engine; provide **embedded code** so the logic is readable without running the script.
- **Sections to include:**
- **Purpose** — what classical problem is being reframed and what the script shows.
- **Engine** — which formulae from the core theory are used (e.g. $\mu(\eta,n)$, or fidelity-from-noise for BSD).
- **Embedded code** — a short, self-contained code block (engine call + problem-specific inputs + plot idea). This is the “documented” version of the script.
- **Parameters** — table of main parameters (e.g. $n$, noise floor) and their meaning.
- **Output** — which file(s) the script produces (e.g. `navier_stokes_regulator.png`).
- **Results** — link to the Results note: `**Results:** [[... Results]]`.
- **Links** — to the application note and to core theory (Fidelity, Resource Triangle).
The Code note is the **relational bridge**: it links the application to the engine and to the Results.
---
## 5. Including images in the pages
Figures produced by the scripts (e.g. `.png`) live in the **application subfolder** next to the script and the notes.
### 5.1 Markdown / Obsidian
To show an image **inside a note**:
- **Same folder as the note:**
``
Example: `` in `Navier-Stokes Smoothness (RST).md` or in `Navier-Stokes Regulator Results.md`.
- **Subfolder or relative path:**
``
If you ever move images to a dedicated `figures/` subfolder: ``.
- **Optional link:**
`[](filename.png)`
Renders the image and makes it clickable to open the file.
### 5.2 Where to put the image
- **Application note:** You can add the main figure once, e.g. in the section that describes the Python regulator/solver (e.g. “Python blow-up regulator” or “Python arithmetic solver”), so the reader sees the result in context.
- **Results note:** The **Results** note is the natural place to **embed the figure** and describe what it shows. **Result notes must include every result graph inlined** (e.g. `` for each figure produced by the script), so the note is self-contained and the reader sees the outputs in the vault. Example:
```markdown
## Output
| File | Description |
|:---|:---|
| `navier_stokes_regulator.png` | Velocity vs radius: RST regulated vs classical. |
```
**Guideline:** Every Results note must display the result graphs inlined; do not only list filenames. So: run script → image in application folder → reference image in Results (and optionally in the main application note) so that “documentation” and “output” stay linked.
---
## 6. Internal links — conventions
The vault uses **wikilinks** so that the vault stays relational and navigable.
### 6.1 Linking to application notes
- From **Applications Roadmap:**
`**[[ApplicationName (RST)|Short problem title]]**`
Example: `**[[Navier-Stokes Smoothness (RST)|Navier–Stokes existence and smoothness]]**`.
- From **another application or from core theory:**
`[[ApplicationName (RST)]]`
or, from inside `expanded theory applied`, same: `[[Navier-Stokes Smoothness (RST)]]`. If your vault is flat by name, the note name is enough; if you use folders, some systems resolve by note title/filename.
### 6.2 Linking to core theory (from applied folder)
- Because applied notes sit in `expanded theory applied/`, applied notes point into the core theory with an explicit path when needed:
`[[expanded theory/Relational Substrate Theory (RST)]]`
`[[expanded theory/Resource Triangle]]`
`[[expanded theory/Fidelity]]`
`[[expanded theory/Fidelity Derivation]]`
`[[expanded theory/Symbol Index]]`
`[[Relational Resolution Theory (Draft)]]` (RRT draft lives at workspace root, not under `expanded theory/`.)
Adjust if your vault uses different folder names (e.g. `expanded theory` vs full path).
### 6.3 Linking within an application
- **Application note → Code:**
`See [[Navier-Stokes Regulator - Code]].`
`**Results:** [[Navier-Stokes Regulator Results]].`
- **Code note → Application and Results:**
`parent: "[[Navier-Stokes Smoothness (RST)]]"`
In body: `**Results:** [[Navier-Stokes Regulator Results]].`
- **Results note → Application and Code:**
`Output from **[[Navier-Stokes Regulator - Code]]**`
Links: `[[Navier-Stokes Smoothness (RST)]]`, `[[Navier-Stokes Regulator - Code]]`.
### 6.4 Frontmatter (YAML)
- **parent:** The note this one belongs under (e.g. `parent: "[[../Applications Roadmap|Expanded Theory Applied]]"` or `parent: "[[Navier-Stokes Smoothness (RST)]]"`).
- **related:** List of sibling or closely related notes (application, Code, Results, core theory). Keeps the graph explicit.
Example for an application note:
```yaml
parent: "[[../Applications Roadmap|Expanded Theory Applied]]"
related:
- "[[../Applications Roadmap]]"
- "[[expanded theory/Relational Substrate Theory (RST)]]"
- "[[expanded theory/Resource Triangle]]"
- "[[Navier-Stokes Regulator - Code]]"
- "[[Navier-Stokes Regulator Results]]"
```
---
## 7. Relational map — what links where
| From | To |
|:---|:---|
| **Applications Roadmap** | Each application note (roadmap table); core theory (Links section). |
| **Application note** | Applications Roadmap (parent/related); Code note; Results note; core theory (axioms, Triangle, Fidelity, Symbol Index). |
| **Code note** | Application note (parent); Results note (Results section); core theory (Engine section, Links). |
| **Results note** | Application note; Code note; optionally embed image. |
| **Script** | (No links in code; the Code note documents how it plugs into the engine and what it outputs.) |
So: **Applications Roadmap** is the hub; each **application** is a small star (Application ↔ Code ↔ Results) that also links **up** to the core theory and engine. Documenting “everything relationally” means: every new application adds one subfolder, one application note, one Code note, one Results note (if there are outputs), and consistent links so that the whole applied folder stays one connected graph.
---
## 8. Checklist for a new application
1. **Subfolder** — create `expanded theory applied/<ApplicationName>/`.
2. **Engine** — script must import from the **`rst_engine/`** package (fidelity applications) or **`rst_axiom_pure`** in Micro-Graph Generator (graph-based applications such as Periodic Table). Add root and Micro-Graph path to `sys.path`. Do not copy or redefine the engine.
3. **Application note** — `"<ApplicationName> (RST).md"`: problem statement, RST reframe (axioms, identities), relation to prize/open problem; link to Code and Results.
4. **Script** — `rst_<topic>_<role>.py`: import from `rst_engine`, map problem to $\Omega,N,I$, produce figure in same folder; docstring and parameter comments.
5. **Code note** — `"<ShortName> <Suffix> - Code.md"`: Purpose, Engine, Embedded code, Parameters, Output, link to Results, Links to application + core theory.
6. **Run script** — generate figure (and any logs).
7. **Results note** — `"<ShortName> <Suffix> Results.md"`: what the figure(s) show; **include every result graph inlined** with `` so the note is self-contained; link to Application and Code.
8. **Applications Roadmap** — add one row in the roadmap table (problem name → application note, subfolder, one-line summary).
9. **Optional:** In the application note, add the same image in the “Python” section so the main page shows the result.
When in doubt: **script plugs into the general engine; Code note documents that; Results note shows the output and embeds the image; every note links to the others and to the core theory.** That is how everything is documented relationally.
---
## 9. Python resolution — can all scripts run?
Yes. All RST calculation scripts that use the engine **resolve** (run successfully) provided:
- The **workspace root** is the folder that contains both `expanded theory` and `expanded theory applied` (and the **`rst_engine/`** package).
- You run Python from that root, or from the script’s directory, so that `__file__` is set and the path to the root is correct. Example from root:
`python "expanded theory/python calculations/verify_super_relational_mapping.py"`
`python "expanded theory applied/Navier-Stokes Smoothness/rst_navier_stokes_regulator.py"`
`python "expanded theory applied/BSD Conjecture/rst_bsd_solver.py"`
**Scripts that plug into `rst_engine` (fidelity engine):**
- `expanded theory/python calculations/verify_super_relational_mapping.py`
- `expanded theory applied/Navier-Stokes Smoothness/rst_navier_stokes_regulator.py`
- `expanded theory applied/BSD Conjecture/rst_bsd_solver.py`
**Scripts that plug into the graph engine** (`rst_axiom_pure` in Micro-Graph Generator):
- `expanded theory applied/further applications/Periodic Table (RST)/rst_nuclear_fusion.py`
- `expanded theory applied/further applications/Periodic Table (RST)/rst_nucleon_ground_state.py`
- `expanded theory applied/further applications/Micro-Graph Generator/rst_axiom_pure.py` (derivation)
**Other scripts** (e.g. `rst_equilibrium_proof.py`, lensing scripts, evaluation notebooks) use their own logic or the `rawt` package; they do not import `rst_engine` and are unchanged. If you add a new application, give it a script that imports from `rst_engine` (fidelity) or `rst_axiom_pure` (graph) and add the path as above.
---
## Links
- **Applications Roadmap:** [[Applications Roadmap]]
- **Core theory:** [[expanded theory/Relational Substrate Theory (RST)]]
- **Engine (core):** [[expanded theory/Fidelity Derivation]], [[expanded theory/Resource Triangle]]
- **Example application (Navier–Stokes):** [[Navier-Stokes Smoothness (RST)]], [[Navier-Stokes Regulator - Code]], [[Navier-Stokes Regulator Results]]
- **Example application (BSD):** [[BSD Conjecture (RST)]], [[BSD Solver - Code]], [[BSD Solver Results]]