What Separates the Two Packets

The failure is not the tone; it is that every success criterion is an output the team controls. “Portal launched” is satisfied by launching a portal nobody uses. “90%+ approved automatically” is satisfied by loosening the rules — the criterion actively rewards the fraud risk the guardrail was supposed to prevent, and there is no guardrail here to stop it. “Support tickets down” has no baseline, no cohort and no denominator, so it can be declared true by picking a fortnight.

The consequence arrives later and is expensive: when evidence shows that 15% of cases need a human, this frame gives the team no way to represent that as anything but failure against “90% automatic”. The predictable response is to automate decisions that should not be automated, or to quietly stop reporting the number. And because the frame is “v1.0, expected to be stable”, learning is routed through a change-request process — a mechanism designed to resist change, applied to the document that most needs to absorb it.

Rubric: Problem and outcome clarity.

These are not assumptions; they are assertions in the grammar of assumptions. “Our returns policy can be expressed as rules in code” has no impact rating, no evidence strength, no test and no owner, so nothing about it can be wrong until it is expensive. The fraud line is worse than untested — it contains a hidden argument (“since the same rules apply”) that is false: the same rules applied by a machine at scale, instantly, with no human noticing a pattern, is a different control environment. Stating the reasoning inline lets it pass without review.

“Validated with stakeholders at kickoff” is the specific move to distrust: agreement in a room is not evidence about the world. And “the team will find out during development” is accurate — they will, at the point where finding out costs a sprint rather than two days. The risk register beside it lists only delivery risks (scope creep, holidays, integration effort); not one row is about whether the intervention works. That is the signature of a plan that has confused shipping with succeeding.

Rubric: Problem and outcome clarity and Delivery sequencing and uncertainty reduction.

Two moves cause the damage. First, skipping the current state on the grounds that it is understood. It was not: the strong packet's map found a 19-hour evidence round-trip, a transposed order id in a shared spreadsheet, and a class of request (gift orders) with no rule and no owner. None of those is visible from the to-be flow, and all of them arrive later as “edge cases” during implementation — which is where the weak packet's week-3 status quietly records “Support mentioned that a lot of returns are actually gift orders. Noted for later.”

Second, the entity list is derived from nouns in the brief, not from behaviour. ReturnStatus as an entity is the tell: it makes “status” a thing to be set rather than a machine with legal transitions and actors, and it guarantees the shared-status-column design in section 8. The list also has no owners, no change cadences and no invariants, so it cannot suggest a boundary — every later structural decision has to come from somewhere else, which in practice means from the technology stack.

Rubric: Domain fidelity and invariant protection.

The backlog is organised by layer — backend, integration, frontend, platform — which means nothing in it is demonstrable to a user until almost all of it is finished. RET-1 through RET-7 can all be complete and correct while no customer has ever returned anything, so the first honest feedback arrives in sprint 4 at the earliest. Every assumption in section 2 stays alive until then, and every integration surprise lands during the sprint that has no slack.

The estimate compounds it: 91 points at 20 per sprint is not a forecast, it is arithmetic wearing a forecast's clothes. It has no range, no confidence, and no statement of which variable can move — so when the carrier work turns out to be six days larger than believed, there is no pre-agreed control surface and the only remaining lever is quality. Note also that the accessibility review is a ticket (RET-15, 3 points, sprint 5). A guardrail expressed as a low-priority ticket in the last sprint is a guardrail that will be traded away under pressure.

Rubric: Delivery sequencing and uncertainty reduction.

“Given a valid return request … then the system returns a result” is a tautology: it is true of any implementation, including a wrong one. “Appropriate message”, “gracefully” and “quickly” are three unresolved decisions in a document that looks like it has resolved them, and each will be settled silently by whoever writes the code first.

The structural problem is what is absent: no failure semantics, no idempotency, no concurrency, no authorization case, no accessibility case. So the questions that produce production incidents — what does a timeout mean, what happens on a double submit, what if the refund is already settled — are not answered here, are not answered in section 8, and are therefore answered by the first person to hit them at 02:00. Deferring them to “QA during testing” moves the discovery to the most expensive point and to the person with the least context to decide.

Rubric: Testability, observability, security and reversibility.

Not one of these nine rows can fail a check, and not one of them distinguishes two designs. “Scalable to handle future growth” does not say which operation, at what load, by when — so it cannot argue against any architecture, and in practice it argues for whichever one sounds most scalable, which is how the microservice in section 7 gets justified without evidence.

