Chapter 9 · Part II — RFPA: The Frame You Set Before Growth

Declare the Assumptions

#Opening signal

The Fibonacci sequence you compute depends on assumptions you may not have noticed you made: that you started at $F_{0} = 0$ rather than $F_{1} = 1$ ; that you are working over the integers rather than modulo something; that "the sequence" means the standard one rather than the Lucas numbers with the same recurrence but different seeds. None of these assumptions is wrong. But each is a choice, and each choice is inherited by every downstream term. Assumptions are the base cases of everything, and undeclared assumptions are the base cases you cannot recover — the silent inputs that shape every output and are visible to no one.

#Mathematical core

FACT. Change the base cases of $F_{n} = F_{n - 1} + F_{n - 2}$ from $(0, 1)$ to $(2, 1)$ and you get the Lucas numbers $2, 1, 3, 4, 7, 11, 18, \dots$ — the same recurrence, a completely different sequence, related to Fibonacci by identities such as $L_{n} = F_{n - 1} + F_{n + 1}$ .^[26] Change the precision of your arithmetic and you get a different answer for the ratio $F_{n + 1} / F_{n}$ — Chapter 3's convergence table depends on computing with enough precision. Change the indexing convention and every statement of the form " $F_{k} = \dots$ " shifts. In each case the assumption is invisible in the output — you see numbers, not the choices behind them — yet it wholly determines that output.

FACT. This is why the same recurrence, honestly applied by careful people, can produce disagreeing results: they made different, undeclared assumptions. The mathematics is not ambiguous; the assumption set was. Registering assumptions is what converts an ambiguous computation into a reproducible one.

#Odisena translation

CANON. Assumption is the RFPA move of declaring and registering the base cases, defaults, precision choices, model selections, and other inputs the system will inherit — so that outputs are reproducible and auditable.

METHOD. Maintain an assumption register: an explicit, versioned list of every assumption the system depends on, each with an owner, a rationale, and — ideally — a falsification test that would show the assumption to be wrong. When an assumption changes, you do not silently edit outputs; you branch, recording the change as a new version, because changing an assumption changes every downstream state. The quantum estimator described later states this precisely: it versions the assumption set — the model family, the measurement convention, the precision, the state assumptions — and treats an assumption change as creating a new branch rather than rewriting prior cycle records.^[27]

#Boundary note

INTERPRETATION. Not every assumption deserves the same weight, and pretending otherwise buries the important ones in noise. The assumptions worth registering with care are the load-bearing ones — the choices that, if wrong, would invalidate conclusions — and especially the ones that are contestable, where a reasonable person might choose differently. My interpretation: a register that lists a thousand trivial assumptions is nearly as useless as one that lists none, because the load-bearing ones are lost in it. Register the assumptions whose falsity would matter.

#Applied CASE

CASE. In device-recovery work, a critical assumption is the irrecoverable criterion: the declared, in-advance definition of when a device should be judged unrecoverable. If left implicit, this assumption gets made in the heat of a frustrating session, inconsistently and unrecorded. The Odisena field-validation failure-response plan makes it explicit: it defines irrecoverable criteria for specific devices in advance, preserves the highest partial state reached, requires a diagnostic-freeze artifact, and imposes a waiting period before any formal irrecoverable call.^[28] The assumption "here is what counts as unrecoverable" is registered before it is needed, so the eventual call is auditable rather than arbitrary.

#Failure mode

The failure mode is the undeclared assumption — the base case you cannot recover. Its signature is irreproducibility: two runs, two people, two dates produce different results and no one can explain why, because the differing assumption was never written down. A subtler form is the silently changed assumption, where someone alters a default or a precision or a model choice and edits the outputs to match, destroying the record that the assumption ever differed. Both are cured by the register: declare assumptions up front, branch when they change, and never edit an output to hide an assumption shift.

#Reusable protocol — The Assumption Register

Maintain a versioned register in which each entry has:

The assumption, stated precisely (the analogue of " $F_{0} = 0, F_{1} = 1$ ").
The owner — who is accountable for it.
The rationale — why this choice rather than an alternative.
The falsification test — what observation would show this assumption is wrong.
The blast radius — what conclusions depend on it, and therefore what must be revisited if it changes.
Change discipline — when the assumption changes, record a new version/branch; never silently edit downstream outputs.

#Validation questions

Can you list your system's load-bearing assumptions, or would you have to reconstruct them?
For each, is there an owner and a falsification test?
If a result of yours were disputed, could you show which assumptions produced it?
When was the last time an assumption changed — was it branched and recorded, or silently absorbed?

#The assumption that hides in the tooling

CASE. The most dangerous assumptions are often not the ones you make consciously but the ones your tools make for you. Return to the ratio table of Chapter 3. Computing $F_{n + 1} / F_{n}$ to six decimal places assumes your arithmetic carries at least that much precision — an assumption you never stated, because the tool made it silently. Push far enough (large $n$ , or a different computation involving $φ$ ) and floating-point arithmetic will quietly lose precision, and your "converging" ratios will start to wobble in the low digits for reasons that have nothing to do with Fibonacci and everything to do with an unstated assumption about your number representation. The output looks like a mathematical result; it is partly an artifact of the tool. The remedy is to surface the tooling's assumptions into your register: what precision, what number type, what rounding mode, what library version. These are load-bearing assumptions even though no human chose them deliberately, and when a result is disputed, they are exactly the assumptions no one thought to record. A register that captures only human-chosen assumptions and ignores tool-imposed ones will still leave you unable to reproduce your own results.

INTERPRETATION. This generalizes well beyond arithmetic. Every layer of tooling — the framework, the runtime, the platform, the model — injects defaults you did not choose and may not know about, and each of those defaults is an inherited assumption that shapes your outputs. Reproducibility, in the end, is nothing more than the discipline of having recorded enough assumptions — chosen and inherited — that someone else, or your future self, can recreate the exact conditions that produced a result. The gap between "it works on my machine" and "it works" is precisely the set of assumptions that were true on your machine and were never written down.

#Bridge

We now have all four RFPA moves: Recover, Field, Principal, Assumption. Individually, each frames one aspect of a system before it grows. But they are meant to work together, as a single preflight run before any loop opens. The final chapter of Part II assembles them into one protocol — the complete frame you set before you allow the Infinity Engine to turn.