RFPA Before Expansion

#Opening signal

A rocket's launch is preceded by a preflight checklist not because engineers are timid but because the cost of discovering a bad assumption after ignition is catastrophic and irreversible. RFPA is the preflight for growth. The four moves are not independent chores; they compose into a single frame, and the quality of that frame determines whether everything that follows can be trusted. This chapter assembles Recover, Field, Principal, and Assumption into one preflight you run before opening any Infinity Engine loop — because framing quality, not execution speed, is what makes later states trustworthy.

#Mathematical core

FACT. Consider how the four moves interlock for the Fibonacci sequence itself. Recover: to continue, you need the adjacent pair $(F_n,F_{n-1})$, verified. Field: you declare zero-indexing, integer arithmetic, the standard sequence. Principal: the rule is $F_n=F_{n-1}+F_{n-2}$, with invariants like Cassini's identity available as checks. Assumption: base cases $F_0=0,F_1=1$, registered. With all four in place, the sequence is fully determined, reproducible, auditable, and reversible. Remove any one and it degrades: no recovered state, and you cannot continue; no field, and comparisons are meaningless; no principal, and there is no rule; no declared assumptions, and the output is irreproducible. The four are not a list; they are a frame, and a frame is only as sound as its weakest side.

#Odisena translation

CANON. RFPA — Recover, Field, Principal, Assumption — is the complete framing that precedes any growth cycle. It is set once per loop and revisited explicitly when assumptions change. The AVPT beats of Part III execute inside the frame RFPA establishes.

METHOD. Run the four moves as a single preflight before opening a loop, and treat the preflight as a gate: if any of the four is incomplete, the loop does not open. This is the practical heart of the method. The Odisena field-validation recovery plan is built exactly this way — its recovery plan maps every step to RFPA moves and AVPT beats, with explicit anti-pattern gates, so that the frame is verified before execution and no cycle begins on an unframed foundation.^[29]

#Boundary note

INTERPRETATION. The preflight can become a ritual — checked off without being thought about — which is worse than no preflight because it manufactures false confidence. The interpretation I hold: RFPA is valuable only when each move can genuinely fail and stop the loop. A preflight that always passes is not checking anything. Build the frame so that "Recover incomplete" or "Assumption unregistered" is a real, common outcome that really does block the loop, and the frame will earn its keep. A frame that never says no is decoration.

#Applied CASE

CASE. A team is about to open a new loop — say, a staged migration. The RFPA preflight runs. Recover: is the pre-migration state verified and reversible? Confirmed. Field: is the scope declared, with exclusions (which systems are out) and conventions (naming, ordering)? Confirmed. Principal: what rule governs the migration, and what invariant proves each step correct? Named. Assumption: are the load-bearing assumptions — data volume, downtime tolerance, rollback window — registered with owners? One is missing: no one has declared the acceptable downtime. The preflight fails on Assumption, and the loop does not open until that assumption is registered. This is the frame working: it caught the undeclared base case before ignition, when the cost of fixing it was a conversation rather than an outage.

#Failure mode

The failure mode is expansion before framing: opening a growth loop with an incomplete frame, usually under schedule pressure, on the theory that framing can be "backfilled later." It never is. The unrecovered state, the implicit field, the unnamed principal, the undeclared assumption all persist, and they surface as unrecoverable, unauditable, irreproducible states downstream — at which point backfilling the frame is impossible, because the evidence needed to do so was the very thing the frame would have preserved. The fix is to make the preflight a hard gate that expansion cannot bypass.

#Reusable protocol — The RFPA Preflight

Before opening any Infinity Engine loop, complete and verify all four; if any fails, the loop does not open:

