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.

Nothing that blocks is on by default

No blocking threshold 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 blocked a merge unexpectedly, the whole gate would lose credibility.

The two context keys are the exception that proves the rule: they default to speaking, because saying a sentence is not coercion. The table below marks which is which.

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

Key	Default	Effect
`budget.threshold_prod_usd`	`0` (off)	A priced monthly increase strictly above this, in a change touching production paths, becomes a critical `budget.threshold` finding and fails the commit check.
`budget.threshold_nonprod_usd`	`0` (off)	The same gate for changes that touch no production path.

Note the deliberate contrast with the comment keys: on a blocking key, 0 must mean disabled — the off-switch has to be the value that does nothing. A change touching both production and non-production paths is held to the production threshold.

Going over is a decision, not a dead end: an admin or owner approves the spend, and the approval is bound to the amount shown — a later push that costs more re-blocks. The gate then renders as approved, deliberately distinct from passed. See cost deltas for the full mechanics, including what a partial estimate can and cannot do to this gate.

Fix delivery

Key	Default	Effect
`fix.commit_directly`	`false`	How a Fix with Deltz click delivers a gate-passing fix. `false`: as suggested-change blocks on the pull request that the author applies or ignores; applying one is a push, reviewed again. `true`: as a commit straight onto the pull request’s head branch. A fix that cannot be expressed as blocks offers the commit path in its note either way. See fixes.

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.

Conventions

Key	Default	What it does
`conventions.enforce_confirmed`	`false`	When on, a violation of a convention a person confirmed blocks the merge (critical); the comment names who confirmed it and when. Conventions Deltz only measured stay advisory whatever this says. Admin-only, off by design — nothing blocks on your team’s standard until an admin decides it should.