questforentropy/iceberg-model

The Iceberg Model - a two-layer computational architecture demystifying quantum and relativistic behaviour, with a versioned examination harness

0

stars

16

commits

Python

primary language

Aug 23, 2026

updated

questforentropy.substack.com
distributed-ledger
emergent-spacetime
general-relativity
iceberg-model
quantum-foundations
quantum-mechanics
quest-for-entropy
solaris
toy-model

README

The Iceberg Model

DOI

The Iceberg Model

A two-layer computational toy architecture in which the classic mysteries of quantum mechanics and relativity stop being mysterious: a fixed-compute substrate whose load bookkeeping makes spacetime, gravity, and expansion emerge, and an append-only ledger holding the state - entanglement as a shared contract, measurement as settlement, the universal wave function stored factorized. The claim is mechanism sufficiency, not empirical adequacy: we are not claiming to have built the universe on a laptop.

The paper is the model's manifest: paper/the-iceberg-model.md (canonical; also as PDF, with the LaTeX source generated from the markdown). Further papers will join it as the model evolves.

Which version is this checkout? model/card.md — the single source of truth for the version triplet, with the three layers described beside it: model/architecture.md (the postulates), model/implementation.md (the mechanisms and the row-to-lab map), model/configuration.md (the dials).

Run the examinations

pip install -r requirements.txt
python labs/run_exams.py all --record solaris-1.1.0 --expect-red GR-34,GR-35,GR-36

