Administration
Organisation policy
Why policy is not a file in your repository
A repository file is writable by anyone who can push. A threshold exists to constrain the person subject to it. Putting the constraint where the constrained party can edit it makes it advisory at best.
So policy is stored per-organisation in the database, every key requires admin or owner, and every write is audited with the old and new value.
Every shipped key defaults to inert
Nothing is switched on for you. A tool that silently applied thresholds you did not choose would be making policy decisions that are yours to make — and the first time one fired unexpectedly, the whole gate would lose credibility.
The keys
Comment thresholds
| Key | Default | Effect |
|---|---|---|
cost.comment_above_usd |
0 |
A priced monthly increase at or above this comments on its own. 0 means every priced increase. |
blast_radius.comment_above |
3 |
A radius score at or above this comments on its own. |
The two defaults read differently on purpose. 0 on the cost key means report everything; 0 on a blocking key would mean disabled. The keys share a subject and not a verb — blocking a merge is coercive, so its off-switch has to be the value that does nothing, while saying a sentence is not.
blast_radius.comment_above: 3 is the lowest score a change reaching production can have, so the default reads as tell me when this reaches production.
Provenance tiers
Six admin-only boolean keys, all defaulting to false, covering the ai_authored and ai_assisted classes: escalate warnings, require human approval, disable autofix. See provenance tiers.
Budget
Cost thresholds and the approver role for changes above them.
Changing one is a documented event
Every change is audited with both values, so “when did we relax that, and who agreed?” has an answer. That question is asked after an incident, and an answer of “at some point, by someone” is the reason audit logs exist.