The Reader Contract

A contract states what each side owes the other. Here is mine to you, and what I ask of you in return.

What this book promises.

1. The mathematics will be correct and checkable. Every non-elementary mathematical claim is labeled FACT and cited to a public source. If you find an error, it is an error, and the regenerate-not-patch discipline described in this book means a corrected version will supersede this one with a recorded reason.

1. The method will be usable, not just admirable. Every chapter ends with a reusable protocol — a checklist, template, canvas, or schema — that you can lift out and apply to your own work. The appendices collect these into a working kit.

1. The boundaries will be explicit. Wherever the book crosses from fact into method, or from method into interpretation, it will say so with a label. You will never have to guess whether a sentence is a theorem, a recommendation, or an opinion.

1. The private will stay private. Where the book draws on real project work, it does so through privacy-safe abstractions. It contains no secrets, no credentials, no personal data, and no invention-enabling detail. What you get is the shape of the practice, not anyone's private keys.

What the book does not claim.

1. It does not claim that nature, markets, art, or organizations "obey" the Fibonacci sequence. Fibonacci is an explanatory model — a clean example used to teach a discipline. Chapter 4 and Chapter 26 are devoted almost entirely to drawing this line clearly.

1. It does not claim that the Odisena method is a mathematical theory. RFPA, AVPT, and the Infinity Engine are named practices. They are judged by whether they help you build recoverable systems, not by proof.

1. It does not claim that any platform submission, retail publication, or third-party review has been performed on your behalf. The publishing chapters describe how the book itself was produced and how you would prepare files for a platform; the act of uploading and the act of being reviewed remain yours.

What I ask of you.

Read the labels. Argue with the interpretations. Run at least one protocol on a real problem before you decide whether the method is worth your time. And if you take one idea from the book, take this one: regenerate, do not patch. When something derived from your work is wrong, do not quietly fix the output. Fix the source, rebuild the output, and keep the old version so you can always show your work.

That is the contract. Turn the page and we will begin where every sequence begins: with a declared starting state.