Use four evidence layers
Start with source observations: quoted or faithfully summarized customer problems with references. Add decision context: affected accounts, commercial exposure, frequency, and strategic constraints. Then add product interpretation: the job to be done and desired outcome. Finally add implementation hypotheses from the current codebase.
Do not flatten these layers into one confident paragraph. A source observation can be verified; a product interpretation can be challenged; an implementation hypothesis can become stale.
Acceptance criteria should describe outcomes
Criteria are easier to review when they name the actor, trigger, observable behavior, and boundary. Avoid prescribing internal implementation unless that choice has already been approved as an architectural decision.
Include negative cases and preservation requirements. What must not change? Which existing users keep current behavior? What happens when permissions, data, or downstream services are unavailable?
Record architectural decisions separately
Cross-cutting choices—data shape, permission model, API contract, retention behavior, and external services—deserve explicit decision records. List considered alternatives, why one is proposed, and the confidence of the codebase evidence.
A product reviewer should not accidentally approve a storage or authentication strategy simply by approving the customer problem.
Make the handoff rejectable
A requirement is ready for implementation review when its scope is bounded, evidence is inspectable, acceptance criteria are testable, unresolved decisions are visible, and an accountable reviewer can say no.
That standard matters even more when an agent drafts the document. Fluency is not evidence, and completeness of prose is not completeness of reasoning.