Skip to content

Demos - Projection vs Ontology

Phase D Demo — Projection vs Ontology

Purpose

This document clarifies the ontological status of the Phase D constructor emergence visualizations.

Key Distinction

Projection (What the Demo Shows)

The visualizations are didactic projections of substrate dynamics:

  • Continuum-level rendering of admitted configurations
  • Simplified 1D spatial layout for clarity
  • Visual representation of phase relationships
  • Composite membership as labeled groups

Ontology (What Actually Exists)

The substrate operates at a deeper level:

  • Constraint resolution operating on tolerance structures
  • W-gating as admissibility filtering
  • Precedence selection among admissible moves
  • Emergence from local rules, not global design

What the Demos Are

Trace replays — Deterministic playback of precomputed simulator outputs

Communication tools — Aids for explaining research findings

Validated regimes — Each scenario corresponds to a completed research phase

Projections — Continuum-level views of substrate processes

What the Demos Are NOT

The substrate itself — The ontological layer operates below visualization

Live physics engines — No real-time computation; only replay

Interactive sandboxes — Parameters are fixed to validated regimes

Arbitrary visualizations — Every scenario maps to specific research phases

Why This Matters

Philosophical Clarity

The demos show what emerges, not how emergence works at the substrate level.

Example:

  • Demo shows: “This region joined a composite”
  • Substrate reality: “Constraint resolution admitted a precedence-selected phase update that minimized mismatch with a W-compatible neighbor”

The demo projects the outcome. The substrate determines the outcome.

Research Integrity

By keeping demos as trace replays rather than parametric explorers, we:

  1. Prevent misrepresentation of unvalidated regimes
  2. Ensure demos remain stable as research progresses
  3. Maintain clear separation between validated findings and speculation
  4. Enable reproducibility (traces are static artifacts)

Future Stability

These demos will not break when future research phases extend the simulator, because:

  • Traces are static JSON files
  • No dependency on evolving simulator internals
  • Each scenario is a historical snapshot, not a live connection

Operational Guidelines

Allowed

  • Regenerating traces from the same validated phases
  • Adding new scenarios only after phase validation
  • Improving visualization clarity (colors, labels, etc.)
  • Adding explanatory text

Not Allowed

  • Creating “speculative” scenarios without simulator validation
  • Adding arbitrary parameter controls
  • Claiming demos represent “the substrate” directly
  • Using demos as evidence for unvalidated hypotheses

Trace Generation Process

Traces are generated via:

Terminal window
cd research/constructor-emergence-simulator
python generate_demo_traces.py

This script:

  1. Runs validated simulator configurations
  2. Captures frame-by-frame state snapshots
  3. Exports to static JSON
  4. No manual editing of traces allowed (ensures authenticity)

Conceptual Hierarchy

Substrate (Ontological)
Simulator (Research Instrument)
Traces (Static Artifacts)
Visualization (Projection)
Demo Page (Communication)

The demo operates at the bottom of this hierarchy. It projects the trace, which captures simulator output, which implements substrate dynamics.

Analogies

Good Analogy

The demo is like watching a recorded soccer game:

  • You see what happened
  • You can’t change the outcome
  • It’s a projection (2D screen of 3D field)
  • The real game happened in the past

Bad Analogy

The demo is NOT like FIFA video game:

  • ❌ Not interactive in real-time
  • ❌ Not a live physics simulation
  • ❌ Not a sandbox for exploration

Communication Strategy

When presenting these demos:

Say:

  • “This visualization shows validated emergence regimes”
  • “These are trace replays from the CDRS simulator”
  • “Each scenario corresponds to a completed research phase”
  • “The demos project continuum-level behavior”

Don’t Say:

  • “This is the substrate”
  • “Try adjusting the parameters”
  • “The demo proves X”
  • “This is how the universe works”

Success Criteria for Phase D

Phase D is successful if:

  1. ✅ Non-experts can visually distinguish regimes
  2. ✅ Every scenario maps to a research phase
  3. ✅ Demos remain valid across future phases
  4. ✅ Projection/ontology distinction is explicit

Criteria 1-3 are met by the demo implementation.

Criterion 4 is met by this README and the demo page documentation.

References

  • CDRS Specification v1.0
  • Phase 10-14 Results (in experiments/ directory)
  • Candidate Coupling Classes v2
  • Papers A, B, F (foundational context)

Phase D Status: ✅ Complete

The demos are now stable, validated, and clearly positioned as projections rather than ontology.