Your bots and dashboards parse denial message text — what breaks when you reword the message?

## The moment a sentence becomes an API A policy denial has an audience the author did not choose. The sentence is written for a developer, but a review bot, a dashboard, a deduplication layer, an alert router and someone's suppression list all end up reading it too. If they have nothing better to read, they read the prose. That is when the wording quietly becomes an interface — one with no schema, no version, no consumers list, and no test that fails when you change it. So you improve the message. The old one said `memory limit missing`; the new one says `container 'log-shipper' declares no memory limit; set resources.limits.memory`. Strictly better for the human. And then: **Suppressions stop matching.** A team had accepted this finding on a legacy workload by suppressing on the phrase. The phrase no longer occurs, the suppression no longer matches, and the finding fires again — probably as a block, probably in the middle of an unrelated change. Symmetrically, a suppression written as a loose substring can now match findings it was never meant to cover, silently hiding a real violation. Both directions are bad and neither announces itself. **Dashboards fork.** A panel that grouped findings by message string shows the old series flatlining and a new one starting. Every trend line spanning the change is wrong, and the quarter-over-quarter comparison someone is about to present is comparing two halves of the same rule. **Deduplication and correlation fail.** Anything that decided "same finding as yesterday" by comparing text now sees a new finding. Tickets get re-opened or duplicated, alert volume spikes, and the noise looks like a regression in the estate rather than an edit to a string. **Parsers break or, worse, don't.** A regular expression that pulled the container name out of the old wording either stops matching — a visible failure, the lucky case — or keeps matching and extracts the wrong substring, which is the unlucky one. ## Why this is a design defect, not bad luck The consumers are not being unreasonable. They needed identity and location; the payload offered a sentence; they took what was on offer. The defect is upstream: the emitter published exactly one machine-readable thing and it was the one field guaranteed to change. The rule to internalise is that **presentation and identity must be different fields**. Identity is the stable set — the rule identifier, the resource, the field path, the severity, the outcome. Presentation is the message and the remediation hint: written for people, expected to improve, explicitly *not* a key. Once that split exists, rewording is a copy edit again, because nothing joins on prose. ## The cost of not fixing it The visible cost is the breakage. The insidious one is **ossification**. Once a team has been burned by a rewording, the operational lesson they learn is "never touch a message". So the vague, unactionable denial that generates a support ticket every week is now permanent, protected by the fear of breaking a dashboard. The gate's worst quality — the thing you most wanted to improve — is the thing most locked in. Payload-as-API failures do not merely cost an incident; they remove your ability to make the gate better. ## Getting out of it This is a migration, and treating it as one is the senior move. 1. **Add the structured fields first,** alongside the existing message, unchanged. Nothing breaks, because nothing has been removed. 2. **Find the consumers.** Not by memory — by looking. Grep the suppression lists, the dashboard definitions, the alert rules and the bot configuration for fragments of your message strings. The set of people parsing your prose is always larger than the set who told you they were. 3. **Migrate each consumer onto the fields**, keying suppressions and grouping on the rule identifier plus resource and field path. 4. **Then declare the message unstable** — in writing, next to the payload's documentation — and reword freely. During the migration, resist the temptation to "keep the message stable-ish" by leaving the old phrase embedded in the new one. That is a compatibility shim for a consumer you can fix, and it locks in the wording you were trying to escape. ## What to say in the interview The answer that lands has three beats: the failure is **silent** (no exception, discovered from a ticket); the root cause is that **the only machine-readable field was the volatile one**; and the fix is to **split identity from presentation and migrate consumers before touching the text**. Adding "and the real damage is that message quality freezes" is what marks someone who has lived with it rather than read about it.