“99.9% uptime” looks like the exception because it has a number, but the number is attached to nothing: uptime of what, measured how, and — the question that actually matters here — may label creation degrade while request acceptance stays up? The strong packet's D1 answers exactly that and gets a real design constraint out of it. One global uptime figure hides the distinction, so the team can hit 99.9% while refusing every return during a carrier incident.

The consequence is that this section does no work. Section 7's architecture cannot be traced to any row here, section 12's alerts are generic infrastructure thresholds, and when the carrier turns out to be slow in week 3 there is no written requirement it violates — so it is recorded as “the team is investigating” rather than as a falsified premise.

Rubric: Use of measurable architecture drivers.

This is a technology inventory labelled as a container diagram. It names what will be installed and answers none of the questions a container view exists to answer: what owns which data, which component may write which fact, what the interaction protocols are, and which requirement pays for each boundary. Redis appears with no stated purpose; RabbitMQ appears before the decision that would need it; the arrows in the box sketch carry no labels, so the diagram cannot distinguish a synchronous call from an event.

The load-bearing sentence is the last one: the service is a microservice “in line with our microservices strategy.” That is a boundary justified by a policy rather than by a driver, and it is charged rent forever — a network hop between the returns logic and the storefront session, a second deployment, separate observability, version skew, and a consistency boundary that now spans a process. The strong packet's test (“we accept network, versioning, observability and ownership overhead because independent ____ is required by driver ____”) cannot be completed from this document, because section 6 contains no driver that requires independent anything.

And “sequence diagrams will be added during implementation” inverts the purpose: the dynamic view is how you find out that a carrier timeout can lose an accepted request. Drawn after implementation, it documents whatever was built, including the defect.

Rubric: Quality and depth of module boundaries and Coupling, cohesion and dependency direction.

status varchar plus PATCH /returns/{id} is the whole defect in two lines: any caller with the endpoint can move a return to any state, including refunded. There is no actor per transition, no precondition, no ownership, and — because the same field carries all three meanings of “approved” that the domain map would have found — no way to tell whether “approved” means policy passed, inspection passed, or money moved. The invariant that a refund cannot exceed the captured amount lives nowhere at all.

“Clients should be tolerant readers, so adding fields is safe” is true of optional fields and false of everything else: a new status value will break every consumer that branches on the enum, and a changed meaning of an existing field will pass every schema check while breaking every reader. Because no compatibility policy distinguishes these cases, the safe change and the breaking change are indistinguishable at review time.

“Retries are handled by Celery's built-in retry mechanism” delegates a domain decision to a library. The mechanism retries the task; it has no idea whether the carrier call is idempotent. With no client reference and no uniqueness constraint, the strong packet's measured outcome — two duplicate labels in ten timeout-retries — is the behaviour this design ships, and nothing here would detect it.

Rubric: Data ownership, contract evolution and failure semantics.

One option is presented, and the rationale is familiarity: it is in our stack and the team knows it. Familiarity is a real force and belongs in a comparison — but here it is the entire argument, so the record cannot show what was given up. A reader in six months cannot tell whether a synchronous call was considered and rejected, whether a database-backed outbox was compared against a broker, or whether anyone measured the carrier at all.

The decision is also under-specified in the way that matters. “Celery's retry mechanism handles transient failures” does not say whether the carrier call is idempotent, what identifies one label intent, or what happens if the task is delivered twice — so the duplicate-label failure is not decided against, it is simply unaddressed. And the queue is a broker outside the accepting transaction: if the return commits and the enqueue fails, the return is accepted with no label and nothing to notice. That is a consequence, and the Consequences section instead lists a UI polling detail.

There is no dissent, no revisit trigger and no accepted cost. The three things a decision record exists to preserve — what was true, what was given up, and what should reopen it — are all missing, which makes this a note of what happened rather than a record of why.

Rubric: Quality of alternatives and trade-off reasoning.

The sprint sequence is horizontal: everything backend, then everything integration, then everything frontend, then “hardening”. Integration therefore happens once, late, in sprint 3, and usability happens later still — so the two things most likely to be wrong are discovered when there is no time to respond. “Hardening” as a sprint name is the tell: monitoring, load testing, accessibility and documentation have been separated from the work that needs them, which makes them the first things sacrificed when sprint 3 overruns. It did.

“Raised in the platform channel; awaiting response” is not a dependency plan. It names no person, no date, no readiness evidence, no fallback and no escalation, so it can only be resolved by luck or by becoming a crisis. The strong packet's fake-adapter fallback exists precisely so that this dependency cannot block the skeleton.

