There is a failure mode every team building on agents discovers within about a fortnight. You ask the agent to check its own work, it reports that everything looks correct, and it is wrong.

Not maliciously. It simply has no independent access to ground truth. The model that misread the requirement is the same model being asked whether the requirement was met, and it misreads it the same way twice — so self-assessment does not merely fail, it fails confidently, and in exactly the cases you most needed it to work. The errors are correlated, which is the one property that makes a check worthless.

SRE has never trusted a component's opinion of its own health either. We do not ask a service whether it is up; we measure it from outside, with a probe that does not share its fate.

Why: A Loss Function Needs a Signal

The AI-DLC method definition paper describes human validation points as functioning "like a loss function" — catching and correcting errors early, before they snowball downstream. It is a good metaphor, and it repays being taken literally, because a loss function has a requirement the metaphor quietly hides. It needs a measured error to act on. Gradient descent without a loss value is just descent.

A human reviewing output at an approval gate is computing that error term from whatever they can see in the time they have. At sprint cadence, that works — a fortnight of work, an afternoon of review, and the ratio is sustainable. At the hours-or-days cadence the paper is designing for, where a Bolt is the smallest iteration and Units are deliberately decoupled to run in parallel, the arithmetic inverts. Human attention becomes the scarcest input in the system, and spending it on things a program could have checked is the most expensive mistake available.

Which reframes the usual design question. It is not "how many gates should we have". It is at each gate, which part of the error term is the machine computing, and which part is the human? Asked that way, a gate where a senior engineer is checking import ordering is not thoroughness. It is a loss function being spent on a rounding error.

What: Feedforward, Feedback, and the Loop Between Them

AI-DLC's documentation describes two mechanisms as the halves of a control loop, which is not language you often see in a developer tool.

Rules are the feedforward half. A persistent behavioural instruction — your logging standard, your naming conventions, the library you standardised on — authored once and pulled into context for every stage it covers. Rules resolve through a strictly additive chain of five layers.

Additive matters more than it sounds. Because broader layers are never overridden, only added to, a team cannot quietly opt out of an organisation-level security rule by writing a narrower one that contradicts it. Anyone who has watched a linting config get progressively disabled on the way down a directory tree will recognise what that design is preventing.

It also creates a cost that nobody warns you about. Every rule consumes context, and context is the resource your agent needs for the code it is supposed to be reading. A rule set that has grown by accretion for a year — every past annoyance memorialised as an instruction — competes directly with the repository for the model's attention, and the symptom is a mysterious decline in output quality that correlates with nothing in your prompts. Rules deserve the same periodic deletion pass you would give a test suite. If you cannot point at a recent correction a rule prevented, it is a comment, not a control.

Sensors are the feedback half. A deterministic check defined by a manifest — a linter, a type check, a custom validator. Sensors fire on matching edits, or once per deliverable at the gate, recording SENSOR_FIRED, SENSOR_PASSED and SENSOR_FAILED. Bindings are advisory or blocking, and a blocking finding needs a correction or an explicit, audited override.

Read as an SRE, the mapping is immediate. Rules are your golden path and your platform defaults — the things you set up so the common case is correct by construction. Sensors are your monitoring and your assertions — the things that tell you the truth when the common case did not hold. A pipeline with only rules is a system with no monitoring: it will work until it does not, and you will find out from a customer. A pipeline with only sensors is a system with no platform engineering: you catch everything late and fix it by hand, forever.

How: Choose Blocking Carefully, and Always Leave the Door

Advisory versus blocking is the same decision as page versus ticket in alerting, and it goes wrong the same way. Make everything blocking and the agent halts on style opinions while humans learn to override reflexively — alert fatigue, destroying signal by exactly the same mechanism, and the override becomes muscle memory rather than a decision. Make everything advisory and nothing is enforced; findings scroll past in a transcript nobody reads.

The rule of thumb that survives contact with reality: blocking sensors check things that are objectively wrong and cheaply verifiable. The code does not compile. The types do not check. A credential is in the diff. A required migration is missing. Taste, structure and preference start advisory, and are promoted only when the audit trail shows they are being ignored and that the ignoring is causing rework — two conditions, not one, because plenty of advisory findings are safely ignorable and promoting those is how you arrive at the fatigue problem from the other direction.

A starting catalogue that earns its keep in most repositories: the formatter and linter you already run in CI, a type check, a secret scanner, a dependency licence check, and one project-specific validator for whatever your codebase gets wrong most often. That last one is worth more than the other five combined, and you already know what it is.

The audited override matters as much as the block. A blocking check with no escape hatch gets disabled the first time it is wrong at 2am, and it stays disabled; one whose override leaves a row in the audit trail gets used correctly, because the escape is visible and attributable. It is the same design as an error budget policy exception — you can always ship anyway, and the decision is on the record with a name attached. Then review the overrides monthly. A sensor overridden ten times in a month is not protecting you, it is describing a rule you have not written.

There is a third kind of check worth separating out, because it catches a failure the other two cannot. AI-DLC runs an automated verification gate at each phase boundary, validating that every required artefact from the completing phase exists, that traceability links are intact — every requirement maps to a story — and that there are no orphaned artefacts before downstream stages build on them. That is a referential integrity check, run where corruption becomes expensive.

Long agent runs are unusually prone to quiet drift of exactly this kind. A requirement gets dropped three stages back, everything downstream remains internally consistent and entirely plausible, and nothing surfaces until a human reads the final diff closely enough to notice something missing — which is the reading people are worst at. A sensor will not catch it, because nothing is wrong with any individual artefact. Only a check that knows what should exist can find what does not.

Then close the loop. During a stage, corrections are recorded; at the gate they are surfaced, the human confirms which to keep, and each becomes a durable practice or scaffolds a new sensor, recorded as RULE_LEARNED or SENSOR_PROPOSED. That is a blameless post-incident review compressed into a single run — a correction is an incident, however small, and the valuable output is never the fix but the change that stops the class recurring.

When a correction becomes a rule, ask whether it also deserves a sensor. Rules shape behaviour probabilistically; sensors verify deterministically. Anything you would be genuinely upset to ship needs both, because the rule makes the right outcome likely and only the sensor makes the wrong one impossible.

Finally, treat rules and sensor manifests the way you treat SLO definitions in version control: in the repository, changed by pull request, reviewed by someone other than the author. A rule change alters the behaviour of every future run in its scope, which makes it a higher-blast-radius edit than most application code — and it is exactly the kind of change that gets made in a hurry, at the end of a frustrating session, by whoever was closest to the keyboard and most annoyed.