Which properties of a rendered notification message can a case assert, and which need human review?

Every rendered notification splits into two kinds of property: things with a single right answer computable from the case's own inputs, and things that require taste or an unpredictable rendering surface. The first kind belongs in an assertion. The second kind belongs to a person — and the engineering work is not deciding *that* a person is needed, it is making the person's pass rare, cheap and triggered by change rather than by the calendar. ## The line is determinism, not difficulty A useful test to apply property by property: **could two competent people disagree about the right answer, given only the case's inputs?** If not, a machine decides. If so, a person does. | Property of a rendered message | Decided by | Why | |---|---|---| | Every slot rendered a value | the case | one right answer, no judgement involved | | The values the case seeded appear | the case | the case created them, so it knows them | | Link destinations point where the flow intends | the case | comparable against a stated expectation | | Dates and amounts match the recipient's declared preference | the case | derivable from seeded profile data | | The formatted and plain-text bodies carry the same facts | the case | set comparison over extracted values | | Subject line carries the correlation value the run injected | the case | exact match | | Layout holds together in an unfamiliar reading application | a person | the surface is not controlled by the sender | | Wording reads as intended for a first message | a person | taste, and no stable expected value | | A long translated string overflows or truncates awkwardly | a person | perceptual, and varies per rendering surface | | Emphasis and hierarchy land on the important line | a person | design judgement | Everything in the top half is written once into the shared step that handles a captured message. It costs nothing per case afterwards, and it never gets skipped under release pressure — which is the real argument for automating it, more than the effort saved. ## Make the human pass rare: review on change "Somebody eyeballs the welcome email each release" is a commitment that quietly stops happening around the third release. Replace it with a **review triggered by change**: 1. The run captures the rendered bodies and subject line as artefacts. 2. A normalisation step removes everything that legitimately varies per run — the seeded values, generated references, single-use codes, timestamps — replacing each with a stable marker. 3. The normalised content is compared against an approved reference stored with the code. 4. Identical? No review, no failure, nobody's time spent. 5. Different? The case fails with both versions attached, a person reads the difference once, and either fixes a defect or approves the new content as the reference. That inverts the economics. Unchanged templates cost nothing. A changed template costs one focused reading of one diff, by someone who can see exactly what moved — which is a far better review than a tired scan of a message that looks the same as last time. The normalisation step is the part that decides whether this survives. Under-normalise and every run differs, the case is noisy and gets disabled within a month. Over-normalise and you erase the content you were reviewing. Normalise **exactly** the per-run values and nothing else, and keep the list of them in one visible place. ## Both failure modes are real - **Over-automating appearance.** Comparing images of a rendered message across several reading applications every run produces differences that harm nobody, on a surface the sender does not control. The failures are ignored, then the case is disabled, and the genuinely deterministic checks that were bundled with it go quiet at the same time. - **Under-automating facts.** "We look at the emails" covers a raw placeholder, a stale link and a wrongly formatted amount only if somebody happens to notice. All three are exactly computable, and the machine notices every time. ## Write the human half down so it can fail The part that needs a person still needs to be an obligation rather than a hope. Name who reviews, what triggers it — a change in normalised rendered content — and what a review can conclude: approve, or raise a defect. A review that has no way to fail is decoration. In an interview, saying that out loud is what separates "we automate what we can" from someone who has actually kept the manual half alive past release three.