1. Recover — Is the prior state reconstructed, verified, and reversible? (Chapter 6 worksheet.)
2. Field — Is the boundary declared, with scope, exclusions, conventions, and audience? (Chapter 7 declaration.)
3. Principal — Is the governing rule named, with invariants and cheap checks? (Chapter 8 card.)
4. Assumption — Are load-bearing assumptions registered, with owners and falsification tests? (Chapter 9 register.)
5. Gate — Confirm every move can genuinely fail. Only if all four pass does the loop open. Record the passed preflight as the loop's opening evidence.

#Validation questions

1. Could you run all four RFPA moves as a single preflight for your next piece of work right now?
2. Which of the four is weakest in your current practice — and therefore your frame's weakest side?
3. Has your preflight ever actually stopped a loop, or does it always pass?
4. When you feel schedule pressure to skip framing, what is your rule for resisting it?

#RFPA as a whole: the frame is a system, not a sequence

INTERPRETATION. It is tempting to run the four RFPA moves as a linear checklist — Recover, then Field, then Principal, then Assumption, tick, tick, tick, tick — but the deeper truth is that they are interdependent, and running them once in order rarely gets them right. Fielding often reveals that you recovered the wrong state (you recovered the production state when the boundary you actually care about is staging). Naming the principal often reveals a hidden assumption (the rule you thought was governing turns out to depend on an unstated precision or convention). Registering assumptions often forces you to re-field (an assumption's blast radius crosses a boundary you had not drawn). The moves are a system that you iterate until it is internally consistent, not a sequence you traverse once. A good preflight usually loops through the four moves two or three times before they lock into a coherent frame, each pass tightening the others.

This is why the preflight is a genuine gate and not a formality. If the four moves were independent, you could complete them in any order and never revisit them, and the whole exercise would be bureaucratic theater. Because they are interdependent, the act of completing them forces the inconsistencies to the surface — the recovered state that does not fit the field, the assumption that violates the principal — and forcing those inconsistencies to the surface before the loop opens, when they are cheap to fix, is the entire value of the frame. The frame earns its keep precisely in the cases where completing it is hard, because a frame that is hard to complete is a frame that is telling you something you needed to know before you started growing.

#When the frame legitimately changes mid-flight

INTERPRETATION. A fair objection to RFPA is that it sounds rigid: set the frame once, then never touch it. Real work is not like that — you learn things mid-flight that should change the frame. The method's answer is not that the frame never changes but that frame changes are governed events, not silent drift. When you discover, three cycles into a loop, that an assumption was wrong or a boundary was mis-drawn, you do not quietly adjust the frame and pretend it was always so. You supersede the frame: you record the change explicitly, note which cycles ran under the old frame and which will run under the new one, preserve the old frame, and — crucially — reconsider whether the cycles already run under the old frame are still valid. This is exactly the supersession discipline of Chapter 15, applied to the frame itself rather than to a state. A frame change that is recorded, bounded, and forces re-examination of what it invalidates is legitimate governance; a frame change that is silent, so that later cycles run under a quietly different frame than earlier ones with no record of the shift, is precisely the drift the method exists to prevent.

This distinction — governed frame change versus silent frame drift — is the difference between a system that adapts and a system that decays. Both change over time; the adaptive system changes visibly, so that at any moment you can say which frame each part of its history ran under, while the decaying system changes invisibly, so that its history becomes a palimpsest of undocumented frame shifts that no one can untangle. The assumption register (Chapter 9) is where frame changes are recorded, and its branch-on-change discipline is exactly the mechanism: a changed assumption creates a new branch, the old branch is preserved, and the record shows the fork. RFPA is not a demand that you get the frame right the first time and never learn; it is a demand that when you do learn, you change the frame as a recorded, bounded event rather than as an untracked mutation. Learning is welcome. Forgetting that you learned is not.

#Bridge

The frame is set. Recover, Field, Principal, Assumption have established a system that knows where it stands, within what boundary, under what rule, on what declared assumptions. Now — and only now — may the system grow. Part III turns the frame into motion: the four AVPT beats that execute, over and over, inside the frame RFPA built. We begin with the first beat: the Attempt.