Meet people where the work happens. A rule violation surfaced in the editor while someone is writing the definition gets fixed in seconds. The same violation in a pull request gets fixed before merge. The same violation in a monthly report gets ignored. Guidance has to be just-in-time — available at the moment someone hits the friction, not filed in a wiki they would have to think to consult.
Ship the why with every rule. A failure message that says what is wrong, why the organization cares,
and exactly how to fix it is a completely different social object from one that just says
path-casing: error. This is why rule metadata — a stable ID, a category, how-to-fix text — is worth
more than additional rules.
Build a real exception process. Some rules genuinely should not apply to some APIs, and a governance program with no legitimate escape hatch teaches teams to lie or to hide. Make exceptions explicit, recorded, time-boxed and reviewable. An honest exception register is far more useful than a hundred-percent compliance number that everyone knows is fiction.
Roll out by team or domain, gradually. Start warnings-only, watch what fires, fix the noisy rules before you turn anything into an error. A ruleset that produces two hundred findings on day one teaches everyone that the findings do not matter.
And keep the framing guardrails, not gates. A guardrail stops you going off the cliff without stopping you driving.