“The plan is achievable with the current team” is a claim with no range and no movable variable. When reality arrives, no trade has been pre-agreed, so the adjustment happens invisibly, in the only place with no gate: quality.

Rubric: Delivery sequencing and uncertainty reduction.

“We decide together, and anything contentious goes to the tech lead or the PM” specifies nothing. It does not say who decides scope against experience, who decides whether a guardrail has been breached, or who may stop a release — so under pressure the decision goes to whoever is most senior, most insistent, or in the room. The failure is invisible while things go well and total when they do not: during an incident, nobody knows whether they are allowed to turn the flag off.

“All pull requests reviewed by the tech lead” converts one person into a throughput limit and a single point of knowledge. It also substitutes a person for a mechanism: the boundary rules and contract promises live in one reviewer's head rather than in checks the build can run, so they degrade the moment that person is on holiday — and there is no import rule, no contract test and no fitness function anywhere in this packet to catch it.

Note what is absent: no WIP limit, no swarm rule, no escalation trigger, no named source of truth per fact, and no consultation path for the expertise the team does not have. The section describes ceremonies rather than a decision system, which is why section 13's status report has no decision in it.

Rubric: Product, design and engineering collaboration.

Coverage is a proxy: 84% coverage of a rules engine tells you the lines ran, not that the rules match what an expert would decide. The strong packet's equivalent — 200 real agent decisions replayed as tests — is the check that can actually fail for a domain reason, and it is what surfaced the missing gift-order rule. The load test at 100 rps is meanwhile testing a number nobody derived; the real peak is 40 rps, and no requirement anywhere says what latency at that load must be, so the test cannot fail either.

The dashboard measures the system and nothing else. Request rate, error rate, latency, CPU and queue depth can all be green while returns take three days, while the fraud rate doubles, or while every mobile customer abandons the flow. Nothing here would show that the initiative failed, which means the initiative can only be judged by whether it shipped.

Going to 100% on launch day removes the one property that makes production learning safe — a limited blast radius and a population to compare against. And “disable the flag or roll back the deployment” treats reversal as a single action, when the flag stops new intake but does not recall a refund, void a label, or unsend an email. Because the reversal was never rehearsed, whether the flag even stops the background worker is unknown; in the strong packet, rehearsing exactly that revealed that it did not.

Rubric: Testability, observability, security and reversibility.

Every line reports activity: points, tickets closed, velocity, coverage. None of it is evidence about whether the initiative will change anything for a customer, and none of it can turn the status from Green to Amber, because no threshold has been defined for any of it. “80% complete” on the carrier integration is the classic false precision — the remaining 20% is the unknown behaviour, which is why the strong packet reports milestones as demonstrable exits instead.

The two most important sentences are filed as minor risks. “The carrier sandbox is slower than expected” is the same observation that superseded an ADR in the strong packet; here there is no latency requirement for it to violate, so it becomes a performance annoyance to “optimise if needed”. “A lot of returns are actually gift orders” is a falsified policy assumption arriving from a domain expert, recorded as “noted for later” — it will resurface as an escaped defect or as an agent quietly overriding the system.

“Blockers: none that will affect the date. Asks: none.” A review with no ask and no decision is a broadcast. Its cost is not the thirty minutes; it is that the forecast keeps its confidence long after the evidence supporting it has gone, so the options that were available in week 3 have expired by the time anyone admits the position has changed.

Rubric: Technical communication and decision clarity.

Not one claim here is checkable. “Most returns are approved automatically” has no denominator and no comparison; “a noticeable drop in tickets” is a report of someone's impression with no baseline, no window and no cohort; “no P1 incidents” measures the absence of catastrophe, not the presence of value. Since the whole population was exposed on day one, there is nothing to compare against even in principle — the choice made in section 12 has removed the ability to know whether the initiative worked, permanently.

“One day ahead of plan” is the sentence that reveals what was being optimised. The date was never the goal; it was a constraint on achieving an outcome that this document never measures.

Then the operational tail is simply absent. No named steady-state owner, no on-call handover, no runbook acceptance, no access revocation, no removal of the pilot machinery — “the feature flag remains in place for safety” is how a flag becomes permanent, doubling the live state space of every future change with nobody owning its deletion. The retrospective records feelings and two process actions but no organisational memory: which assumptions failed, what the carrier actually does under retry, what the gift-order finding means. Rolling straight onto phase 2 completes the pattern — the next initiative starts with the same untested assumptions, the same status column, and the same 80%-complete reporting.

Rubric: Operational ownership and initiative closeout.