Skip to content

Topic · 6 articles

Honest claims

An honest claim is a harder document to write than either an evasion or a data dump, and it is the only one of the three that survives a second year. These articles walk what it contains, from the difference between a promise and a passing arrangement to the direction a system's failures fall. The order runs outward: what you say, whether anything backs it, where it stops, how it is presented, and what happens on the worst day.

Start reading The five-minute version

The through-line: The owed disclosure and What remains valuable , the long reads these articles expand on.

  1. 1 Start with the sentence you are about to publish, and the question that decides whether it is a promise or a piece of machinery you will regret describing. Guarantees, not shapes
  2. 2 Publishing the right sentence is only half of it, because a rule nothing enforces can be written in exactly the same confident voice as a rule that is. Candor about enforcement
  3. 3 Once you are honest about what holds, the next question is where it stops, and whether that boundary gets drawn by you or found by somebody else. What your claim excludes
  4. 4 Exclusions turn out to do more than keep a claim honest: what a maker refuses is the only legible statement of what it believes. The exclusions are the taste
  5. 5 A boundary you have written down and set in six-point grey has been disclosed and not communicated, which turns the whole problem into a design problem. Limits are content
  6. 6 End with the claim that cannot be softened later or added afterward, because it was decided the day the system was built. Which way failure falls

You have walked Honest claims end to end: the promise against the shape, the check against the request, the boundary you draw before someone else does, the limit given a place to live, and the direction your failures fall. None of it required publishing the machinery, which is the discovery that makes it affordable. Candor and confidentiality were never opposed.

Practice Take one promise your product, your resume, or your profile currently makes, and write four lines about it. Whether it is a guarantee or just how things happen to be arranged right now. Whether anything actually checks it, or whether it is only requested. What it excludes, in the same plain words as the promise itself. And which way it fails when it fails. Then fix the wording rather than the reader, because every one of those four lines was already true before you wrote it down.

Follow this topic: RSS · agent version