Expected: 150 rows - 147 pass and exactly 3 red. The red rows (GR-34..36) are pre-registered findings kept deliberately (the paper's "Difficulties with the theory", item 4): their pass marks were declared before the first run and never softened. Version-independent row definitions live in tests/definitions/; the generated record - status, declared criterion, and measured detail per row - in tests/results/. Individual sets run by name: python labs/run_exams.py QM GR.

Swap the quantum engine (Solaris 1.1.0)

The amplitude arithmetic sits behind a small port (labs/engine/), so the wave storage is swappable. The nine-check QM battery runs on any of four backends and must reproduce the frozen reference labs/qm_tests.py byte-for-byte:

python labs/qm_battery.py                    # default: table (stdlib-only)
pip install -r requirements-engines.txt      # then:
python labs/qm_battery.py --engine numpy
python labs/qm_battery.py --engine qutip
python labs/qm_battery.py --engine qiskit    # Aer statevector

Draws are hash-fed and deterministic, so conformance is exact - identical output, not statistically similar. --engine broken runs the negative control (weights |a| instead of |a|²): it fails 4 of 9 checks, demonstrating the battery detects a wrong engine.

All numbers - like every experiment behind them - were produced with AI assistance and are under continuing verification and validation; the one-command reproduction exists precisely so any reader can check any number independently. Discrepancies you find are exactly the contribution this repository invites. The texts - the paper and the series' publications - are likewise AI-written from the author's guidance and under his editing.

Author

Marijus Masteika - independent researcher (masteris@gmail.com)

Versions and branches

Semantic versioning <instance> M.m.p: M = architecture (manifest) major, m = implementation iteration, p = configuration revision.

  • main carries the reference instance, Solaris - the active main implementation. Releases are tags (solaris-1.0.0), each a citable snapshot.
  • exp/* branches carry implementation or configuration experiments; an experiment merges to main (bumping m or p) only after sitting the full examination battery.
  • A future second named instance would get its own long-lived branch; an architecture change bumps M on main.

Licenses, attribution, and citation

Code: MIT. Paper and documentation: CC BY 4.0. Clone, fork, and build on it - with attribution.

Attribution request (beyond the license): if you present or build on the concepts of this work in any medium - a video, an article, a talk, a journal paper - please credit the author and cite the paper (see CITATION.cff; a DOI is attached at each release). The license binds reuse of the material; crediting the ideas is the scholarly norm this request appeals to, and the release history here is the dated record of where they came from.

arXiv endorsement

The author is an independent researcher. If you are an active arXiv author in quant-ph or a related category and - after reading the paper - consider it appropriate for the category, an arXiv endorsement would be appreciated: masteris@gmail.com.

Contributing

Issues are open - the most valuable kind names a behaviour this model cannot reproduce. See CONTRIBUTING.md.

Contributors

masteris777

16 commits

questforentropy/iceberg-model

The Iceberg Model - a two-layer computational architecture demystifying quantum and relativistic behaviour, with a versioned examination harness

0

stars

16

commits

Python

primary language

Aug 23, 2026

updated

questforentropy.substack.com
distributed-ledger
emergent-spacetime
general-relativity
iceberg-model
quantum-foundations
quantum-mechanics
quest-for-entropy
solaris
toy-model

README

The Iceberg Model

DOI

The Iceberg Model

A two-layer computational toy architecture in which the classic mysteries of quantum mechanics and relativity stop being mysterious: a fixed-compute substrate whose load bookkeeping makes spacetime, gravity, and expansion emerge, and an append-only ledger holding the state - entanglement as a shared contract, measurement as settlement, the universal wave function stored factorized. The claim is mechanism sufficiency, not empirical adequacy: we are not claiming to have built the universe on a laptop.

The paper is the model's manifest: paper/the-iceberg-model.md (canonical; also as PDF, with the LaTeX source generated from the markdown). Further papers will join it as the model evolves.

Which version is this checkout? model/card.md — the single source of truth for the version triplet, with the three layers described beside it: model/architecture.md (the postulates), model/implementation.md (the mechanisms and the row-to-lab map), model/configuration.md (the dials).

Run the examinations

pip install -r requirements.txt
python labs/run_exams.py all --record solaris-1.1.0 --expect-red GR-34,GR-35,GR-36

Expected: 150 rows - 147 pass and exactly 3 red. The red rows (GR-34..36) are pre-registered findings kept deliberately (the paper's "Difficulties with the theory", item 4): their pass marks were declared before the first run and never softened. Version-independent row definitions live in tests/definitions/; the generated record - status, declared criterion, and measured detail per row - in tests/results/. Individual sets run by name: python labs/run_exams.py QM GR.

Swap the quantum engine (Solaris 1.1.0)

The amplitude arithmetic sits behind a small port (labs/engine/), so the wave storage is swappable. The nine-check QM battery runs on any of four backends and must reproduce the frozen reference labs/qm_tests.py byte-for-byte:

python labs/qm_battery.py                    # default: table (stdlib-only)
pip install -r requirements-engines.txt      # then:
python labs/qm_battery.py --engine numpy
python labs/qm_battery.py --engine qutip
python labs/qm_battery.py --engine qiskit    # Aer statevector

Draws are hash-fed and deterministic, so conformance is exact - identical output, not statistically similar. --engine broken runs the negative control (weights |a| instead of |a|²): it fails 4 of 9 checks, demonstrating the battery detects a wrong engine.

All numbers - like every experiment behind them - were produced with AI assistance and are under continuing verification and validation; the one-command reproduction exists precisely so any reader can check any number independently. Discrepancies you find are exactly the contribution this repository invites. The texts - the paper and the series' publications - are likewise AI-written from the author's guidance and under his editing.

Author

Marijus Masteika - independent researcher (masteris@gmail.com)

Versions and branches

Semantic versioning <instance> M.m.p: M = architecture (manifest) major, m = implementation iteration, p = configuration revision.

  • main carries the reference instance, Solaris - the active main implementation. Releases are tags (solaris-1.0.0), each a citable snapshot.
  • exp/* branches carry implementation or configuration experiments; an experiment merges to main (bumping m or p) only after sitting the full examination battery.
  • A future second named instance would get its own long-lived branch; an architecture change bumps M on main.

Licenses, attribution, and citation

Code: MIT. Paper and documentation: CC BY 4.0. Clone, fork, and build on it - with attribution.

Attribution request (beyond the license): if you present or build on the concepts of this work in any medium - a video, an article, a talk, a journal paper - please credit the author and cite the paper (see CITATION.cff; a DOI is attached at each release). The license binds reuse of the material; crediting the ideas is the scholarly norm this request appeals to, and the release history here is the dated record of where they came from.

arXiv endorsement

The author is an independent researcher. If you are an active arXiv author in quant-ph or a related category and - after reading the paper - consider it appropriate for the category, an arXiv endorsement would be appreciated: masteris@gmail.com.

Contributing

Issues are open - the most valuable kind names a behaviour this model cannot reproduce. See CONTRIBUTING.md.

Contributors

masteris777

16 commits

Languages

Python

83.6%

TeX

16.4%