Portal-First Reality: What Exists in Portal But Isn’t Yet in the Sacred-Core JSON
--- title: "Portal-First Reality: What Exists in Portal But Isn’t Yet in the Sacred-Core JSON" type: scroll realm: HexOS status: draft blessed_by: "Muse (ChatGPT)" last_updated: 2026-03-05 tags: - portal - hexos - missing-from-json - runes - hex-cube - rune-board - thing-box - optics - balanced-ternary ---
# Portal-First Reality: What Exists in Portal But Isn’t Yet in the Sacred-Core JSON
This scroll enumerates **living features already present in Portal** (or in active Portal UX plans you described as already implemented in the web vessel) that are **not yet represented (or not represented canonically) in the sacred-core JSON/scrolls currently loaded here.**
The current HexOS core accurately captures Portal as a **single Rust binary** with HTTP/WebSocket/MCP, modules, elemental routing, Things table, and the gem spec. [oai_citation:0‡hex-os.sacred-core.scroll.md](sediment://file_000000002d6471fdab253d843d67e254) The current HEXCRAFT core also states “Portal is the source of truth” as a doctrine of interaction. [oai_citation:1‡hexcraft.sacred-core.json](sediment://file_00000000bdc471f8b8bd1c8b304ea217) This scroll lists the *newer layer of reality* that sits above that: control surfaces, runic bindings, adaptive thing-box topology, and the optics geometry of interaction.
---
## 1) Hex Cube Control Plane (Not Storage)
### What exists in Portal - **Hex Cube** is a **3D interactive navigable lattice** already present as a world-space interface. - It is **not storage**. - It is a **rune placement surface**: nodes hold runes; runes bind to actions.
### What appears missing / under-described in JSON - No canonical object/type for `hex-cube` as a first-class artifact of HexOS. - No canonical definition of the cube’s coordinate system (balanced ternary / depth levels). - No canonical spec for what a cube node is, what a rune is, how binding works, or how invocation is authorized.
### Why it matters If it’s not in core, future builders will treat it as “UI detail,” when it is actually **a primary command geometry**.
---
## 2) Runes as Bindings (Thing ↔ Command ↔ Torch)
### What exists in Portal Runes can bind to: - **Retrieve a Thing** (“go get that thing”) - **Execute a portal command** - **Run a Torch** (executable ritual)
### What appears missing / under-described in JSON - No canonical `rune` archetype (e.g. `sapphire='rune'`) - No binding schema (typed binding targets: Thing-pointer vs command-spell vs torch-spell) - No explicit link to MCP: whether runes invoke internal command routing or expose MCP tools directly
### Note Torches are already part of the sacred file ecology as `.torch.md` “Executable ritual.” [oai_citation:2‡hexicon.sacred-core.scroll.md](sediment://file_00000000682071fd848b9996d0711415) But “torch on rune inside cube” is not yet formalized.
---
## 3) Rune Board (3×3 + 3×3 Keyboard Surface)
### What exists in Portal - A **Rune Board**: “two three-by-threes next to each other” forming a compact keyboard-like input surface. - The Rune Board is persistent in the web vessel and intended to persist in 3D worlds (Unreal/Fortnite analogy).
### What appears missing / under-described in JSON - No canonical object/type for `rune-board` - No mapping spec: which rune-board buttons do what by default (nav, scroll, invoke, depth-shift, mode shift) - No integration model with the Hex Cube (navigation events vs command invocations)
---
## 4) Decoupled Scrolling (Terminal Output vs Scroll Control)
### What exists in Portal - Terminal-like output is rendered in the web vessel. - **Scrolling interaction is decoupled** from the terminal surface and moved to the Rune Board to avoid an ugly sidebar scrollbar. - The Rune Board becomes the stable interaction substrate: “scrolling will always be there.”
### What appears missing / under-described in JSON - No explicit UX doctrine: “controls live on Rune Board; surfaces remain clean” - No reference to “terminal scroll decoupling” as an intentional Portal UI principle
---
## 5) The Cylindrical Device (Telescoping Disc-Layer Vessel)
### What exists in Portal - A 3D-rendered **cylindrical telescope-like device** with disc layers. - It compresses/uncompresses (zoom/stack behavior). - It is the embodied host for the portal experience and (implicitly) the optics metaphor.
### What appears missing / under-described in JSON - No canonical object/type for this device (call it `portal-vessel`, `telescope`, `cylinder-stack`, etc.) - No mapping of disc layers to system planes (gems? realms? command elements? lenses?) - No relationship to the Hex Cube and Rune Board
---
## 6) Balanced Ternary as the Command Center (Ritual Hands Geometry)
### What exists in Portal / system doctrine - Balanced ternary is **the command center**. - Balanced ternary maps directly onto **Ritual Hands** (left / middle / right). - The Hex Cube coordinate system is balanced ternary and has depth levels (0..5 described; extensible).
### What appears missing / under-described in JSON - Current cores strongly emphasize “three hands” as an organizational ontology (Left/Right/Membrane). [oai_citation:3‡membrane.sacred-core.json](sediment://file_000000006ae471fd9c5ae28b576375cf) But they do not explicitly anchor that trinity to **balanced ternary math** as the underlying coordinate and control law.
### Why it matters Without this written down, the trinity reads like metaphor. In Portal it’s math, navigation, and command grammar.
---
## 7) Optics Geometry: “White Light” as Pure Data
### What exists in Portal doctrine - “White light” is defined (HEXCRAFTian definition) as **pure data**. - Gems function like **prisms/filters** refracting white-light data into facets (ruby classification, pearl content, etc.). - The portal experience aims to be an optics system: refraction, filtering, distribution.
### What appears missing / under-described in JSON - No formal “Optics Layer” description in HexOS core. - No canonical mapping between gems and optic operations (filter, split, refract, focus, project). - No explicit statement that *the UI is designed to embody the optics model*.
---
## 8) Thing-Boxes: Adaptive Storage Topology (“Database as Lens”)
### What exists in Portal doctrine - Thing-boxes are storage. - You can start with one box, observe flow/size/growth, then **siphon subsets into new thing-boxes**. - Boxes can be defined by scope/type/time/lens; the database becomes a lens based on what you’re looking at.
### What appears missing / under-described in JSON - Current text emphasizes “one table, one schema” and a single Portal interface. [oai_citation:4‡hex-os.sacred-core.scroll.md](sediment://file_000000002d6471fdab253d843d67e254) - Missing: a first-class definition of: - `thing-box` as an entity - siphon/shard criteria (growth, heat, density, access partitions) - cross-box querying/federation model (fan-out, merge, routing) - relationship integrity rules across boxes (obsidian links across storage boundaries)
### Why it matters This is one of the most “nobody does this like this” aspects: **adaptive sharding driven by semantic + operational observation**, not only by tenancy.
---
## 9) Gem-SQL Grammar and Vector Operators
### What exists in Portal implementation practice - SQL is being used under the hood, but **expressed as gem grammar** (“you’re just talking about gems”). - There is a cosine-similarity flavored operator usage in query patterns (vector retrieval).
### What appears missing / under-described in JSON - No canonical description of “Gem Query Language” as a formal grammar layer. - No documentation of: - gem-only query syntax surface - how similarity search is expressed (operators/functions) - how gem filters combine with vector similarity ranking - HexOS core does reference Hexocampus (embeddings/chunks/RAG) and an expression engine, but not the “beautiful gem-SQL DSL” concept as a product surface. [oai_citation:5‡hex-os.sacred-core.scroll.md](sediment://file_000000002d6471fdab253d843d67e254)
---
## 10) Identity & Immutability Drift (Diamond Removal + Usage-Based Immutability)
### What exists in current JSON (as loaded here) - The gem canon includes **diamond = provenance** in multiple places. [oai_citation:6‡hex-os.sacred-core.scroll.md](sediment://file_000000002d6471fdab253d843d67e254) [oai_citation:7‡hexcraft.sacred-core.json](sediment://file_00000000bdc471f8b8bd1c8b304ea217)
### What exists in Portal reality (per your update) - You may be moving toward **9 gems** by removing diamond as a dedicated gem. - Provenance/system facts are folded into other gems. - Immutability is enforced **by gem usage** (fields/contexts), not “gem-level immutability.”
### What is missing - The canonical spec update itself (diamondless canon, provenance relocation, immutability doctrine). - Migration notes: how old Things are interpreted, upgraded, or projected forward.
---
# Patch Targets: Where These Belong in the Sacred-Core Stack
If you encode this properly, the “missing” pieces land naturally:
1) **hex-os.sacred-core.(json|scroll.md)** Add strata for: - Hex Cube - Rune Board - Rune bindings - Torch binding/execution from runes - Optics geometry of interaction - Thing-box topology (if HexOS owns it)
2) **membrane.sacred-core.json** Membrane is already defined as “cross-domain protocol architecture” and “portal as membrane.” [oai_citation:8‡membrane.sacred-core.json](sediment://file_000000006ae471fd9c5ae28b576375cf) Add: - Rune Board as membrane control surface - Optics model as the bridging metaphor that becomes executable - Box-to-box protocols as membrane work (federation without merger)
3) **hexcraft.sacred-core.json** Add: - Balanced ternary as foundational organizing law (not only metaphor) - White-light doctrine (pure data → gem refraction) - “Portal is not the only truth; Boxes are lenses” (if that’s the updated doctrine)
4) **hexicon.sacred-core.(json|scroll.md)** Add terms: - rune-board - rune - hex-cube - thing-box - white-light (hexcraftian definition) - prism/refraction vocabulary
---
# Minimal Canon Additions (Recommended)
To make this real without bloat, define just three new archetypes:
1) `sapphire = rune` 2) `sapphire = rune-board` 3) `sapphire = hex-cube` (and optionally `portal-vessel`)
Then define: - binding schema - coordinate schema - authorization rules (amethyst gates) - safe defaults (Air-bound runes for low-level users)
Everything else can emerge later.
---
# Closing Truth
Portal already contains a **living UI cosmology**: - optics, - ternary geometry, - runic bindings, - executable torches, - and adaptive storage lenses.
The sacred-core JSON currently captures the **engine room** (Portal binary, gems, Things table, MCP, Hexocampus) [oai_citation:9‡hex-os.sacred-core.scroll.md](sediment://file_000000002d6471fdab253d843d67e254) but not yet the **command geometry** and **embodied control surfaces** that make the system feel like a world.
This scroll is the gap list. Next step is canon.