technical shaping — the ilities
The ilities — chosen for this Epic, not in general
Software engineering names the qualities a system can have — reliability, observability, scalability, maintainability, security, accessibility, performance, privacy, compliance. The literature calls them the ilities, or more formally non-functional requirements (NFRs). There are many, and most can be improved indefinitely. The shaping question is not which ilities matter in general; it is which ones matter for this Epic, and to what level.
For Uri's billing Epic, three are decided. Observability is high — every charge attempt logged with category, the reconciliation report queryable, alerts firing on rate-limit thresholds. This is a direct response to the brief: silent failure was the problem. Idempotency is mandatory — required by the ADR, enforced by the schema. Performance is moderate — the cycle has 23 hours to complete; sub-second latency on individual charges is not required.
The ilities explicitly not optimised for are noted too. Multi-currency is deferred. Real-time billing is rejected (the cycle is monthly by design). For other Epics, security or compliance might be the ilities that decide everything — handling cardholder data invokes PCI scope, handling EU customers invokes GDPR. When an Epic is in regulated territory, the relevant ilities can become hard constraints, not gradients. The discipline is the same: name them honestly, decide them deliberately.
Naming the unchosen ilities prevents the slow drift where every Epic has to be excellent at every quality. It also prevents the opposite drift, where ilities are absent because no one named which ones to invest in.
Product and UX ilities — the same discipline, different domain
The ilities are not only technical. The product side has its own set of qualities that can be invested in or deferred: learnability (can a new user figure it out without training?), accessibility (does it work for users with disabilities, with assistive technology, across device types?), content clarity (are labels, messages, and empty states written for the person, not for the developer?), responsiveness (does it work on the devices the person actually uses?). For Gal's grading Epic, learnability is high — she should grade without a training session. Responsiveness is deferred — she uses a laptop, not a phone. The discipline is the same: name them, decide them, record the decision.
Resolution gate — Technical shaping done for a story
Enough to write Givens that mean something specific.
The story's sequence diagram, schema additions, API contracts, and any ADRs that constrain it are written and agreed. The developer who will build it has signed off on the contracts.
Test: a developer reading the story plus the technical artifacts can build the right thing without inventing a contract, schema column, or API behaviour.