Observer Patch Holography turns a physics hypothesis into a program you can run

OPH starts from records that observers can compare, not from spacetime

Observer Patch Holography, shortened to OPH in the repository, proposes that physics is what bounded observers can establish together. The mechanism it assumes is social and mechanical rather than metaphysical: finite observers compare records on shared boundaries, repair their disagreements, and treat as real whatever survives every comparison. Three stubborn problems motivate the programme, namely quantum measurement, correlations that no local classical model reproduces, and the origin of an apparent spacetime. OPH seeks one explanation for all three in the consistency of observers' records and operations, and it pursues that explanation through three concrete artifacts rather than through argument alone: an executable observer, machine-checked mathematics, and predictions fixed in advance. The audience is narrow, mostly researchers and reviewers who want to inspect whether the formal machinery holds together, and anyone who can read Lean and Python.

The smallest observer has twelve ports and two events

The smallest observer in the project has twelve ports and two events. It writes a record at each event, keeps that record, and lets only the record choose the next repair. The interesting part is that the record changes what is measured: the final occupation moves from 1/6 to 35/264 when record-selected feedback is in play. One finite quantum process joins electric flux, charged matter and a scalar field on a single register, and an exact calculation certifies that the recorded feedback changes the measured response. The observer protocol continues smoothly, executing four reads on one disturbed state and compiling two quantum record laws of the native repair, while an encoded qubit survives record-selected recovery under declared services. Two observers with overlapping regions read their fields and clocks from one continuing history and agree on a single complete law. Joined carriers form screens of up to 245,760 ports, and on a refining screen one repair history defines a continuum field with Gaussian fluctuations and waves of finite speed.

Running the observer model and reading the Brier risk

The model directory holds a runnable observer, its tests and its retained results. From the repository root, with Python 3.11 or newer, the entry point is a module invocation with a trial count and a seed:

python3 -m model.observer run --trials 10000 --seed 42

The run prints a single line: the Brier risk of three forecasts of the next record, plus the hash of the result. The format is JSON, so it pipes into other tooling without parsing work:

{"brier": {"action_known_prior": 0.0728, "native_record": 0.0563, "within_action_shuffle": 0.0884}, "reference_matches": 10000, ...}

Lower is better, so read the three numbers against each other rather than in isolation. The forecast that uses the retained record, at 0.0563, beats the one that knows only the chosen action at 0.0728 and the one with records shuffled within the same action at 0.0884. That ordering is the point of the exercise: if the retained record carried no information, the shuffle control would land in the same place. The reference_matches field shows that all 10000 trials produced a match against the reference, and the hash makes the output verifiable against the retained results.

The Lean library carries 12,600 theorems without admitted proofs

The formal side lives in the Lean directory, and the README states it contains more than 12600 public theorems and lemmas with no admitted proofs, with every retained computational receipt replayed under continuous integration. That is a specific and checkable claim rather than a slogan: admitted proofs are the usual hiding place for an unproved step, and the project advertises the absence of them as a headline. The theorems then push finite readouts toward familiar structure. The listed results include public records that do not depend on the order of repairs, the Born rule fixing quantum probabilities, the Tsirelson bound on completed records, a carrier that is three-dimensional in its slow response, the Standard Model gauge Lie algebra with one anomaly-free generation, a (1+3)-dimensional causal order in which proper time comes from record counts, and the Einstein equation arising from a realized null balance. The repository also carries CI workflows for a mandatory suite, for Lean, and for a runnable observer model.

Predictions are frozen and timestamped before the comparison data exists

This is where OPH differs most sharply from ordinary computational physics practice, and the difference is about where the rejection rule is written. A prediction and the rule that would kill it enter the frozen-prediction ladder before any comparison data, with timestamps attested on the Bitcoin blockchain; the dispersion prediction for the primitive port orbit is named as one of them. A hash written after the data arrives proves nothing, which is the entire reason for putting the rule in custody first. The postdiction ledger and the falsification programme keep comparisons with real measurements apart from tests of the mathematics, so a failure of one kind cannot be quietly absorbed into the other. The prediction package fixes an experiment and its count-based rejection rule before any independent counts, and the construction guide states the acceptance criteria for the candidate. On the repair law itself, the candidate guide separates what is forced from what is free: the classical rule follows from four requirements, and the quantum record laws form one family with five coherence multipliers.

