Guardrails belong in code, not in a style guide
A style guide asks people to remember the rules. A CI check refuses to merge when they forget. In trust-first domains, that difference is the whole game.
Every team building in a sensitive domain writes a copy guide. Do not promise a cure. Do not foretell what is coming. Do not claim a guaranteed outcome. Then someone ships a landing page at 11pm and the guide is a document nobody reread.
The fix is not more discipline. It is moving the rule from prose into code.
What the check actually does
The governance scan in this repo walks the product source and the public site content, splits every file into lines, and flags any line containing a forbidden claim fragment. A line that denies a claim - anything with "not", "without", "never" - is allowed, so disclaimers pass and assertions fail.
It runs in CI. A pull request that claims the product can foretell what is coming will not merge. There is no meeting about it.
Why lines, not sentences
Line-level scanning is crude, and that is the point. It is fast, it has no dependencies, and it is trivially auditable. A reviewer can read the rule in a minute and predict exactly what it will catch. Cleverer natural-language checks are more accurate and far less trustworthy, because nobody can hold their behaviour in their head.
The general lesson
If a rule matters enough to write down, it matters enough to enforce. A guide that is not executable is a hope. Put the guardrail where the work happens, fail the build when it is crossed, and spend your discipline on the problems a regular expression cannot see.