Who owns acceptance criteria when agents draft them

Watch someone accept a drafted set of acceptance criteria. It takes about four seconds.

The ticket has a paragraph of prose in it. A tool offers a checklist derived from that prose: six boxes, well formatted, each one plausible. The person scans it, sees nothing obviously wrong, and clicks accept. The checklist is now in the ticket. It looks exactly like a checklist somebody wrote.

Nothing bad has happened yet. The criteria are probably decent, because deriving testable criteria from clear prose is a task models are genuinely good at. But something has changed that nobody in the room noticed: the ticket now contains a set of decisions that no human made, presented in the format that your organisation uses to signal that a human made them.

Four seconds. Six decisions. And in three weeks, when the feature ships without the thing everyone assumed it would do, the conversation will be “the criteria didn’t say that”, and the criteria will have been written by nobody.

Approval is not authorship

The comfortable answer to the ownership question is “the human who approved it”. I want to push on that, because it is doing less work than it appears.

Authorship forces you through the decisions. When you write “a reset token expires after 30 minutes”, you had to pick 30. You considered 15 and you considered an hour, and you have a reason, even a weak one. That reason is now in your head, and it will surface in review when someone proposes something inconsistent with it.

Approval does not force you through anything. When you read “a reset token expires after 30 minutes”, you evaluate plausibility, and 30 minutes is plausible. So is 15. So is 24 hours, which is a security problem, and it is also plausible, because plenty of systems do it. Reading generates a much weaker signal than writing, and it generates it on a different question. Writing asks “what should this be”. Reading asks “is this obviously wrong”. The second question passes almost everything.

This is not a claim that the drafted criteria are bad. It is a claim that approval produces less understanding than authorship, and the understanding is what you needed, because the criteria are going to be interpreted by an implementer who will resolve every remaining ambiguity on their own.

Approval

• Evaluates plausibility
• Thirty minutes reads as reasonable
• So does fifteen. So does twenty-four hours
• No decision was made, only not-objected-to
• Four seconds, six decisions

Authorship

• Forces you through the decision
• You picked thirty over fifteen
• You have a reason, even a weak one
• The reason survives to the next argument
• The understanding is the point

Two failure modes, in opposite directions

Rubber-stamping is the obvious one. Drafts accepted at volume, quality drifting down, nobody noticing because everything looks fine. The tell is your acceptance rate: if approvers accept drafted criteria without edits more than about four times in five, they are not reviewing, they are clicking. I would treat unedited acceptance rate as a real operational metric, and a high one as an alarm rather than a success.

Ownership diffusion is subtler and worse. When criteria are drafted, reviewed by a product manager, refined by an engineer, and gated by automation, there are four parties and no owner. Everybody assumes somebody else checked the thing that mattered. This is the classic diffusion of responsibility and adding a machine to the chain makes it sharply worse, because the machine is the only participant that cannot be asked what it was thinking, and it is also the one everyone quietly assumes was thorough.

The organisational tell for diffusion: when something ships wrong, the post-mortem cannot identify who should have caught it. If the answer is “the process”, you have diffusion.

A model that actually assigns ownership

Here is the split I would defend. It has three roles and one rule.

The specifier owns intent and the non-negotiables. One named person per ticket, usually whoever wanted the work. They own the answer to “what is this for” and to a small number of decisions that must not be delegated. Not all of them: three or four.

The implementer owns completeness. Whoever builds it, human or otherwise, is responsible for the criteria covering the cases the specifier did not think about. An implementer who finds an unspecified case and resolves it silently has failed even if the resolution was right, because the resolution should have gone back into the criteria where the specifier could see it.

The verifier owns evidence. Whoever signs off owns the question “how do we know”, not “does this look reasonable”. Different question, much harder to fake.

And the rule: a drafted criterion becomes owned when someone changes it or explicitly confirms a specific decision inside it. Blanket approval does not transfer ownership. This sounds like process pedantry and it has a very practical form, which is the next section.

The specifier owns intentOne named person per ticket. Owns what this is for, and the small number of non-negotiable decisions inside it.

The implementer owns completenessResponsible for the cases the specifier did not think of. Finding a gap and building to the letter anyway is a failure.

The verifier owns evidenceOwns "how do we know", not "does this look reasonable". A different question, and much harder to fake.

The three questions technique

The technique that makes this work in practice, and costs about ninety seconds per ticket, is to never accept a drafted checklist wholesale. Instead, before accepting, answer three questions in writing.

1. Which number here did I choose?

Drafted criteria are full of numbers, and every one is a guess weighted toward what is typical. Typical is frequently wrong for you. Go through and either confirm each number with a reason or change it.

- [ ] Reset token expires after 30 minutes        ← drafted
- [ ] Reset token expires after 15 minutes        ← mine: our support flow
      re-sends on request, so short expiry costs us nothing and we had an
      incident with long-lived tokens in the legacy system

Thirty seconds, and now that criterion is owned. Note that the comment is as valuable as the change, because it survives the next person’s instinct to “fix” it back.

2. What did it not ask about?

Drafts are derived from what you wrote, so they inherit your blind spots and add none of their own knowledge about your system. Their omissions cluster in predictable places: concurrency, permissions, existing data, and the interaction with things not mentioned in the ticket.

+ [ ] Two admins submitting the same invitation simultaneously results in
      one invitation, not two (unique on org_id + email where not accepted)
+ [ ] Accounts created before 2024 have no `region` set; the export must
      not fail on them