The README marks its own boundary: agreement with measurements is not established

The most useful paragraph in the README is the one that concedes the limit. It states that agreement with the full range of observed measurement statistics has not been established, that the theorems hold under stated premises, and that the executable observer is a candidate judged by declared acceptance criteria. Further down, the model description names the field action and the preparation of the common interacting process as supplied inputs. That is the honest shape of the project: the logical and computational machinery is claimed to be verified, while the physical match to measurement is claimed only in part. A reader deciding whether to spend time here should treat the Lean library and the replayed receipts as the strong side of the claim and the comparison with observed statistics as the open side, because the project itself draws that line.

Reproducing the suite means a pinned dependency set and three skipped Windows packages

The dependency file pins the core scientific receipt suite, and the comment says it was pinned and verified from a clean clone on CPython 3.12. The pinned set is the following:

numpy==2.5.3
scipy==1.18.1
mpmath==1.3.0
sympy==1.14.0
PyYAML==6.0.3
jsonschema==4.26.0
cryptography==50.0.2
pytest==9.1.1

The comment above the list explains why mpmath and sympy are declared explicitly, since they are imported across code/ and clean-clone collection needs them named. Optional lanes keep their own extras and stay opt-in, so the IBM and Qiskit hardware lane runs only when OPH_RUN_IBM=1 is set, and the qiskit ancillary experiments live behind their own requirements file. The frozen-prediction custody code under evidence/custody/ parses detached OpenTimestamps proofs locally with no network access, but the client cannot start on Windows because python-bitcoinlib finds no OpenSSL there, so those three packages carry a sys_platform marker and are skipped on that platform:

opentimestamps-client==0.7.2; sys_platform != "win32"
opentimestamps==0.4.5; sys_platform != "win32"
python-bitcoinlib==0.12.2; sys_platform != "win32"

A Windows user can still run the model, but loses the local proof parsing, and the repository also states that pytest.ini sets testpaths to code.

A custom licence and a release train that ships every few days

GitHub classifies the licence of this repository as Other, meaning a custom licence that GitHub cannot categorise, with the terms in the LICENSE file at the root. Anyone planning to build on the code needs to read that file directly rather than assume a familiar permissive licence, since the repository has no README section explaining the terms. The project is also moving quickly. The last push was on 2026-10-20, and the recent release list shows r2049 on 2026-10-13, r2050 on 2026-10-17 and r2051 on 2026-10-19. That cadence suits a working research programme whose artefacts and proofs change together, but it also means a pinned tag is the sane choice when you want a reproducible state. The repository layout reflects the breadth: Lean/, model/, docs/, evidence/, code/, paper/, book/, claims/, cosmology/, tracking/, tools/ and schemas/ all sit at the top level, alongside the reproduction guide REPRODUCE.md and a French version of the README.

Editorial conclusion

Adopt Observer Patch Holography if your interest is in the closure hypothesis itself, in a physics claim written as executable specifications, or in a reproduction pipeline that treats a prediction as a commitment rather than a result. Do not adopt it as a source of established physics: the README states plainly that agreement with the full range of observed measurement statistics has not been established, and the field action and the preparation of the common interacting process are supplied inputs rather than derived ones. Before using any of it, read docs/BASIS.md for the premises, run python3 -m model.observer run --trials 10000 --seed 42 to see the observer model produce its Brier risk, and check the LICENSE file yourself, since GitHub classifies it as a custom licence it cannot categorise.

Frequently asked questions

Official sources

1. FloatingPragma/observer-patch-holography on GitHub
2. Issues
3. Project website
4. README
5. Releases