Engineering · Mathematics
Research in progress

Research / How the lab works

The Lab.

The rules, the vocabulary and the machinery shared by every research program — the part that does not change when the subject does. Programs themselves live on the Research page.

01 Programmes

Shared across every program

One machine,
many questions.

Each program owns its own page, its own data and its own evidence status, and inherits the same runner, the same conjecture engine and the same publishing path. A paused program keeps everything it built; nothing is deleted to make room.

Every program is listed on the Research home, with its status and live counters. This page describes what they have in common.

02 How the lab works

Method, not topic

Rules that outlive
any one question.

The subject changes; these do not. They exist because each was learned by getting something wrong first.

Every claim carries an evidence status.

An observation is not a result, a result is not a theorem, and a pattern found in simulation is none of the three. Statuses are attached at publication, not added afterwards.

A conjecture without a test is not a conjecture.

Silence is not survival. Nothing is marked as having withstood scrutiny unless a test existed that could have refuted it, and that test actually ran.

What failed stays on the record.

Falsified conjectures are kept with their counterexamples. So are refuted mechanisms, mis-specified tests and abandoned explanations. The failures are the part that stops the same wrong idea returning next week.

The machine runs whether anyone is watching or not.

Each programme lives on a local server as a supervised service. It survives disconnects, reboots and power loss, detects when its own code has changed, and restarts itself rather than continuing on a stale copy.

Impossible baselines are labelled as impossible.

Policies that read information no real system has are kept — they bound what is achievable — and are never reported as though they could be deployed.

03 Evidence statuses

What each label means

The vocabulary.

Used consistently across every programme, so a claim's weight is readable without reading the method.

literature resultEstablished elsewhere, cited here.
reproduced resultA known result recovered by this machinery — a check on the tooling, not a discovery.
empirical observationMeasured here. Holds over the parameter domain actually swept and says nothing beyond it.
candidate conjectureA stated pattern that has survived a test capable of refuting it.
falsified conjectureRefuted, kept with its counterexamples.
analytical derivationArgued from first principles and verified numerically.
unresolvedCarries information, fails its own threshold for a claim.
04 Infrastructure

Shared across programmes

One machine,
many questions.

Everything runs on a single local server. Simulations are deterministic Python; a small local language model is reserved for reading papers and drafting structured notes, never for numerical work.

Results are append-only JSONL, one self-describing row per run, each carrying a fingerprint of the code that produced it — so a change to the simulator invalidates exactly the cells it affects and no others. Every workload is a pure function of its parameters and a recorded seed.

This page and each programme's page are regenerated on the server and pushed from it. The numbers below were not typed by hand.