There's a line I wrote early in the design documentation that now works as a test for practically every system decision involving chance: "the Ordem's scientific interpretation can be wrong; the server's arithmetic cannot." I started out writing it as a nice piece of lore. Only later did I understand it's also an engineering constraint — and an engineering constraint costs real work, not just text.
The problem the promise creates all on its own
If I promise the odds are public — base appearance rate, modifiers, pity, counter, effective rate, all visible — that means, without exception, that any dedicated player can calculate the real rate by dividing confirmations by observations. There's no middle ground here: either I publish enough data for the community to audit the math, or I don't publish it and the promise turns into an empty slogan. I chose to publish, knowing this means the system's secret can never live in the number — it can only live in the seed and the implementation of the random generator, which is where it should live anyway.
Why there are two layers of record, not just one
The Ordem's Registro is global and permanent: first confirmation of each species, authorship, global observation count, scientific status, odds published once for everyone. The Caderno de Campo is per account: each player's personal arc going from Apócrifo to Catalogado, their own sightings, their own containments, their own history.
The reason there are two, and not just one, is a problem I only spotted late: if there were only a single global Registro, the most dedicated players would catalog all one hundred and twenty beta species in the first week, and every new player who joined afterward would find a world that was one hundred percent cataloged — the entire arc of discovery, which is one of the reasons to play, would die at launch for anyone showing up a month late. Splitting the two layers solves this without inventing new mechanics: both terms already existed in the game's vocabulary, I just hadn't realized they needed to be separated until I designed the onboarding flow for a player who joins late.
The statistical standard I had to learn to use properly
Publishing raw counts of rare events is misleading without context — if a species has three confirmations out of a hundred observations, that's not the same thing as three confirmations out of three observations, even though the number "three" looks identical on both screens. That's why the Registro's expanded audit uses a 95% Jeffreys interval (the technical formula is Beta(k+0.5, n−k+0.5), appropriate specifically for rare events, where simpler statistical methods behave badly). And a species only leaves the "uncalibrated" state after accumulating at least fifty natural confirmations, with a relative margin narrow enough and a sample collected after the current version of the rule — if the base rate changes, the old sample no longer counts toward calibration.
That means that, for a while, the game itself will publicly admit "I don't have enough data yet to confirm this rate" — and I decided that's preferable to faking confidence I don't have.
What stays off the everyday screen, on purpose
Not everything I publish makes it onto the Caderno de Campo's main screen — some things live in an expanded audit layer, visible to anyone who looks for it, but not pushed at people who just want to play: aggregate participation of VIP players, the full statistical interval always available, the "uncalibrated" state flagged even for an already-cataloged species when the sample is still too thin. And there's a line I wrote as an explicit warning to myself, not just to the player: any inference that mixes appearance with containment is misleading, because the simple ratio of confirmations divided by observations doesn't represent the real base rate when pity, VIP, modifiers, and rule version changes are all operating at the same time, stacked on top of each other. It's easy, looking only at the final number, to think the math is simple. It isn't, and pretending it is would be just another way of lying with true data.
The tension I decided to accept instead of resolve
There's an inevitable consequence of publishing cumulative counts: the community will be able to infer the real base rate anyway, with growing precision, just by cross-referencing the numbers I already publish. There's no way to disclose exact counts and keep the base rate secret at the same time — the two things are mathematically mutually exclusive. I accepted this as part of how the system works, not as a bug to fix. The secret never needed to live in the rate. It needs to live in how the random generator is implemented and seeded, which is the only place where secrecy actually protects anything.
What I haven't finished yet
The public counter conversion for when the base rate or the pity ceiling gets recalibrated someday — which needs to happen without wiping out anyone's accumulated progress — already has a finalized, published formula, but it's never run in real production, with real counters from real players in the mix. It's the kind of thing that only proves itself right on the day I actually need to use it, and I'd rather you know the formula exists and hasn't been battle-tested yet than let you think it already has.