What your claim excludes

Somewhere in our platform documentation there is a list of things our product may not be called. Not zero knowledge. Not fully client-held confidentiality. Not local-only, and not universal end-to-end encryption. An architecture document alongside it carries a companion list of phrases to avoid in presentation copy, each entry a sentence that would flatter the system and is not true at the maturity the system has reached, with the truer sentence written next to it so nobody has to invent a replacement under deadline.

Neither list is modesty and neither is legal caution. They are a specification of what our claims exclude, written by the people who know exactly where the sealing stops and handed to the people whose job is to make the thing sound good, before those people need it rather than after. The engineers are not being protected from the marketers. Both are being protected from the sentence that is only slightly too strong, which is the one that ships, because it survives every review by being almost true.

The mechanism is that an exclusion published by the claimant bounds what a reader is entitled to infer, while an exclusion discovered by the reader does the reverse, retroactively converting every unbounded claim standing beside it into something that looks like it was left unbounded on purpose. The asymmetry is brutal and it is not really about honesty. It is about who is doing the drawing. A boundary you draw is information. A boundary someone else draws is a finding.

The same instinct fits in one sentence. In a sync design note we state that we do not claim to eliminate the window in which already-synced data sits on a device after access has been revoked. That window is inherent to every system that lets people work offline, which is why the sentence generalizes past us to anyone shipping a mail client, a file sync folder, or a messaging app: the copy on the device outlives the revocation on the server, and no amount of policy language changes the physics. Saying so costs a paragraph. What it buys is the only kind of credibility that compounds, because a reader who finds one limit you volunteered stops auditing you for the ones you hid.

At consumer scale this has already become ordinary practice, which is worth knowing because it removes the excuse that customers cannot handle it. Apple publishes a table of iCloud data categories stating which iCloud data is protected end to end and which is held under standard protection, so the boundary of the encryption claim appears in the vendor’s own support documentation rather than in a researcher’s write-up or a court filing. The table is not an apology for the categories on the weaker side. It is the thing that makes the categories on the stronger side mean something, since a claim that covers everything covers nothing in particular.

There is a test buried in all of this that anyone can run today on their own product page. Take the strongest sentence on it, the one doing the most persuasive work, and try to write the boundary of that sentence in the same font. If the boundary is easy to write and merely unflattering, the claim is honest and the work is a paragraph. If the boundary is hard to write because you are not sure where it falls, you have found engineering to do rather than copy to fix. And if you know where it falls and cannot bring yourself to print it, then the claim was never doing the work you thought it was doing, and the version that survives contact with a skeptical reader is the one that told them where it ends.