What an Invariant is, and why you need one<\/strong><\/h2>\n\n\n\nAn invariant is a rule every change must respect. Invariants address the most common category of AI slop: convention blindness, deprecated APIs, module boundaries the model doesn\u2019t know about, and security baselines that should apply everywhere. <\/p>\n\n\n\n
None of these are in the\u00a0model\u2019s training data\u00a0for your specific codebase. They live in the heads of your senior engineers and show up as recurring review comments. Invariants say what every <\/em>PR should respect, for example:<\/p>\n\n\n\n\n- Writes to the users table go through UserRepository.<\/li>\n\n\n\n
- HTTP handlers call auth middleware before any business logic.<\/li>\n\n\n\n
- Migrations declare a down block.<\/li>\n<\/ul>\n\n\n\n
These are the rules your linter can’t express, because they’re about what the code does, not how it’s written. Today they live in senior engineers’ heads and in Skills or files like CLAUDE.md. They tell an agent your rules, but nothing checks whether the agent followed them. <\/p>\n\n\n\n
With Invariants, the rule is written once, stored in your Aviator account for the whole team, and checked on every matching change.<\/p>\n\n\n\n
Where Invariants Come From<\/strong><\/h2>\n\n\n\nMost good invariants start as a review comment someone has typed more than twice. You don’t have to write them from scratch. Verify drafts them from what your team already knows:<\/p>\n\n\n\n![\"\"](\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2026\/10\/invariant-sources-1024x650.png\")
<\/figure>\n\n\n\nAI-drafted rules start as drafts. They don’t affect any PR until someone on your team approves them.<\/p>\n\n\n\n
\nSee what your team’s invariants would look like.<\/strong> With a free Aviator account,<\/a> Verify generates them from your PR history and docs. You keep them even if you don’t continue with Verify.<\/em><\/p>\n<\/blockquote>\n\n\n\nHow it works<\/strong><\/h2>\n\n\n\n\n- Verify picks the rules that fit.<\/strong> When a PR comes in, a selector reads the change and its intent and picks the invariants that apply. Nobody tags rules by hand, and a CSS change doesn’t get checked against database rules. You can also scope a rule to certain paths or languages with conditions<\/a>.
<\/li>\n\n\n\n- A separate agent checks them.<\/strong> Each selected invariant gets a pass or fail, with evidence pointing at the code that broke it. The verdict says what’s wrong; the author decides how to fix it. See how verification works<\/a>.
<\/li>\n\n\n\n- Exceptions are allowed, Invariants evolve.<\/strong> Any invariant can be waived with a reason: false positive, doesn’t apply, accepted risk, or fix in a follow-up. Every waiver is logged. If one rule keeps getting waived, that’s your signal to reword it.<\/li>\n<\/ol>\n\n\n\n
The full reference is in the invariants docs<\/a>, and setting up org invariants<\/a>. <\/p>\n\n\n\n\n
- \n
- Writes to the users table go through UserRepository.<\/li>\n\n\n\n
- HTTP handlers call auth middleware before any business logic.<\/li>\n\n\n\n
- Migrations declare a down block.<\/li>\n<\/ul>\n\n\n\n
These are the rules your linter can’t express, because they’re about what the code does, not how it’s written. Today they live in senior engineers’ heads and in Skills or files like CLAUDE.md. They tell an agent your rules, but nothing checks whether the agent followed them. <\/p>\n\n\n\n
With Invariants, the rule is written once, stored in your Aviator account for the whole team, and checked on every matching change.<\/p>\n\n\n\n
Where Invariants Come From<\/strong><\/h2>\n\n\n\n
Most good invariants start as a review comment someone has typed more than twice. You don’t have to write them from scratch. Verify drafts them from what your team already knows:<\/p>\n\n\n\n
<\/figure>\n\n\n\nAI-drafted rules start as drafts. They don’t affect any PR until someone on your team approves them.<\/p>\n\n\n\n
\n
See what your team’s invariants would look like.<\/strong> With a free Aviator account,<\/a> Verify generates them from your PR history and docs. You keep them even if you don’t continue with Verify.<\/em><\/p>\n<\/blockquote>\n\n\n\n
How it works<\/strong><\/h2>\n\n\n\n
- \n
- Verify picks the rules that fit.<\/strong> When a PR comes in, a selector reads the change and its intent and picks the invariants that apply. Nobody tags rules by hand, and a CSS change doesn’t get checked against database rules. You can also scope a rule to certain paths or languages with conditions<\/a>.
<\/li>\n\n\n\n- A separate agent checks them.<\/strong> Each selected invariant gets a pass or fail, with evidence pointing at the code that broke it. The verdict says what’s wrong; the author decides how to fix it. See how verification works<\/a>.
<\/li>\n\n\n\n- Exceptions are allowed, Invariants evolve.<\/strong> Any invariant can be waived with a reason: false positive, doesn’t apply, accepted risk, or fix in a follow-up. Every waiver is logged. If one rule keeps getting waived, that’s your signal to reword it.<\/li>\n<\/ol>\n\n\n\n
The full reference is in the invariants docs<\/a>, and setting up org invariants<\/a>. <\/p>\n\n\n\n
\n
- A separate agent checks them.<\/strong> Each selected invariant gets a pass or fail, with evidence pointing at the code that broke it. The verdict says what’s wrong; the author decides how to fix it. See how verification works<\/a>.
- Verify picks the rules that fit.<\/strong> When a PR comes in, a selector reads the change and its intent and picks the invariants that apply. Nobody tags rules by hand, and a CSS change doesn’t get checked against database rules. You can also scope a rule to certain paths or languages with conditions<\/a>.