When are custom thresholds worth it for No unfilled merge tags?
When are custom thresholds warranted?
Override `placeholderPatterns` when your stack's token syntax is not among the defaults, which is the common case for ESPs with distinctive delimiters or for in-house sending code. Add your own patterns when you have a house convention for unfinished copy in email, or when a migration has left a second token style in circulation that you want caught until it is cleaned out. Take the patterns from a real unresolved send rather than from documentation, since what reaches the inbox is what matters.
When should you stay on Standard?
Stay on the defaults if your ESP uses one of the covered syntaxes and you have no house filler convention, because the list is already tuned against real mail. Keep them for editorial newsletters especially, where bracketed phrases appear legitimately in subject lines and body copy — this is exactly the case the generic bracket pattern was removed for. If your concern is placeholder *images* or unfilled links rather than text, widening this list will not reach them.
What do you trade away?
Patterns compile case-insensitively, so a class written for uppercase letters cannot express "uppercase placeholder" — a mistake that turns a narrow rule into a broad one without any warning. Broad patterns are the real hazard here: a bracket or brace rule wide enough to catch every token style also catches legitimate editorial punctuation, and a check that fails good sends stops being read. Supplying your own list replaces the defaults rather than adding to them, so carry the originals forward unless you mean to drop them.
Community Standard vs org Custom
The Standard list is deliberately shaped by measurement against a real corpus rather than by completeness, which is why it names specific merge fields instead of matching all brackets. A Custom list encodes your own sending stack and belongs with whoever owns the templates, reviewed when you change ESP — patterns for a platform you no longer use quietly stop protecting anything. Record why each added pattern exists, because the ones nobody can explain are the ones that later cause a false failure.
Worked override examples
A team on an ESP using `${field}` syntax adds `\\$\\{[^}]+\\}` alongside the defaults, catching a token style the generic list has no view of. A company mid-migration keeps both its old and new platforms' delimiters in the list for a quarter, so any template still carrying the retired syntax surfaces before it goes to volume. A publisher whose newsletters routinely use bracketed labels in copy keeps the Standard list untouched rather than adding a general bracket rule, accepting narrower coverage in exchange for a check that never fails a legitimate issue.
How does an agent call it with parameters?
{
"type": "email",
"validations": [
{
"id": "email-no-placeholder-text",
"parameters": {
"placeholderPatterns": [
"\\{\\{[^}]+\\}\\}",
"\\[[A-Z ]{3,}\\]",
"lorem ipsum",
"\\[FIRST NAME\\]",
"\\[LAST NAME\\]",
"\\[COMPANY\\]",
"\\[DATE\\]"
]
}
}
]
}