Attempt the Next Term

#Opening signal

The recurrence is a promise, not a result. $F_n=F_{n-1}+F_{n-2}$ tells you how to attempt the next term, but the attempt is not the answer until it has been carried out and, as the next chapters insist, validated. There is a discipline in treating the next state as a candidate rather than a fact — a thing you have proposed, not yet a thing you have accepted. Most systems collapse this distinction, treating whatever they just computed as automatically true. The Attempt beat is the refusal to do that: it generates a candidate, clearly labeled as such, and hands it forward for judgment.

#Mathematical core

FACT. To attempt $F_{10}$, take the preserved predecessors $F_9=34$ and $F_8=21$ and apply the rule: $34+21=55$. The candidate is $55$. Note the structure of a well-formed attempt: it has declared inputs (the two predecessors), a declared operation (addition, per the principal), and a produced output (the candidate). Each of these is recorded, so that the attempt can later be checked and, if wrong, diagnosed — was the input wrong, or the operation, or the arithmetic? An attempt that records only its output is an attempt you cannot debug.

FACT. The attempt is also where cost is realized, connecting to Chapter 5. The same candidate $F_{10}=55$ can be attempted by the naive recursion, the iteration, memoization, or matrix exponentiation, and the choice of method is part of the attempt. A disciplined attempt therefore also records how the candidate was produced, not merely what it is, because the method affects both the cost and the failure modes.

#Odisena translation

CANON. Attempt is the AVPT beat of generating a candidate next state according to the principal, with declared inputs, operation, and output — explicitly as a candidate, not yet as an accepted fact.

METHOD. Structure every attempt as a candidate record: inputs (which preserved prior states), operation (which rule, which method), output (the proposed new state), and cost (time, memory, money spent). Label it a candidate. Do not let it become canonical merely by existing. This is the single most important habit-shift the method asks for: the thing you just made is a proposal, and proposals are validated before they are accepted. In model-assisted work this is the difference between "the model produced X, so X is our answer" and "the model produced candidate X; now we validate."

#Boundary note

INTERPRETATION. There is a school of thought that says candidate/accepted distinctions are overhead — that for simple, reliable operations you should just trust the output. For a single addition, sure. But my interpretation, learned the hard way, is that the discipline is cheap to keep and expensive to add back later. The systems that get burned are the ones that trusted outputs when the operation was "reliable," right up until the day the operation was subtly wrong and there was no candidate stage at which to catch it. The boundary: the more consequential or irreversible the state, the less optional the candidate discipline.

#Applied CASE

CASE. In a deployment pipeline, the Attempt beat is the canary: a change is applied not to the whole fleet but to a limited surface, explicitly as a candidate, with its inputs (the change set), operation (the deployment), and output (the new behavior) recorded. The Odisena AVPT CI/CD work embodies this — its rollout across the repository fleet was deliberately marked dry-run and non-destructive, SHA-pinned and inert, precisely so that attempts could be made and observed without being mistaken for accepted, production-committed states.^[30] The candidate deployment is an attempt; promoting it to production is a separate, later decision. Collapsing the two is how a bad change reaches every server at once.

#Failure mode

The failure mode is the accepted attempt: treating a freshly generated state as canonical the moment it exists, with no candidate stage and no record of how it was produced. The symptoms are outputs that cannot be debugged (no recorded inputs or operation) and changes that go straight to production (no candidate/accepted boundary). This failure feels like speed and is actually the removal of the only point at which errors are cheap to catch. The fix is structural: every next state is born a candidate, with a full record, and becomes canonical only by passing the gate of Chapter 15.

#Reusable protocol — The Candidate-State Template

For every attempted next state, record:

1. Inputs. Which preserved prior states did the attempt consume?
2. Operation. Which rule/principal, and which method, was applied?
3. Output. What is the proposed new state? (Labeled explicitly as a candidate.)
4. Cost. Time, memory, money, latency spent producing it.
5. Status. Candidate — pending validation. (Never "accepted" at this stage.)

#Validation questions

1. Does your process distinguish a candidate state from an accepted one, or do outputs become facts by existing?
2. For your last attempt, could you state its inputs, operation, and cost — or only its output?
3. If an output were wrong, could you diagnose whether the input, operation, or method failed?
4. What is the most consequential state your system currently accepts with no candidate stage?

#Candidates all the way down

INTERPRETATION. The candidate/accepted distinction seems like a small bookkeeping nicety, but it reshapes how a system relates to its own outputs, and the shift is profound enough to deserve a name: it is the difference between a system that believes itself and a system that checks itself. A system without the distinction treats every output as immediately true — it believes itself — and therefore has no internal surface on which doubt can operate. There is no moment at which the system holds a result at arm's length and asks whether it should be trusted, because the moment of production and the moment of acceptance are fused. A system with the distinction inserts exactly that surface: between "produced" and "accepted" there is a gap, and into that gap you can place validation, review, and judgment. The gap is where all the safety lives.

This is why the discipline matters most precisely where it feels least necessary — in systems that are usually right. A system that is usually right is a system whose operators stop looking, because looking rarely finds anything, and a system whose operators have stopped looking is a system with no candidate stage in practice even if it has one on paper. The rare wrong output then sails through unexamined, because the examining habit has atrophied. The candidate discipline is a commitment to keep the gap open and the examining habit alive even when it is usually unrewarded, on the understanding that its entire value is concentrated in the rare case, and that you cannot know in advance which case that will be. It is insurance, and like all insurance it feels wasteful right up until the moment it is the only thing that saves you.

#Bridge

We have a candidate. It is a proposal, not yet a fact. The next beat is where proposals earn or fail their promotion: Validate. A candidate that has not been tested against the principal's invariants and an independent check is not knowledge — it is a hopeful guess with good formatting.