The Initiative Artifact Pack

The version history is the part most frames delete. v0.1 (25 Aug) defined success as “automatic approval for at least 90% of eligible requests”. v0.2 (4 Sep) changed the outcome event from automatic approval to decision communicated, because the 200-case policy sample showed 15% of requests are genuine judgment calls — an outcome defined on automation would have scored the correct product behavior, routing a judgment call to a human quickly, as failure. v0.3 (2 Oct) moved guest orders from “non-goal” to “deferred opportunity, sized, decision date 15 November”, because “non-goal” kept being re-argued as “refused forever”.

Full frame with every field and the version history: initiative-frame.md.

Two habits are worth stealing. The test is sized to the decision, not to the assumption: A3 got a four-hour spike because a number would change a structural choice, while A7 (do policy rules change often?) got two hours of reading because the change log already existed. And “no test” is a legitimate recorded choice — a map where every row has a test is usually a map nobody costed.

All eight rows with owners, dates, and evidence strength: assumption-map.md.

The most useful contribution came from Nils's silent-writing notes: most eligible returns are unopened domestic items that agents approve without real deliberation, and most of the 72 hours is queue time rather than decision time. In an open discussion anchored on “build a portal”, that fact does not get said.

Five mechanisms were sketched, four genuinely different: automated eligibility; proactive status with no automation at all; agent tooling that removes re-keying; a full self-serve portal; and adding two agents for the season. The workshop deliberately did not produce an architecture — choosing a mechanism before the codifiable-policy rate was known would have been an opinion with a diagram attached, and the sample later came back at 63%, not the 90% everyone in the room had assumed.

And the dissent was right. Guest orders turned out to be 29% of demand. The cohort did not change, but the outcome statement did — it now names the signed-in cohort explicitly, so nobody quotes the headline number as if it covered everyone.

Preparation, block-by-block notes, and facilitator failure modes: workshop-agenda.md.

Two facts fell out of the timings immediately. 68 of the 72 baseline hours sit in two queue waits — order verification and policy interpretation — and neither is work; both are the request waiting for a human to reach it. And the 19-hour evidence round-trip only happens for opened items, which the pilot excludes. That is why the pilot's narrow scope is not timidity: it removes the second-largest wait by construction.

All four kinds of evidence point the same way, which is the only kind of boundary evidence worth acting on. Target workflow: two waits deleted, one manual step deliberately kept (warehouse receipt, about 40 confirmations a day, with a stated removal trigger), and one new state added — referral — because the sample said 15% of cases need a human and pretending otherwise would have produced bad automatic refusals.

Every hotspot record, the full glossary, and the target-state table: workflow-and-eventstorming-board.md.

Release line: the first row only. What it proves: both halves of the outcome on 1% of eligible demand, against a matched control, at n ≥ 120 requests. Manual seam: warehouse receipt matching — about 40 confirmations a day inside the clerk's existing workload, removed after 14 consecutive days with under 0.1% late receipt events and zero mismatches.

What the pilot slice is not. It is not “the eligibility service” and not “the returns database”. Both could be finished without a single customer being served.

A second card covers the fraud hold, and its most important line is a guardrail rather than a rule: no customer-visible text, email, or API response distinguishes a fraud hold from any other referral, asserted by a negative test that fails if the internal reason code ever appears in a customer-facing payload.

Both cards in full, plus the release-slice table: story-map-and-example-card.md.

Five candidates were rejected as drivers, each with a reason: “the system must scale” (no load, operation, or horizon — and no option responds differently to it); “must handle 10× volume” (beyond the demand horizon, and untestable); “must be cloud-native / event-driven” (mechanisms, not qualities — they belong in the option table where they can be rejected); “must be maintainable” (replaced by D4, which can fail a check); and “99.99% uptime” (a number with no operation, which would have hidden the distinction that label creation may degrade but request acceptance may not).

Also caught: “use our standard message broker” was classified as a preference, not a constraint — one database transaction already gives all-or-nothing across return, decision, and intent. And “build inside the existing deployable” was classified as a decision, not a constraint, so its reasoning stayed visible and arguable.

All five drivers with why-they-are-ranked-there and owners: architecture-driver-table.md.

The one boundary that was justified is smaller than a service: the label worker is a separate process in the same artifact, sharing the same schema, because D1 requires the carrier call to survive a 30-minute outage without blocking request acceptance. That is the smallest boundary that satisfies the driver, and no network hop was introduced where a transaction would do.

The three “authoritative:” labels on the context view — order truth, settled money, parcel received — are the most load-bearing text in the packet. They say the returns system holds no independent opinion about any of them, which is what makes the state machine enforceable rather than aspirational.

Full checklist, the packet contents, and the module import table: c4-review-checklist.md.

Two rows carry most of the design. Only Payments may write “refunded” — the returns module requests and observes, and physically cannot break that invariant. And the refund row has no recovery, written down rather than hidden behind the word “rollback”. A code deploy can be reverted; a settled refund cannot. That single admission is what produced a settlement_disputed state and the rule that we never auto-compensate.

Not everything called an invariant is one. “Every accepted return reaches a terminal state within 21 days” looks like an invariant and is not: it is false for up to 21 days by design. Enforcing it as one would mean refusing legal states. It needs a daily detector with an owner and an escalation — a completely different piece of work, and one that only got built because the classification exercise happened.

The customer-facing contract makes one careful choice worth copying: 201 means the return exists and a decision has been made — it does not promise a label exists. That distinction is the whole point of ADR 0003. And the closed/open enum split matters more than it looks: reason_code is an open enum with mandatory human text, so a new reason ships freely; state is a closed enum consumers branch on, so a new state needs a version bump.

