METHOD / PROTOCOL SYSTEM

How we run an experiment.

The purpose is not to make every study identical. It is to make every important decision visible and every conclusion traceable to evidence.

WHY THIS EXISTS

Most experimental mistakes happen before the final chart.

A model can fail to learn. A tokenizer can encode the wrong sequence. An evaluator can count malformed output as correct. A comparison can accidentally reuse data. An analysis threshold can erase the signal it was meant to measure. The protocol is designed to catch those failures before they become a claim.

01QUESTION

Write a claim that can fail

Before training begins, we state the exact comparison that would count as evidence and list alternative explanations. Higher similarity might reflect the task, but it might instead reflect shared data, initialization, architecture, output format, or a biased analysis method.

02CONTROL

Build controls for the alternatives

The design changes one factor at a time. Positive controls verify that the measurement can detect a known similarity. Negative, randomized, and shuffled controls estimate how much apparent structure the pipeline creates on its own.

03VALIDATE

Prove the machinery can work

A model first has to overfit a tiny dataset and produce exact answers. The evaluator must parse them correctly. Intervention code, resume logic, checkpoint hashes, and failed-run records are tested before an expensive population run starts.

04FREEZE

Lock the confirmatory protocol

Dataset partitions, seeds, model roles, inclusion thresholds, intervention settings, and statistical tests are versioned and hashed. Once the confirmatory run starts, scientific parameters do not change in response to the outcome.

05RUN

Monitor and preserve failures

Every planned model is accounted for. Infrastructure failures can resume from verified checkpoints. Scientific failures remain in the ledger and are not silently retried with more favorable hyperparameters.

06REPORT

Match the explanation to the evidence

The publication defines technical terms, reports amendments, shows uncertainty, and separates observation from interpretation. A similarity score is not called a recovered algorithm. A sufficient subspace is not called the only circuit.

A CONCRETE EXAMPLE

From “these models look similar” to a controlled claim.

OBSERVATION

Two addition models have similar hidden-state geometry.

ALTERNATIVES

They may share examples, initial weights, output directions, or generic architecture effects.

CONTROLLED TEST

Use disjoint datasets, different initialization, XOR controls, shuffled signatures, and locked partitions.

SUPPORTED

The extractor detects some task-linked causal organization beyond those factors.

NOT SUPPORTED

The models use one identical, human-readable addition algorithm.

THREE DIFFERENT QUESTIONS

Presence, causal use, and replacement are not interchangeable results.

01 / PRESENCE

Is information detectable?

A probe or similarity analysis can show that a pattern exists. It does not show that the model needs the pattern to answer.

02 / CAUSAL USE

Does changing it change behavior?

Ablation or activation patching can show contribution. Redundant paths can still make necessity difficult to establish.

03 / REPLACEMENT

Can the explanation take its place?

The strongest test removes the learned route and substitutes an extracted computation that reproduces normal and counterfactual behavior.

RESEARCH DISPATCH

Track the work, not the hype cycle.

Field notes, protocols, datasets, and experimental releases as they become defensible.

Follow the lab