Regenerate, Do Not Patch

#Opening signal

You have found the corrupted term. There are two ways to fix the sequence. The first: reach into the output and change the wrong numbers directly — patch them. The second: fix whatever caused the error in the canonical inputs, then regenerate the sequence from the corrected inputs, preserving the old version. The first is faster and feels efficient. The second is the discipline that keeps a system trustworthy over time. This chapter is the argument for the second, and it is, in a sense, the argument of the whole book: derived artifacts should be rebuilt from canonical rules and inputs, never edited in place, with predecessor versions preserved.

#Mathematical core

FACT. A Fibonacci table is a derived artifact: it is fully determined by the recurrence and the base cases. If the table contains an error, there are two repair strategies with very different properties. Patching changes the wrong entries directly. But patching is treacherous: if the error came from a wrong base case or a misapplied rule, patching the visible symptoms leaves the cause in place, and the error will reappear the next time the table is extended or regenerated. Worse, a patched table is no longer reproducible from its inputs — run the generator again and you get a different (still-wrong) table, so the artifact and its source have silently diverged. Regenerating fixes the base case or the rule and rebuilds the entire table from them. The corrected table is once again exactly what the inputs produce, and the divergence between source and artifact is closed. The mathematical property that makes regeneration possible is determinism: the same inputs and rules always produce the same output, so the output can always be rebuilt rather than hand-repaired.

FACT. Determinism is also what makes verification possible. If a table is regenerated from inputs, anyone can re-run the generator and confirm they get the same table — the artifact is checkable against its source. A patched table fails this check, because it no longer matches what its source produces. Regeneration keeps source and artifact in provable correspondence; patching breaks it.

#Odisena translation

CANON. Regenerate, do not patch: derived artifacts are rebuilt from canonical inputs, and predecessor versions are preserved. Editing a derived output in place is forbidden; the fix goes to the source, and the artifact is regenerated.

METHOD. Maintain a single canonical source and treat every other artifact — reports, dashboards, print files, electronic editions, catalog metadata — as derived and disposable, regenerable at any time from the source. When something derived is wrong, fix the source and regenerate; never hand-edit the derived output. The Odisena governance chain states this as its core rule: it preserves predecessor amendments verbatim, then regenerates the tracker and dashboard artifacts rather than patching them in place, so that the derived views are always exactly what the canonical amendments produce.^[49] This book itself is built this way (Chapter 25): one canonical manuscript source, from which the print interior, the electronic edition, and the metadata are all regenerated.

#Boundary note

INTERPRETATION. Regeneration has a real cost — it requires that your derived artifacts can be rebuilt from source, which requires deterministic, reproducible build tooling, which is work. It is tempting, under deadline, to "just patch this once." My interpretation, from painful experience: the one-time patch is almost never one-time. It diverges the source from the artifact, and every future regeneration either overwrites the patch (reintroducing the error) or is quietly abandoned (so the source rots). The boundary is honest: regeneration is worth building toward whenever an artifact will be rebuilt more than a few times, and the patch that "just this once" avoids the investment is the beginning of the source-artifact divergence that eventually makes the whole system unmaintainable.

#Applied CASE

CASE. A public knowledge corpus must stay synchronized across three stores — a version-controlled repository, and two separate knowledge databases. The patch approach edits each store by hand when something changes, and the three inevitably drift apart. The regenerate approach designates one canonical source and deterministically reconciles the others from it. The Odisena collective system does exactly this: it reconciles its three replicas through a deterministic sync engine, and a later change made the scheduled runner invoke a single executable so that orchestration could never override a clean no-op — that is, so the regeneration is deterministic and cannot be silently corrupted by the machinery around it.^[50] The three replicas stay in correspondence because they are all regenerated from one source, not patched independently.

#Failure mode

The failure mode is the in-place patch: editing a derived artifact directly, leaving the canonical source unchanged and the cause of the error in place. Its signatures are source-artifact divergence (the output no longer matches what the source produces), error recurrence (the fix vanishes on the next regeneration because the cause was never addressed), and unverifiability (no one can confirm the artifact against its source). The most insidious form is the abandoned generator — once patched artifacts diverge, teams stop regenerating at all, the source rots, and the system loses the very reproducibility that made it trustworthy. The fix is absolute: derived artifacts are read-only outputs; all changes go to the source; regeneration is the only path to a new output.

#Reusable protocol — The Regeneration Discipline

1. Designate the canonical source. Exactly one source of truth per derived-artifact family.
2. Enumerate the derived artifacts. List everything regenerated from the source; mark each read-only.
3. Make the build deterministic. Same inputs → same outputs, verifiably (the analogue of re-running the Fibonacci generator).
4. Forbid in-place edits. Any change to a derived artifact goes to the source; the artifact is then regenerated.
5. Preserve predecessors. Every regeneration produces a new version; prior versions are kept, marked superseded.
6. Verify correspondence. Periodically confirm each derived artifact still matches what the source produces.

#Validation questions

1. Do you have exactly one canonical source per family of derived artifacts, or several drifting copies?
2. Is your build deterministic — same inputs, same outputs, verifiably?
3. When was the last time you patched a derived artifact in place, and did the source diverge?
4. Could you regenerate every derived artifact from source right now, or has some generator been abandoned?

#The economics of regeneration versus patching

INTERPRETATION. The argument for regeneration is usually made on grounds of correctness — patching leaves the cause in place, diverges source from artifact, and so on — but there is an economic argument that is, in practice, more persuasive to the people who have to do the work, and it is worth making explicitly. Patching is cheap now and expensive later; regeneration is expensive now and cheap later. The patch takes ten minutes today and costs you, over the life of the system, a slow accumulation of divergence, recurring errors, and eventually an abandoned generator and a rotted source — a debt that compounds silently and comes due at the worst possible moment, usually during an urgent correction when you can least afford to discover that your source no longer produces your artifact. Regeneration takes an investment up front — you must build a deterministic, reproducible build — and then costs almost nothing per correction forever after, because every fix is just a source edit and a rebuild.

The reason teams choose patching anyway is a well-known cognitive trap: the cost of patching is immediate and visible (ten minutes, and the fire is out), while the cost is deferred and diffuse (a little divergence, spread across months, attributable to no single decision). Human beings systematically undervalue diffuse future costs against concrete present ones, which is exactly why the patch feels rational in the moment and proves ruinous in aggregate. The regenerate-not-patch discipline is, at bottom, a precommitment device against this trap — a rule you adopt while calm so that you do not have to re-decide, under the pressure of each individual fire, whether this particular patch is "worth it." It almost always feels worth it, and it almost never is. The discipline is to have decided already.

#Bridge

Regeneration turns a validated seed into a reliably reproducible output. The next natural question is how a single validated pattern becomes many reusable systems — how a proven loop scales into a family of variants without losing its governance. The next chapter is about scaling the signal: the Founding Loop, and the maturity ladder from one seed to a hundred systems.