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

Name the Principal

#Opening signal

Strip the Fibonacci sequence of everything but one thing, and what remains? Not the numbers — those are outputs. Not the base cases — those are inputs. What remains, and what is the sequence in any meaningful sense, is the rule: add the previous two. That rule is the principal. It is the governing generator, and everything the system does is an expression of it. Name the wrong principal, or leave it unnamed, and you have a system that produces states with no governing logic — a sequence of numbers with no rule connecting them, which is to say, no sequence at all.

#Mathematical core

FACT. The recurrence $F_{n} = F_{n - 1} + F_{n - 2}$ is the generator of the sequence, but the generator is accompanied by invariants — relationships that remain true no matter how far the sequence runs, and which therefore serve as tests of correctness. The most elegant is Cassini's identity: $F_{n - 1} F_{n + 1} - F_{n}^{2} = (- 1)^{n},$ which holds for every $n$ .^[23] There is also the summation identity $\sum_{i = 1}^{n} F_{i} = F_{n + 2} - 1$ , the identity $F_{1}^{2} + F_{2}^{2} + \dots + F_{n}^{2} = F_{n} F_{n + 1}$ , and the fundamental "addition formula" $F_{m + n} = F_{m} F_{n + 1} + F_{m - 1} F_{n}$ .^[24] Each of these is a consequence of the principal — the recurrence — and each can be used backward, as a check: if a computed term violates Cassini's identity, the term is wrong, guaranteed, without recomputing the whole sequence.

FACT. This is the deep point about a principal: a good generating rule brings its own invariants, and those invariants are the cheapest, most reliable validators you will ever have. You do not have to trust the process; you can test the output against a relationship the principal guarantees.

#Odisena translation

CANON. Principal is the RFPA move of naming the governing rule, generator, or invariant that every future state of the system must obey. (Note the spelling: principal as in the governing, primary rule — not principle as in a general truth.)

METHOD. Name your system's principal explicitly, and — this is the move most people miss — derive its invariants and use them as validators. In a codebase, the principal might be a core contract or schema; its invariants are the properties every valid state must satisfy, checkable cheaply at any moment. In a governance system, the principal is the amendment rule; its invariant is that predecessors are preserved and the chain has no gaps. Naming the principal is not enough; the payoff comes from extracting the invariants it guarantees and turning them into automatic checks.

#Boundary note

INTERPRETATION. It is tempting to think a system can have many principals — that governance is a committee of rules. In my experience the systems that stay coherent have one principal per loop, with everything else derived from or subordinate to it. Multiple co-equal governing rules tend to conflict, and when they conflict, there is no principled way to resolve them, so the resolution becomes political or arbitrary. The interpretation I hold: name one principal, make everything else a consequence, and when you are tempted to add a second co-equal rule, ask whether it is really a derived invariant of the first.

#Applied CASE

CASE. The Odisena v8 governance chain has a clear principal: regenerate, do not patch — preserve every predecessor amendment verbatim, then rebuild the tracker and dashboard artifacts rather than editing them in place. From this single principal flow the system's invariants: the amendment chain has no gaps; every superseded version still exists; the "head" of the chain always points to the latest amendment while all prior amendments remain on disk. When the chain advanced to registry version 17, it did so by preserving versions 15 and 16 and all the amendments from the twenty-fourth through the thirty-sixth, while moving the head forward — the principal enforced, the invariants intact.^[25] The invariant "no predecessor is lost" is checkable at any moment and is the cheapest possible validator of the whole chain's integrity.

#Failure mode

The failure mode is the unnamed or multiple principal: a system whose governing rule is implicit, or which has several conflicting rules with no priority among them. The symptom is that no one can answer "what rule must every state obey?" cleanly, and disputes get resolved by whoever argues hardest rather than by appeal to the principal. A related failure is naming a principal but never deriving its invariants, so the rule exists on paper but nothing checks that states actually obey it. The fix: one named principal per loop, plus explicit invariants used as automatic validators.

#Reusable protocol — The Invariant and Rule Card

On a single page, record:

The principal. State the one governing rule or generator in a single sentence.
The invariants. List the relationships that must hold for every valid state as consequences of the principal.
The cheap checks. For each invariant, state the cheapest test that detects a violation (the analogue of Cassini's identity — a check far cheaper than recomputing everything).
The response to violation. What happens when an invariant fails? (It should block promotion — see Part III.)
The subordination note. Confirm that every other rule in the system is derived from or subordinate to the principal, not co-equal with it.

#Validation questions

Can you state your system's principal in one sentence?
What invariants does that principal guarantee, and do you check them automatically?
Do you have a cheap check — cheaper than full recomputation — that detects a bad state?
Are there any co-equal rules that conflict with the principal, and if so, which one wins?

#The discipline of one principal — an extended argument

INTERPRETATION. I claimed above that a coherent loop has exactly one principal, and I want to defend that claim, because it runs against a common instinct to hedge by naming many rules. The problem with many co-equal governing rules is not that they are individually wrong; it is that they are guaranteed, eventually, to conflict, and a system of co-equal rules has no principled way to resolve a conflict. When two co-equal rules disagree about what the next state should be, the resolution is decided by whoever is in the room, or by which rule was checked first, or by the accident of implementation order — none of which is governance. It is the absence of governance dressed in governance's language.

A single principal, by contrast, gives conflicts a home. When something that looks like a competing rule arises, the single-principal discipline forces a clarifying question: is this new rule derived from the principal (in which case it is an invariant, subordinate, and conflicts are resolved by appeal to the principal) or does it genuinely contradict the principal (in which case one of them must go, and the choice is explicit rather than accidental)? Either way the conflict is surfaced and resolved by reference to a single source of authority. This is exactly how legal and constitutional systems work: not by having many co-equal supreme rules, but by having one supreme rule from which all others derive their authority and against which all conflicts are adjudicated. The systems that stay coherent over time are the ones that can always answer "by what authority?" with a single, stable answer.

#Bridge

We have recovered the state, fielded the boundary, and named the principal. One RFPA move remains, and it is the one that quietly determines everything: the assumptions. Every base case, every default, every unstated model choice shapes the output. The next chapter is the Assumption move — declaring, and registering, the choices the system will inherit forever.