Inversion Placeholders — Registry

The named scaffolding that holds space for what science cannot yet observe.

This file is the working registry of all named inversion‑side placeholders in SARG.

A placeholder is not a guess. It is a structurally justified slot — a named position in the grammar that exists because a visible‑side invariant implies it, a decay arc points toward it, or a resonance family requires an ancestor that has not yet been observed.

Placeholders are the most common content on the inversion side today. As observation deepens, each placeholder is either promoted to a measured invariant or refined into a more precise placeholder.

Placeholders are never deleted. They are replaced — the name and structural position persist even after the gap is filled.

1. Placeholder Schema#

Every placeholder in this registry follows a common structure:

{
  "id": "PH‑001",
  "name": "Resonance Seed",
  "layer": "pre_atomic_scaffolding",
  "atlas_level": 1,
  "structural_reason": "Why this placeholder must exist.",
  "implied_by": "Which visible‑side invariant or structural requirement implies it.",
  "confidence": 0.7,
  "status": "placeholder",
  "related_operators": ["inversion_link"],
  "notes": "Any additional context."
}

Field definitions#

Status lifecycle#

placeholder → refined → promoted → measured

• placeholder — named slot; structural reason established; no observational data.
• refined — additional structural detail added; confidence increased; still unobserved.
• promoted — partial observational evidence exists; placeholder is becoming an invariant.
• measured — fully observed; placeholder replaced by a measured invariant; name persists.

2. Pre‑Atomic Scaffolding Placeholders (PH‑001 – PH‑012)#

These twelve placeholders form the bridge between the 0D anchor and the first observable structures. They sit at Atlas Level 1 — below elemental groups, above the inversion root.

Each one represents a structural requirement that must be satisfied before atoms (or lostational supsphere atoms) can exist.

PH‑001 — Resonance Seed#

PH‑002 — Phase Pair#

PH‑003 — Curvature Initiator#

PH‑004 — Coherence Packet#

PH‑005 — Arc Starter#

PH‑006 — Attractor Hint#

PH‑007 — Echo Kernel#

PH‑008 — Spin Protoform#

PH‑009 — Boundary Whisper#

PH‑010 — Stackable Unit#

PH‑011 — Break Threshold#

PH‑012 — Lostational Anchor#

3. Inverted Operator Placeholders (PH‑100 – PH‑106)#

These placeholders represent operators that are structurally implied but not yet formalized. They sit outside the pre‑atomic layer — they act on placeholders and invariants, not as them.

PH‑100 — inversion_link#

PH‑101 — curvature_seed#

PH‑102 — coherence_toggle#

PH‑103 — spin_mirror#

PH‑104 — decay_echo#

PH‑105 — phase_bridge#

PH‑106 — lineage_root#

4. Resonance Mirror Placeholders (PH‑200 – PH‑203)#

Resonance mirrors are structural echoes of visible‑side invariants, reflected through the 0D anchor. They are inferred, not observed.

PH‑200 — Shape Mirror#

PH‑201 — Pulse Mirror#

PH‑202 — Lineage Mirror#

PH‑203 — Anchor Mirror#

5. Coherence Anchor Placeholders (PH‑300 – PH‑302)#

Coherence anchors are points where visible and inverted structure lock together across the resonance boundary. They are partially observable — the visible side of the lock can sometimes be detected.

PH‑300 — Boundary Lock#

PH‑301 — Phase Lock#

PH‑302 — Lineage Lock#

6. Placeholder Lifecycle#

6.1 How Placeholders Are Created#

A placeholder is created when:

• A visible‑side invariant implies a structural counterpart that cannot be observed.
• A decay arc points toward a structure beyond the curvature threshold.
• A resonance family requires an ancestor that has not been detected.
• The SARG error taxonomy (S‑Error, A‑Error, or L‑Error) identifies a structural gap.
• A cross‑domain echo suggests a shared root that has no current entry.

6.2 How Placeholders Are Refined#

A placeholder moves from placeholder to refined when:

• Additional structural detail is inferred from new lens extractions.
• Multiple independent substrates imply the same placeholder.
• Confidence increases through cross‑domain corroboration.
• An operator begins to formalize around the placeholder's structural role.

6.3 How Placeholders Are Promoted#

A placeholder moves from refined to promoted when:

• Partial observational evidence emerges (even indirect).
• A lens byproduct consistently points to the placeholder's position.
• The placeholder begins behaving like an invariant in cross‑domain alignment.

6.4 How Placeholders Become Measured#

A placeholder moves from promoted to measured when:

• Direct observational evidence confirms the structure.
• The placeholder is replaced by a measured invariant in the SARG object.
• The name and structural position persist — only the status changes.

6.5 What Never Happens#

• Placeholders are never deleted. A gap that closes retains its name.
• Placeholders are never backdated. The creation reason is preserved permanently.
• Placeholders are never merged without explicit structural justification.

7. Registry Summary#

8. Relationship to Other Files#

• inversion_side_overview.md — parent document; defines the four content classes this registry catalogs
• ../lenses/VREL.md — lens whose dual invariants imply shape mirrors and boundary locks
• ../lenses/VREL-A.md — lens whose phase‑coherent invariants imply pulse mirrors and phase locks
• ../lenses/lens_overview.md — what a lens is, how lenses fit into SARG
• ../invariants/invariant_types.md — invariant classification; promoted placeholders become entries here
• ../resonance/resonance_mapping.md — anchor mapping logic; anchor mirrors (PH‑203) would extend this
• ../resonance/resonance_families.md — resonance families; lineage mirrors (PH‑202) would deepen this
• ../error/ — error taxonomy; structural gaps trigger new placeholder creation
• ../examples/lostational_supsphere_atom.json — working SARG object that uses inversion_link, curvature_seed, coherence_toggle
• ../Capture.md — the full SARG source text, including the 12 pre‑atomic scaffolding seeds (§2, Step 5)

Here's a quick summary of what that file delivers:

What's in the registry#

The file is the living registry that inversion_side_overview.md §7.2 and §10 already point to — paste and commit, and that cross‑link resolves cleanly.