A red-team report on an AI feature marks a finding as 'accepted, signed off' at the release gate. What does that disposition actually mean, and who has to be the signer for it to carry weight?

### What the disposition means A release gate has three outcomes for a confirmed finding. **Block** stops the launch until the behaviour is removed. **Compensating control** ships the behaviour with a mechanism already deployed in front of it that bounds the consequence. **Named acceptance** — sometimes written *risk acceptance* or *sign-off* — ships the behaviour with nothing in front of it, on the strength of a specific person's decision. That makes acceptance the most consequential of the three, because it is the only disposition where the residual risk reaches users unmodified. Candidates commonly describe it as the bin where findings go to disappear, and interviewers ask this question precisely to see whether you treat it as a decision with an owner or as a filing status. ### Why the identity of the signer decides whether anything happened A signature from someone who lacked the authority to choose otherwise is theatre: they could not have blocked the launch, so no decision was taken and none can be revisited. It also inverts accountability, because the person who found the problem ends up carrying the consequence of shipping it. The right signer is whoever answers for the product's outcomes — the accountable product or business owner — not the red teamer who reported it and not the engineering manager whose team would do the fix, who has a direct interest in avoiding the work and usually cannot cancel a launch either. For classes with legal, regulatory or safety-commitment exposure, the decision escalates further, and that escalation is itself the useful mechanism: an organisation frequently discovers it does not actually want to accept something at the moment someone senior is asked to put a name on it. A gate that never escalates is either shipping only trivial residual or is routing acceptances to whoever signs fastest. ### Why scope and expiry are not paperwork Without a stated scope — this behaviour, on this surface, in this build — the wording stretches. A year later the feature has three new integrations, the provider model behind it has been swapped, and an old signature is quietly covering a system nobody has assessed. An **expiry date** forces a re-decision on a schedule; a **reopening trigger** forces one on an event: a model swap, a guardrail or system-prompt change, a new integration, a new user population, or a production incident in that class. Both matter, because AI features change underneath their assessments without any code change on the team's side. ### What it costs Acceptance looks free at the gate and is not. Each live acceptance costs a periodic review — realistically 15 to 30 minutes of the signer's and the programme's time per item per cycle — and that cost is what caps how many a programme can genuinely hold. A ledger of two hundred unexpired acceptances is not two hundred decisions; it is an unreviewed list, and the review is the only thing that made acceptance different from ignoring the finding. Escalation costs more: getting a senior decision-maker properly briefed on one class is hours, not minutes, which is exactly why teams try to route around it. ### Where the number misleads Acceptance counts are routinely reported as closure. A dashboard showing *18 findings, 15 closed* usually counts acceptances as closed items, which reads as progress while describing accumulating residual risk — the number moves in the reassuring direction precisely as the exposure grows. Two related misreadings: a rising acceptance count can mean the gate is finally seeing more surface rather than that the product is getting worse, so the count alone tells you nothing about direction; and a **severity label** on an acceptance is often mistaken for a control, when a label sorts a list and stops nothing. The honest presentation is unexpired acceptances by class, with age, reported as risk carried rather than work completed. ### What you would check Can the signer name what happens in production if this fires, without reading the report? Could they have said no? Is the acceptance written against the behaviour and its reproduction, or against the finding's title — titles drift, behaviours do not. Is there a date or a trigger? And across the ledger: is anything expiring, is one person signing for every team (which usually means the signature has become administrative), and is the total being shown to leadership as accumulating risk rather than as closed items?