Chapter 1 · Part I — Foundations and Recurrence as an Explanatory Model

One, One, and the Next State

#Opening signal

Write down two numbers. Then, forever after, obey one rule: the next number is the sum of the previous two. Start with $0$ and $1$ , and the rule gives you $1$ , then $2$ , then $3, 5, 8, 13, 21, 34$ , and onward without end. You have just built the Fibonacci sequence, and you have also, without noticing, done something philosophically strange. You have created a process whose every future depends on its remembered past. There is no term you can compute in isolation. To know where the sequence goes next, you must hold on to where it has just been.

That small strangeness is the seed of this entire book. Most of the systems we build behave like a clock: they show a current state and quietly discard the previous one. The Fibonacci sequence refuses to. Its whole engine is memory. And it turns out that this refusal — the insistence on carrying forward preserved prior state — is exactly the property that separates systems that can recover from systems that cannot.

#Mathematical core

FACT. The Fibonacci sequence is defined by the recurrence $F_{n} = F_{n - 1} + F_{n - 2}, n \geq 2,$ together with the base cases $F_{0} = 0$ and $F_{1} = 1$ . A recurrence relation is an equation that defines each term of a sequence as a function of earlier terms; the base cases are the declared starting values that the recurrence itself cannot produce. Without base cases the recurrence is empty, because it has nothing to add. This is not a quirk of Fibonacci; it is true of every recurrence. A rule that generates the next state from prior states cannot generate the first states. Those must be declared.

The sequence has been studied for well over two millennia. It appears in the Chandaḥśāstra of the Indian scholar Piṅgala and in the work of later Indian mathematicians such as Virahāṅka, Gopāla, and Hemachandra, who counted the number of rhythmic patterns of a given total duration formed from short and long syllables — a counting problem whose answer is exactly the Fibonacci numbers.^[1] In the Latin West the sequence is named for Leonardo of Pisa, called Fibonacci, who in his 1202 book Liber Abaci introduced it to European readers through a stylized problem about the growth of a rabbit population.^[2] The name and the rabbit problem are historical facts about attribution and exposition; they are not evidence that rabbits, or anything else, are numerically governed by the sequence. We will return to that distinction with some force in Chapter 4.

The first terms, with our declared convention $F_{0} = 0, F_{1} = 1$ , are: $0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, \dots$

FACT. Different authors declare different base cases. Some begin $F_{1} = 1, F_{2} = 1$ ; some define a companion sequence, the Lucas numbers, with base cases $L_{0} = 2, L_{1} = 1$ obeying the same recurrence. The sequence you get depends entirely on what you declare at the start. This is worth dwelling on, because it is the mathematical fact from which the whole method of this book takes its first cue: the starting state is a choice, and every later state inherits that choice.

#Odisena translation

CANON. In the Odisena method, the four framing moves you make before a system is allowed to grow are called RFPA: Recover, Field, Principal, Assumption. The very first Fibonacci terms correspond to the Assumption move — the declared initial conditions, the base cases, the starting state you commit to before the rule takes over.

METHOD. When you begin any growing system — a codebase, a document, an organization, a model-assisted workflow — you are, whether you admit it or not, declaring base cases. You are choosing an initial state and a set of assumptions that the system will inherit forever. The discipline the sequence teaches is to make that declaration explicit and recorded, rather than letting it happen by accident. In Fibonacci, if you forget whether you started at $F_{0} = 0$ or $F_{1} = 1$ , every downstream term is ambiguous. In a real system, if you forget your initial assumptions, every downstream state is unauditable.

#Boundary note

INTERPRETATION. It is tempting to say the sequence "knows" its history, or that memory is somehow intrinsic to growth. That is a metaphor, and a useful one, but let us be exact about what is true. The mathematical fact is narrow: this particular class of rule — a recurrence — is defined in terms of earlier terms, and therefore cannot be evaluated without them. It is not a fact that all growth requires memory. Plenty of processes generate their next state from their current state alone, with no reference to the past; a simple compound-interest calculation is one. The claim this book actually makes is a design claim, labeled METHOD, not a law of nature: if you want a system you can validate and recover, build it so that its next state depends on preserved prior state, the way a recurrence does. That is a recommendation, not a theorem.