Neither of those could have been drafted, because neither is visible from the ticket text. They come from knowing the system. This is the part of criteria authoring that has not been automated and, I would argue, mostly cannot be at present, because the necessary evidence is not in the ticket or the diff.

3. Which of these would I actually block a merge on?

A drafted list treats all criteria as equal. They are not. Some are the point of the feature and some are hygiene. Marking that distinction is a decision only a human can make, and it is the one that determines what the gate does.

- [ ] BLOCKING: no account enumeration on the reset endpoint
- [ ] BLOCKING: tokens single-use
- [ ] Nice: rate limit of 5 resets/hour per email

Ninety seconds total for the three questions. In exchange, the ticket now contains at least one number you chose, at least one case you added from system knowledge, and an explicit statement of what matters most. That is ownership, and it is visible in the artefact rather than asserted in a policy.

Which number did I choose?Every draft is full of guesses weighted toward typical. Typical is frequently wrong for you.

What did it not ask about?Omissions cluster: concurrency, permissions, failure. None visible from the ticket text.

Which would I block a merge on?Drafts treat all criteria as equal. Some are the point, some are hygiene.

What this does to the product manager’s job

The obvious concern is that drafting assistance deskills the specifier. I think the opposite happens, but not automatically, and the direction depends entirely on whether the three-questions habit exists.

Without it, the job degrades into approving plausible text, and the skill atrophies quickly because it is never exercised. With it, the mechanical part of the work disappears (formatting, splitting, phrasing, remembering to add the 403 case) and what remains is the part that was always the job: knowing what the thing is for, knowing which decisions are load-bearing, and knowing enough about the system to see what is missing.

That is a better job and a harder one. It also has a nasty implication for how people learn it, which is that the mechanical work was how juniors used to build the judgement. Writing forty sets of criteria by hand is how you develop the instinct for what a good one looks like. If the first forty are drafted and approved, the instinct does not form. I do not have a clean answer to this and I am suspicious of anyone who claims to. The least-bad version I have seen is deliberately having people write criteria unassisted for high-stakes tickets, treating it as practice as much as production.

Who owns it when it goes wrong

The test of any ownership model is the post-mortem, so let me be concrete about what good looks like there.

Bad: “The acceptance criteria didn’t cover the case where the subscription was cancelled mid-period.” Passive, ownerless, unactionable. Leads to a process change nobody follows.

Good: “The criteria were drafted and accepted unedited. Nobody asked what happens to seats on a mid-period cancellation, because the ticket text didn’t mention cancellation and the draft couldn’t know to ask. The specifier is accountable for the omission; the specific gap is that our three-questions check doesn’t prompt for lifecycle transitions of related entities. Adding that prompt.”

The second version names a person, and also names the systemic gap, and does both without contradiction. Ownership is not about blame allocation, it is about there being a definite answer to “who should have caught this”, because without a definite answer you cannot improve anything.

One thing worth stating plainly: a machine cannot be accountable. It cannot be asked to explain, cannot be corrected in the way a person is, and cannot carry consequences. Any ownership model that lets responsibility come to rest on a tool has no bottom to it. If your criteria are drafted, a person owns them, and the process should make that person’s fingerprints visible in the artefact rather than implied by a workflow state.

Where this breaks down

Ninety seconds per ticket is a real cost and it will be the first thing dropped. On a team pulling thirty tickets a sprint, that is under an hour, which sounds trivial. In practice it is an hour of the specific attention that is most scarce, and it will be skipped under pressure, on exactly the urgent tickets where it matters most. Any process that depends on voluntary diligence at the moment of highest pressure has a known failure rate, and it is not low.

The three questions assume the specifier knows the system, and often they do not. “What did it not ask about” is a question you can only answer with knowledge of the codebase, the data, and the history. A product manager three months into a role cannot answer it, and telling them to try produces confident additions that are wrong. In that situation the honest move is to route the question to an engineer, which makes it a conversation rather than a checklist item, and conversations do not scale the way this article implies.

There is a decent argument that ownership of criteria is the wrong frame entirely. You could hold that the only thing worth owning is the outcome: does the feature work for users, does it not break anything, is the customer happy. On that view, obsessing over who authored a checkbox is process theatre, and the right investment is in fast feedback from production rather than in specification rigour upstream. I have sympathy for this. Teams with excellent observability, small batches and quick rollback genuinely need less specification, because they find out cheaply. If you can detect and reverse a bad change in ten minutes, a wrong criterion costs you ten minutes. The specification-heavy argument is strongest exactly where feedback is slow, expensive or irreversible: data migrations, billing, permissions, anything regulated, anything a customer sees once.

And unedited acceptance rate is a gameable metric. The moment you measure it, people will make trivial edits to clear the bar. I still think it is worth watching, because the transition from ninety percent unedited to fifty percent tells you something real, but do not attach it to anything with consequences or it will immediately stop meaning anything.

The takeaway

Drafted criteria and authored criteria look identical in the ticket and are not the same object. One carries decisions, the other carries plausibility, and your process almost certainly cannot tell them apart.

Fix that at the artefact level, not the policy level. One named specifier per ticket. Three questions before accepting any draft: which number did I choose, what did it not ask about, and which of these would I block a merge on. Leave the reasoning in the ticket so the ownership is visible to the next person.

Drafting is genuinely useful and I would not give it up. It removes the typing, which was most of the cost. It cannot remove the deciding, and the failure mode is that it looks like it has.

The next piece takes the third question seriously and asks what should actually block a merge: which unmet criteria justify stopping a change, what happens to the ones that do not, and why a gate that blocks everything is functionally the same as no gate at all.