The carrier contract's key row came from measurement, not instinct: a timed-out create retried without a client reference produced a second label in 2 of 10 attempts, and with one, in 0 of 10. The client reference is not a nicety; it is what makes “exactly one label per return” achievable at all.

All thirteen transitions, the rule classification, both contracts, and the idempotency-key table: state-and-contract-review.md.

Decision: what happens to an accepted return request when the carrier is slow or down? The team's provisional design called the carrier inside the request, and it had already been written up and accepted as ADR 0002 on 1 September.

Option C was not a straw man. It lost as the everyday mechanism because its cost scales with success, and it won as the emergency mechanism because it needs no new code and no vendor. Keeping a rejected option alive in a narrower role is often the most useful outcome of an option table.

Four hours removed the option the team preferred, eleven days after it had been accepted as an ADR. That is the entire economic case for spikes.

How the dissent ended. At closeout, referrals alone reached 41/day at peak, so option C's extra label purchases would have breached the 50/day guardrail: Sam's main point was recorded, tested, and not upheld. His second point — that the flag carries ongoing cost — was upheld and put on the removal list with a date. A dissent is not a vote to be defeated; it is a prediction to be checked.

Full option table, spike record, ADR text, and the five-entry decision log: option-table-spike-brief-and-adr.md.

What it proved in week 2 — three things nobody predicted. The storefront's session cookie was not available to the worker process, so correlation ids broke across that boundary. The migration needed a two-step deploy to avoid locking a hot table. And the platform's log retention was 3 days, not the 30 the privacy review had assumed. All three were cheap in week 2 and would have been expensive in week 9.

Note the third row: when a dependency has a genuine fallback, its failure is a scope trade to be decided, not a delay to be reported. Writing the fallback in advance converts an escalation from a complaint into a decision request.

Forecast. Pilot open to 1% between 26 September and 3 October, about 70% confidence — not “30 September”, because a single date at that range is a claim the evidence does not support. Fixed: the date and the team. Movable: scope. The smallest trade, identified in week 1 and taken in week 3 on evidence rather than under deadline pressure, was to drop the in-product appeal flow to a later slice: about five days, and it touches neither outcome measure — which is the test a scope trade has to pass. What would not be traded: the reversal rehearsal, the authorization negative tests, and the control cohort, because trading those buys days by removing the ability to know whether the pilot worked.

All five milestones, the full dependency map, and the forecast fields: delivery-and-dependency-map.md.

The asymmetry in the last two rows is the single most useful line in the charter. Advancing exposure requires two named people to agree; stopping it requires one person to act. A team that needs permission to stop will not stop in time.

Flow. WIP limit of two slices, which feels wrong for about a week and then stops feeling wrong. Swarm when a slice has not moved for half a day rather than starting a third. Any engineer may approve a pull request; the tech lead reviews only changes crossing a module boundary, a contract, or an authorization path — the three places where a mistake is expensive. That is why the tech lead is not a throughput bottleneck, and it is also what makes the one-day policy release achievable at all.

Escalation is triggered objectively: a dependency misses its needed-by date; a driver cannot be met inside the agreed scope; a decision crosses another team's ownership; forecast confidence drops below the agreed range; a guardrail breaches, in which case whoever notices stops first and talks afterwards.

Health. No planned weekend work — the date moves scope, not hours. Two protected no-meeting mornings a week, protected by the product manager including from the product manager. Every module touched by at least two people before the pilot gate: checked, not assumed.

Full charter with people, sources of truth, and the cadence table: team-charter.md.

The holdback is the point of stage 3. “It improved after we launched” is not a finding. A control cohort that stays unexposed for the whole pilot is what turns the outcome numbers into evidence rather than into a coincidence with a date on it.

Reversal means “stop the intake”, never “undo the week”. Disabling exposure stops new returns entering the new path; returns already in flight continue, because abandoning them would strand customers mid-journey. Labels already bought are not voided. Refunds already requested are not recalled. The contract says so, rather than leaving the team to discover it at 2 a.m.

The rehearsal that found a real defect. First run: the disable flag did not do what everyone believed. It was checked when a request created an intent, so it correctly stopped new label attempts — but the worker read the flag once at start-up and kept retrying the 63 intents already in its backlog against a failing carrier. The stopwatch said “disabled in 3 minutes”; the carrier's dashboard said we were still calling it eleven minutes later. The fix: read the flag inside the worker loop, with a test asserting the worker stops within one iteration. Second run: disable worked in 90 seconds, and the gap was the support message — nobody could say what a customer with a pending label should be told. It is now a stage-2 entry condition.

The rehearsal runs before every stage, not once, because the disable path is code and code changes. An untested control is a belief; thirty minutes found a defect that would otherwise have surfaced at 02:00 during a real outage.

Risk-to-test map, telemetry map, and the operational readiness checklist: rollout-contract.md.

Three results, three different responses. The carrier spike reversed a decision: ADR 0002 superseded by ADR 0003, with every affected artifact updated the same day — the ADR log, the container view, a new dynamic view, the carrier-failure example, the delivery map, and the rollout contract. The referral volume model re-ordered the plan, taking the scope trade the week-1 forecast had pre-identified; the designer dissented, and the threshold that would prove him right was instrumented before exposure opened, adding a telemetry measure whose only job is to adjudicate a disagreement. And the comprehension test changed nothing, on purpose: two of five is too small a sample to separate a wording problem from two participants, so the wording changed (cheap and reversible) and a retest was commissioned, but no expensive decision moved. A review in which every piece of evidence conveniently supports the existing plan is a review that is being performed rather than run.

Full review page and closeout checklist: weekly-review-and-closeout-checklist.md.