Verify

Acceptance must produce evidence. The impression that a screen looks clean, or that the code compiles, does not demonstrate that the product fulfills its purpose.

Dimension	Acceptance evidence
V01 Coverage	Every mandatory element of the product definition has an implementation and evidence, or an explicit and approved exception.
V02 Progress	People achieve the defined outcomes and can recognize them; where Job Stories exist, this is verified in their circumstances.
V03 Causality	The evidence relates the situation, the need and the outcome without depending on a feature request; where it applies, it preserves circumstance and motivation.
V04 Understanding	They can explain where they are, what they can do and what will happen next, without outside help.
V05 Burden	They do not face decisions, concepts or data that the system could resolve safely.
V06 Depth	The beginner finds a clear route and the advanced user retains sufficient capability.
V07 Trust	The system anticipates consequences, confirms results and offers proportionate recovery.
V08 Control	The person can review, correct, reject or revert according to the impact of the action.
V09 States	Loading, empty, error, success, interruption and return all preserve context and orientation.
V10 Accessibility	The flow works with keyboard, visible focus, understandable labels, contrast and the applicable assistive technologies.
V11 Performance	Critical actions meet the response budget or show honest progress.
V12 AI	Variable outputs declare uncertainty; critical rules are verifiable; sensitive actions require authorization.

Assign 0 where there is no evidence, 1 where compliance is partial or depends on an unvalidated assumption, and 2 where there is sufficient evidence. The score guides the conversation; it does not replace judgment.

Criterion	Score	Evidence question
Traceable foundation	0 / 1 / 2	Sources, authority, scope, results and conditions are identifiable
Product coverage	0 / 1 / 2	Every mandatory element has implementation, a test or an approved exception
Applicable Job Stories	0 / 1 / 2	Where they exist, circumstance, motivation and outcome retain sufficient evidence
User progress	0 / 1 / 2	The implementation produces the outcomes defined by the product
Cognitive load	0 / 1 / 2	It reduces or justifies concepts, decisions and steps
Interface clarity	0 / 1 / 2	State, action and consequence are understood
Control and recovery	0 / 1 / 2	Proportionate review, correction or reversibility exists
Progressive depth	0 / 1 / 2	Capability appears when it is appropriate
Dependability and timing	0 / 1 / 2	Performance, persistence and feedback meet expectations
Responsible use of AI	0 / 1 / 2	Uncertainty, limits and determinism have been resolved
Cumulative quality	0 / 1 / 2	States, language and micro-interactions are coherent

Recommended exit criterion. No critical dimension may score 0. Criteria relating to security, permissions, money, personal data or irreversible actions must score 2 before release. For the rest, the team must define its threshold according to risk and scope.

• What authorized source and what product foundation justify this decision?

• Do the implementation and its tests account for the full scope?

• Where Jobs to Be Done or Job Stories exist, how does this decision relate to them?

• Does the formulation describe a need, or is it a feature request recast in another form?

• What cognitive load does it introduce and what does it remove?

• Are we exposing internal complexity?

• Can any element be removed without reducing capability or control?

• Does the person know what will happen before acting?

• Can they recover easily if they make a mistake or if the system fails?

• Is the AI proposing, deciding or executing? Is that level authorized?

• What would make us reject this implementation even though it technically works?

Anti-pattern	How it shows up	Response
The Job Story is a feature in disguise	The motivation says to use a dashboard, receive alerts or press a button.	Reformulate the progress the person needs without anticipating the answer.
The circumstance was invented	The team writes a plausible story without observing behavior, tension or real context.	Mark it as a hypothesis and obtain evidence before extending the implementation.
The interface mirrors the database	The user has to choose internal types, states or relationships.	Translate the structure into human goals and decisions.
More options are mistaken for more value	Every exception turns into a visible control.	Resolve by context and reveal exceptions when they arise.
AI fills conceptual gaps	An ambiguous prompt produces a large implementation.	Stop, clarify the material assumptions and preserve the authorized scope.
The plan selects scope	Some stories or rules are implemented and the rest deferred without a product decision.	Restore full coverage, or record an explicit and approved modification.
Decomposition is mistaken for exclusion	A technical phase is presented as though it redefined what the PRD requires.	Separate execution order, progress status and committed scope.
The tutorial compensates for an opaque interface	The basic task requires prior explanation.	Review language, hierarchy, conventions and feedback.
Confirmation substitutes for reversibility	The system asks several times, but there is no undo.	Design recovery and use confirmations only according to risk.
The happy path defines the product	Errors, empty states and interruptions are left for later.	Model states before implementing and accept them explicitly.
A fluent answer looks true	The user does not distinguish fact, inference and proposal.	Show source, uncertainty, limits and a route to verification.
Technical speed hides the wait	The operation takes time with no feedback, or blocks the whole flow.	Respond immediately, show progress and preserve continuity.
Aesthetics paper over friction	The screen looks good, but demands unnecessary decisions.	Evaluate the complete journey and the real effort.
The agent adds things just in case	Modes, preferences and abstractions appear that nobody asked for.	Define exclusions and require justification per capability.

A warning about simplicity

Simplicity can become an excuse for hiding information, denying legitimate cases or limiting the expert user. The framework does not reward empty interfaces. It rewards the right relationship between capability, moment and context.

Valuable simplicity does not remove what is necessary. It avoids demanding it before its time.