Adopting Redline
What actually happens, in order, and when it is reasonable to start blocking merges. The short answer is: later than you think, and on evidence rather than a date.
Redline is deliberately unenforcing on day one. Every stage below ends where the evidence for the next one is gathered — the same rule the enforcement ladder applies mechanically, said in prose.
Day one — One repository, nothing blocked
What you do
- Run redline init on a single repository — ideally one with real traffic, not a sandbox.
- Merge the onboarding pull request.
- Leave the rung at observe.
What you get
- The standard rendered into whatever AI tools that repository already uses.
- The merge gate reporting on every pull request, blocking nothing.
- The security floor on and blocking: dependency review and the secret scan.
Resist promoting here. You have no evidence yet, and a gate that blocks before anyone trusts it is a gate someone routes around.
Week one — Find out whether the findings are any good
What you do
- Read the findings on real pull requests. Are they right? Are they worth the interruption?
- Score the reviewer against the seeded corpus on a pilot repository.
- Raise anything that fires constantly on code you have deliberately decided to allow.
What you get
- Seed recall and false-positive numbers — evidence, rather than an impression.
- A sense of which rules earn their place in your codebase specifically.
A rule that fires constantly and is always dismissed is a rule to cut, not a team to train. That conversation is what rule ids exist for.
Week two to four — Onboard the rest, still watching
What you do
- Onboard the repositories that matter. redline init is idempotent, so batching is safe.
- Let the nightly register pick them up.
- Turn on telemetry collection so acted-on rate starts accumulating.
What you get
- A derived register, and a coverage figure that is instrumented-against-onboarded rather than a raw count.
- The weekly drift sweep, so a repository whose gate quietly stops publishing gets noticed.
- Sync pull requests whenever the standard changes — nobody re-runs init by hand.
Month two — Start blocking, where the evidence supports it
What you do
- Promote the repositories whose numbers clear the bar to block-blocker.
- Leave the rest where they are. The ladder refuses a promotion the evidence does not support, and says which number is short.
What you get
- A guarantee you can actually state about a named set of repositories.
- A dashboard figure for how much of the estate is enforcing rather than watching.
Demotion never needs evidence. If a gate misfires, step it back the same day and investigate afterwards — that is what makes promoting safe.
Ongoing — Price it, and tune it
What you do
- Run the ROI page before a budget conversation.
- Read the tuning queue: rules that fire often and are acted on rarely.
- Ingest whatever scanners the estate already runs, so the picture is whole.
What you get
- Cost per BLOCKER caught — a figure no cost tool and no DORA tool can compute.
- One severity contract across LLM review and static analysis.
Two things to decide early
- Who owns the standard. A rule change is a production change: it reaches every onboarded repository as a pull request. Somebody has to be able to say yes to one.
- Who can turn the gate off. Before any repository blocks, write down how a team disables it out of hours without waiting for that person. A control nobody can release is one people work around.
What does not change
No repository is asked to change which scanners it runs, which assistant it uses, or how it deploys. Redline governs the change while it is still a diff — see what it is and is not.