#Applied CASE

CASE. Consider a team maintaining a knowledge base — a wiki of project pages, each linking to others. One day a page is renamed. If the team treats the rename as a single forward motion, overwriting the old title, every inbound link breaks and no one can reconstruct what the page used to be called. Now suppose instead the team obeys a Fibonacci-like discipline: the new state is produced from the old state, and the old state is preserved. In practice this means the rename creates an explicit redirect record — old title, new title, reason, date — so the old name remains discoverable and every link still resolves. This is precisely the redirect convention used in the Helios 1 worldbuilding corpus, where renamed entries receive explicit redirect records and an architecture index so that old titles remain findable and nothing is silently lost.^[3] The rename is not a deletion; it is a next state computed from, and preserving, its predecessor.

#Failure mode

The characteristic failure of this chapter's principle is the undeclared base case. A system starts, someone makes an assumption — a default configuration, an unstated scope, an implied convention — and never writes it down. Everything works while that person is present and remembers. Then they leave, or six months pass, and no one can reconstruct why the system behaves as it does, because the initial conditions were never recorded. The system still runs, but it is now unauditable and unrecoverable from first principles. The failure is silent until the day you need to go back to the beginning, and discover the beginning was never written down.

#Reusable protocol — The Seed Declaration

Before you let any system grow, complete this declaration and store it with the system:

State the base cases. What are the exact initial values, configurations, or conditions? Write them down as literally as $F_{0} = 0, F_{1} = 1$ .
State the convention. Which of several possible starting conventions did you choose, and why? (Zero-indexed or one-indexed? Which defaults? Whose assumptions?)
State the rule that will govern growth. In one sentence, how is each next state produced from prior states?
State what must be preserved. Which prior states does the rule require, and therefore must never be discarded?
Store and version the declaration alongside the system, not in someone's memory.

#Validation questions

Can you state your system's base cases as precisely as $F_{0} = 0$ and $F_{1} = 1$ ?
If two reasonable people set up your system independently, would they choose the same starting convention? If not, is the choice recorded?
Which prior states does your growth rule require, and are they all preserved?
If everyone who set up the system left tomorrow, could a newcomer reconstruct its initial conditions from written records alone?

#A second worked example — the seed determines the species

FACT. To feel how completely the seed governs everything downstream, hold the rule fixed and change only the two starting values. With $F_{0} = 0, F_{1} = 1$ you get the Fibonacci numbers. With $L_{0} = 2, L_{1} = 1$ — the same "add the previous two" rule — you get the Lucas numbers: $2, 1, 3, 4, 7, 11, 18, 29, 47, \dots$ . With $P_{0} = 0, P_{1} = 1$ and a slightly different rule ( $P_{n} = 2 P_{n - 1} + P_{n - 2}$ ) you get the Pell numbers: $0, 1, 2, 5, 12, 29, 70, \dots$ . Three sequences, three utterly different families of numbers, produced by tiny differences in the declared starting state and rule. Nobody looking only at the outputs $2, 1, 3, 4, 7$ could reconstruct which rule and seed produced them without being told — which is exactly the point. The seed and the rule are the identity of the system; the outputs are merely its consequences. This is why the Seed Declaration below insists that you record the seed and the rule as literally as possible: they are the only things that make the outputs mean anything.

CASE. Consider two engineers who each set up "the same" logging system. One declares that timestamps are stored in coordinated universal time; the other declares local time with no zone recorded. Six months later, when the two logs are merged to investigate an incident, the events are off by hours and the sequence of cause and effect is scrambled — not because either engineer made a mistake in the rule (both logged correctly) but because the seed, the declared convention, differed and was never recorded alongside the data. The logs are the Lucas and Fibonacci numbers of the story: correct sequences produced by different undeclared seeds, impossible to reconcile after the fact. The failure is not in the rule; it is in the unrecorded starting convention, which is precisely the base case you cannot recover.

#Bridge

We have a starting state and a rule. But the rule has a demand we have only glanced at: it requires its predecessors. The next chapter takes that demand seriously and asks what it means to build on a rule that remembers — and what breaks the instant a required predecessor goes missing.