What rule decides which platform answers a fixed-memory approximate sketch may serve, and which it may never?

## What is actually being decided A fixed-memory sketch buys a footprint that does not grow with the input, and pays for it in certainty. That is a genuine engineering trade and the platform's job is not to ban it — banning it means paying for exactness nobody asked for, in the one place where memory is the scarce resource. The job is to say **which answers may be bought that way**, in terms a reviewer can apply without re-deriving the argument each time. ## The three tests 1. **Tolerance is stated as a number.** The consumer says what error it accepts — a percentage for a count, a rate for a membership answer — and the structure's published bound sits inside it. 'Approximate is fine' is not a tolerance; it is a sentence written by someone who has not asked the person who reads the number. Be explicit about the *kind* of bound too: a relative error means the absolute gap grows with the answer, and a quoted figure is often a typical deviation rather than a ceiling every reading respects. 2. **The consequence is reversible or confirmed.** Follow the answer to the action. If the uncertain direction fires something irreversible or visible to a user, an authoritative read goes in front of that branch or the sketch does not serve it. The certain direction — on membership structures, the 'no' — may be acted on alone. 3. **The estimate is labelled at the boundary.** An approximate number that crosses a service boundary in a field called `count` becomes exact the moment somebody else reads it. Name the field so its nature travels — an estimate, with its bound alongside — and keep a documented path to the authoritative figure for anyone who needs it. ## Where the answer must be exact regardless | kind of answer | may a sketch serve it | why | |---|---|---| | operational dashboard of distinct activity | yes | a percentage of error changes no decision | | suppressing optional, repeatable background work | yes | the wrong answer costs work, not correctness | | anything a person can dispute — money, entitlement | no | the disputed figure must be reproducible from a record | | a figure two systems reconcile against | no | two estimates never agree, and nobody can say which is right | | an irreversible, user-visible action on the uncertain direction | no | the failure is silent and there is nothing to retry | The recurring failure in real platforms is not the first row; it is a number that started life on the left of this table and drifted to the right, because it was convenient and nobody re-read where it came from. ## What this tier adds to the rule The sketch is an ordinary entry on a volatile tier, and two consequences belong in the rule: - **It can vanish.** A restart, a failover or pressure at the memory ceiling can remove it, and what a store keeps across a restart differs widely across this class — some keep nothing, others write a point-in-time copy or a log of writes. So the rule is not merely 'the estimate is not exact' but 'the estimate is not the record': every sketch has a named authoritative source it can be rebuilt from, and every consumer has a stated behaviour for the empty case, where membership answers 'nothing seen' and a distinct count answers zero. - **Comparisons across time need somewhere durable.** Reading today's estimate against last month's only works if the readings were copied out to a durable place as they were taken. The entry that produced last month's number is long gone. ## Who owns the structure when the store does not offer it Not every store in this class provides these structures server-side; some do, some only through an add-on, and some not at all. Where the server does not, the sketch lives in the application and the store holds it as opaque bytes — which changes the ownership question, not just the code. Every addition becomes a read-modify-write round trip, concurrent writers can overwrite each other's additions, and the remedies for that race are the caller's problem rather than the server's. A platform rule that assumes the server-side form will not survive a move to a store that has no such thing. ## Making it enforceable A rule that lives on a wiki page is not a rule. Three things make this one hold: - **Put the tolerance in the interface.** A field named as an estimate, carrying its bound, is read correctly by people who never saw the design document. - **Ask one question in review:** what happens if this specific answer is wrong, and who finds out? If the honest answer is 'nobody', the confirmation step is missing. - **Record the sizing assumption with an owner.** The error rate was derived from a forecast population; on a growing service that forecast expires, and an unowned assumption becomes an accuracy claim nobody re-checks.