Turn the problem into falsifiable acceptance claims

What This Concept Is

An acceptance claim binds a user outcome to a scope, observable result and failure condition. It is narrower than an architecture aspiration and broader than a single implementation detail.

Why It Matters Here

The capstone must connect domain, architecture and final evidence. A design diagram without a way to disprove its promises cannot guide a rigorous defense.

Concrete Example

For ticketing, claim that two simultaneous attempts for one remaining seat cannot produce two confirmed bookings. Define confirmation, capacity, cancellation and retry identity before choosing a lock or transaction. Add an authorized successful booking case so a system rejecting every request cannot pass. Map the claim to a domain invariant and the later test/trace.

Common Confusion / Misconception

A requirement such as use microservices specifies a mechanism, not a user outcome. A target with no workload or observation boundary is not a complete performance claim.

How To Use It

Create a ledger with claim ID, beneficiary, boundary, counterexample, evidence method and owner. Link the top three risks to a spike and an ADR; retain deliberately excluded claims.

Check Yourself

What observation would falsify the claim? Can a degenerate implementation pass? Which words need domain definitions?

Mini Drill or Application

Rewrite three broad project goals as acceptance claims with a counterexample and positive control. Have the original ADR reviewer challenge one boundary.

Read This Only If Stuck

Building Secure and Reliable Systems provides selective operational reasoning. Use the module sources below for current tool behavior; do not read a whole book before attempting the exercise.

C4 model; Google engineering review guidance. Revisit Semester 07 quality, domain and review lessons; no new book is required.