Introduction
Redline is the review system your team doesn't have: one written standard that your AI follows while it writes, your machine checks before you push, and the pull request gate checks before merge — and it counts which rules actually catch bugs.
It is not a linter — a linter checks syntax, and many of Redline's rules are judgement a linter cannot express. It is not a reviewer either — people and the AI tools you already use still review. Redline decides what reviewed means, and holds every reviewer to the same definition.
AI assistants write more of your code every quarter, and the review capacity to check it did not grow with them. The bar a team agreed on is now enforced — or not — by whatever tooling happens to be in front of the diff, which is why Redline versions the standard rather than leaving it to a prompt somebody wrote once.
There are no servers, no SaaS and no per-seat fee beyond the AI licences you already pay for. Redline detects GitHub or Azure DevOps from your git remote and talks to whichever one you're on through the same command — rulesets or branch policies, reusable pipelines, and pull requests either way.
Where the line is
Redline governs a change while it is still a diff. It does not build, deploy, promote or roll back anything, it has no opinion on cloud spend, and its data ends at merge — those are a delivery platform's job and are well served. Findings can come from Redline's own checker, your AI reviewer or another tool: Redline normalises whoever found what, and measures whether anyone acted.
Words this site uses
| Standard | The rule set in standards/: core rules plus one file per stack, versioned. Every rule has a permanent id such as core/unsafe-assertion. |
| Profile | Which stacks apply to a repository, e.g. web-react. A file only meets the rules of the stacks it belongs to. |
| Gate | The redline-gate / gate check on every pull request. It starts advisory — it comments, it blocks nothing — until you promote it. |
| Deterministic check | A rule a checker decides without a model, so it can run in redline review, the pre-push hook and the gate with no false positives allowed. |
| Seed | A defect planted on purpose in the public corpus, marked with the rule that must catch it. Seeds are how a reviewer is scored. |
| Estate | Every repository an organisation has onboarded. redline sync and redline metrics work across it. |
The loop
standards/ — humans edit one place, versioned + changelogged ↓ the CLI's renderer 4 vendor formats — Copilot · AGENTS.md (Codex) · Claude · Cursor ↓ redline init (one PR, per repo) · redline sync (to the whole estate) every onboarded repo — gated on merge, at the rung that repo has earned ↓ redline verify (locally, or across the estate weekly) drift caught early — policy, security floor, stale artifacts, pending admin work ↓ redline metrics (nightly) what was acted on — and what it cost: the number that decides which rules earn their place
What makes it different
- A measurable output contract. Findings are prefixed
Redline/<SEVERITY> [<rule-id>]:— so recall, precision and noise are measured, never guessed. - Advisory first, and it stays that way until the numbers say otherwise. A repository climbs the enforcement ladder on recorded evidence — seed recall, false positives, acted-on rate — and steps back down without needing anyone's permission.
- It refuses rather than approximates. A check that could not run reports
??, neverok. An unmeasurable figure is absent with its reason, never zero. A correlation below its sample threshold is withheld. Each of those is a place where a confident wrong answer would have been easier to build. - Noise control is a rule. Every standard ships a “what NOT to flag” section, and the clean-code corpus allows zero false positives.
- Vendor-neutral. The rules, gate and telemetry don't know which AI produced a comment. Comparing vendors on identical seeded input is one command.
- Degrades honestly. An engineer without repo-admin rights still gets everything file-level; what needs an admin is recorded, not silently skipped.
Where to go next
- Quick start — take a small service from no Redline to an earned merge gate, one pull request per step.
- Adopting Redline — what happens in week one and month two, and when it is reasonable to start blocking.
- The output contract — how to read a finding and what each severity obliges you to do.
- Standards — browse and copy the full rule set.