/establishing-feasibility-first

name: establishing-feasibility-first
description: Use when your human partner has explicitly opted into exploratory or feasibility mode - a compute-heavy simulation, an unproven pipeline, an unbenchmarked solver, an untested cluster job - or when whether the work can run at all is still unknown, when a plan's largest configuration has never been executed, when a memory or wall-clock ceiling is estimated rather than measured, or when someone proposes pre-registering over runs that have never happened

Establishing Feasibility First

Overview

When it is not yet known whether the computation can run at all, the decisive experiment is not scientific — it is whether the thing executes at scale. Run that experiment first, on the smallest honest version of the real path, and let its measured answer shape everything downstream.

**Core principle:** Process built on an unmeasured feasibility number is process built on a guess. When the guess is wrong, every plan, prediction, and decision rule resting on it was written for a study that does not exist.

This is the deliberate exception to the standard sequence. It exists because the standard sequence assumes the analysis *can* be run, and pays its full cost before testing that assumption.

The Iron Laws

NOTHING IS FEASIBLE UNTIL IT HAS RUN
NOTHING IS BOUNDED UNTIL THE BOUND HAS FIRED

An estimate is not a measurement. A declared kill criterion is not a kill criterion. Both must be demonstrated by execution before any work is built on top of them.

The Entry Gate — Opt-In Only

**Only your human partner can enter this mode.** You may *offer* it; you may never declare it yourself.

Offer it when you notice the triggers: an unrun pipeline, an unbenchmarked solver, an estimated rather than measured ceiling, or a plan whose largest configuration has never executed. Make the offer concrete and wait:

> "Whether this can run at scale is still unknown, and everything downstream depends on the answer. I can enter feasibility mode: a minimal end-to-end runner, three scaling probes, then one exploratory campaign — deferring the survey, the analysis plan, and pre-registration until we know what is runnable. That defers confirmatory claims; nothing produced in this mode can support one. Do you want that, or the standard confirmatory sequence?"

**If they decline, or do not answer, you are in the standard sequence.** Silence is not opt-in. Use `science-superpowers:framing-research-questions` and proceed normally.

**You may not enter this mode to escape rigor.** "This feels exploratory" is not opt-in. "The pre-registration is getting tedious" is not opt-in. Only an explicit choice by your human partner opens this path.

Before Anything: A Short Framing

Feasibility mode defers the survey and the analysis plan. It does **not** skip framing — it shrinks it.

Write a few sentences, not a document, and get agreement:

• **The feasibility question** — the specific thing that must be true for the science to be possible, stated as a measurable threshold ("a 30M-row assembly fits in under 60% of RAM and solves in under 8 hours")
• **The scientific question it gates** — one sentence, held for later
• **The abandonment condition** — what measured result means this approach is not viable, decided now

Keep these separate. Tangling them is what produces pre-registrations written over runs that cannot happen.

Get explicit agreement on the abandonment condition specifically — not an inference from "go ahead". It is necessarily a judgement call made before any measurement exists, so it is both the item most likely to be wrong and the one that later fires and stops the work. Revise it freely before the probes run; never after a probe has reported.

Phase 1: The Minimal End-to-End Runner

Build the thinnest thing that exercises the **real** code path end to end, at a trivial problem size.

• Real solver, real assembly, real I/O — a stub anywhere means the phase proved nothing about the real path
• Smallest size that still touches every stage
• One ground-truth check: a case whose answer is known analytically, asserted to tolerance

**If the thing under test does not exist yet, build only the adapter to it.** Do not build the study around a component that has never been called. Where the real component is genuinely unavailable, a reference implementation is acceptable — but label every number it produces as surrogate, and never let a surrogate result gate a decision without saying so.

**Beware the degenerate test case.** A manufactured problem whose solution is an eigenvector of the operator converges in a fixed number of iterations regardless of size, and will report flat, beautiful, meaningless scaling. If every probe converges in the same handful of iterations, suspect the test problem before believing the result.

**A clean number is not a correct number.** Convergence, a plausible order, and a tidy extrapolation are all available to a quantity measured at the wrong location, in the wrong component, or under a broken preconditioner — and they look exactly like success. Check the measured quantity against an independent reference (an analytic solution, a published value, a different implementation) before you believe it, and treat a large disagreement as an anomaly to root-cause rather than a calibration offset to absorb.

Phase 1 is done when the real path has run end to end once and produced a correct known answer.

Phase 2: Three Scaling Probes

Three measured points, then at most one inference hop.

**First, write the feasibility budget** to `docs/science-superpowers/feasibility/YYYY-MM-DD-<topic>.md` — before any probe runs:

# Feasibility: <topic>

**Feasibility question:** <the measurable threshold>
**Scientific question it gates:** <one sentence, deferred>

## Budget
| Resource | Per-run limit | Whole-sweep limit | On breach |
|----------|---------------|-------------------|-----------|
| Wall clock | <...> | <...> |