← The ADLC library
Product & acceptance criteria
A desk of the Fastpace GroundTruth library
Done, defined precisely enough that a machine can check it.
The specification end of the life cycle: what separates a criterion from a feature name, who owns acceptance criteria once drafting is assisted, why prose is a pointer rather than a spec, and what a definition of done has to become when the builder has no judgement.
Definition of doneOpen knowledge 36 articles
Articles
- Specs rot faster than code Code has a compiler, a test suite and a production environment all pulling it toward truth. A specification has nothing. The difference never mattered much while humans read specs and silently corrected them. Agents read them literally.
- The agent that asks a question is worth ten that do not Every vendor benchmark rewards one-shot completion, so every agent is being tuned to guess rather than ask. That is the wrong optimisation, and the questions you are suppressing are the cheapest quality signal you will ever get.
- Stop writing prompts. Start writing contracts. Prompt craft is a personal skill with no owner, no version, no review and no way to check whether it worked. A contract states what must be true when the work is done, which is the only artefact that survives the run that produced it.
- Your repository is the context, and it is a mess Teams argue about prompts and retrieval while the largest input to every agent run sits in git, unaudited. Your repository is a corpus of worked examples, and every abandoned pattern in it is a vote for doing the wrong thing.
- Fifty percent fewer errors is a ceiling, not a floor The finding that human-refined specs cut errors by up to 50 percent is being sold as a promise. It is an upper bound under favourable conditions, and the half it does not touch is a different kind of error that no amount of specification will reach.
- A spec a machine cannot check is a wish The test for an acceptance criterion is not whether a person agrees with it. It is whether anything could ever disagree with it. Most criteria fail that test, and the failure is invisible until the work comes back wrong.
- Against prompt libraries Shared prompt collections look like reusable knowledge and behave like undocumented folklore. They store phrasing rather than intent, they cannot be tested, and they rot without anyone noticing.
- Who writes the spec decides who runs engineering Authority in software has always sat with whoever made the last irreversible decision. That used to be the person typing. It is moving to the person who wrote the criteria, and most organisations have not noticed they are reassigning power.
- The spec is the artifact of record now For thirty years the code was the only document guaranteed to be true. That guarantee rested on a fact that no longer holds, which is that a person decided every line of it and could tell you why.
- Context blindness is the defining failure of 2026 Hallucination was the failure we prepared for. The one actually costing teams money is output that is internally flawless and incompatible with the repository it was written for, and no better model fixes it.
- Context engineering is requirements gathering wearing a new hat The discipline is forty years old and we already know how to do it. What changed is not the skill, it is that the work moved from a phase at the start of a project to something that happens on every single ticket.
- Making "done" mean something in Azure DevOps Azure DevOps can already tell you which work items went into a given deployment. Here is how to wire states, branch policies and environments so that answer is trustworthy.
- Making "done" mean something in GitHub GitHub has no status called done, so teams silently adopt merged as a substitute. Here is how to build a real finish line out of required checks, linked issues and deployment records.
- Making "done" mean something in Jira How to move your definition of done out of a wiki page and into the Jira workflow itself, using status categories, transition conditions and validators rather than hope.
- Keeping a knowledge base true, the drift problem all over again Everything that makes a board go wrong makes a knowledge base go wrong, for the same reason. A record nobody is obliged to update is a record that will be false.
- When to say "needs human verification" and mean it A decline is only useful if it changes what somebody does. Most teams turn theirs into a checkbox within a fortnight, and then wonder why the gate stopped catching anything.
- Verifying criteria against the diff, and its limits Reading a change and asking whether it satisfies a written criterion works better than expected, and fails in ways worth naming precisely before you rely on it.
- Runbooks, metric definitions and the shared vocabulary problem Two teams in the same company, using the same word, meaning different things. It was survivable when humans mediated. It is not survivable when agents write the query.
- Curated context versus retrieval: when structure beats search You can index everything you already have in an afternoon. Curating a knowledge base takes months. The case for doing the slow thing is narrower than advocates claim and stronger than sceptics think.
- The AC gate: what should block a merge A gate that blocks everything gets disabled in a fortnight. A gate that blocks nothing was never a gate. The interesting design is what happens in between.
- Who owns acceptance criteria when agents draft them A drafted checklist and an authored one look identical in the ticket. Only one of them carries a decision. That difference is an ownership problem, not a tooling one.
- Acceptance criteria as portable knowledge Most criteria die with the ticket that carried them. Treating them as concepts with a path, rather than a text field in a tracker, changes what they can do.
- Your PRD and ERD are knowledge, not documents Planning artefacts are written once, read during kickoff, and abandoned. Most of what they contain is durable. The document format is what kills it.
- From PRD to ERD to execution plan, mechanically Requirements, data model and work breakdown are usually three documents that drift apart. Here is what has to be true for the chain to hold without retyping.
- Remediating four thousand vague tickets You measured the backlog and it is bad. Marching through it in order is the wrong answer. Here is a triage that finishes in weeks rather than never.
- Checkbox criteria versus semantic criteria One has a state a machine can read. The other needs judgement to settle. Most teams mix them without noticing, and then wonder why automation is unreliable.
- Front matter as the agent's index The spec requires exactly one field. That restraint is a design decision worth taking seriously, and it says something about what metadata is actually for.
- Markdown links as a knowledge graph A directory of linked markdown files is a graph nobody had to build. It is weaker than a real graph database in ways that matter, and stronger in the one way that matters most.
- Scoring your backlog's ability to define done Before you fix anything, measure it. A concrete rubric for grading acceptance criteria at scale, and what the first run usually tells you.
- Spec-driven development is not waterfall, and the comparison is lazy Every time specification comes back into fashion, someone says waterfall. It is the fastest way to sound experienced while avoiding the actual question, which is who writes the spec and whether anything can check it.
- Given/When/Then, revisited for machine readers The format was designed to get a business analyst and a developer talking. It is now being parsed by software. That changes what a good scenario looks like.
- One concept per file: the filesystem as schema The oldest data structure in computing turns out to be a decent knowledge schema, provided you accept one rule. Getting the cut right is harder than it sounds.
- Writing acceptance criteria an agent cannot game Precise criteria are not the same as unGameable criteria. Here are the specific patterns that look rigorous, pass cleanly, and deliver nothing.
- The LLM-wiki, formalised The pattern spread as folklore before it had a specification. Now that it has one, it is worth asking what formalising a folk practice actually buys you, and what it costs.
- What the Open Knowledge Format is, and why the ADLC needs one Google Cloud published a v0.1 spec that says knowledge is a directory of markdown files. The unglamorous part is the point, and it is exactly what agentic development has been missing.
- Why "works correctly" is now a production incident Vague acceptance criteria used to be free, because a human filled the gap with taste. An agent fills it with the literal text, and ships that at speed.
The other desks
Delivery & program intelligenceWhat the numbers do when agents arrive. Engineering leadershipWhat happens to the people when the code writes itself. Governance, security & complianceThe questions an auditor will ask, before they ask them. Platform economics & toolingWhat this actually costs, and what it is worth.