# Delivery and dependency map A delivery plan should retire uncertainty, not arrange component tasks. Connect the real path early, then grow behavior through thin, demonstrable slices. Source: lesson 0047 · Plan the Walking Skeleton. --- ## Blank — walking skeleton sentence > From `[real source branch / build]`, move one `[controlled user action]` through > `[real deployment, real boundaries, representative storage, one representative adapter]` > and prove it with `[telemetry or demo]`. Then list **every** fake or hard-coded behavior in it. An undeclared fake is how a skeleton becomes a demo that cannot grow. The business behavior may be deliberately tiny. The delivery path must be real: real build, real pipeline, real deployment, real boundaries, real telemetry. --- ## Blank — delivery map Sequence by four forces: **learning** (put the highest-impact weak assumption where it can be tested early), **technical risk** (exercise the unfamiliar integration, migration, load, or security boundary before easy screens fill the calendar), **dependency** (obtain access, decisions, and ownership before they block finished work), and **value** (each increment coherent enough to demonstrate in user language). | Milestone | Evidence produced | Exit condition | Risk or assumption retired | | --- | --- | --- | --- | | `[name it after what becomes true]` | `[what can now be demonstrated]` | `[observable, binary]` | `[from the assumption map or driver table]` | Never report "percent complete". "Carrier integration: 80%" hides the unknown last behavior. --- ## Blank — dependency rows | Dependency | External owner | Exact deliverable or decision | Needed by | Readiness evidence today | Fallback | Escalation trigger → recipient | | --- | --- | --- | --- | --- | --- | --- | "Waiting on platform" is not a plan. An owner, a date, evidence, a fallback, and a trigger is. --- ## Blank — forecast | Field | One-line guidance | | --- | --- | | Range and confidence | A range, not a date. State the confidence you actually have. | | What changed | Since the last forecast. If nothing changed, say so. | | Fixed | Which of outcome, date, scope, team is genuinely fixed. | | Movable | The one variable that can absorb the difference. | | Smallest scope trade | The smallest cut that preserves the outcome — decided before you need it. | | Next evidence | The date the forecast will change, not the date it becomes impossible. | Reforecast when evidence changes, not when the original date becomes unachievable. --- ## Completed — returns resolution pilot ### Walking skeleton > From the main branch, deploy one internal-user return request through the production > pipeline; persist its intent, cross the carrier port with a fake adapter, render "pending > label" on the real status page, and find the complete request by correlation id in the real > logging stack. **Real:** the build, the pipeline, the deployable, the database and its migration, the module boundaries and their import check, the outbox, the worker process, the correlation id, the telemetry pipeline, the status page. **Fake or hard-coded — stated, not implied:** eligibility always returns accepted (no policy at all); the carrier adapter returns a fixed label id after 100 ms; order lookup returns one fixture order; no notifications; no authorization beyond "is signed in"; warehouse receipt is a button on an internal page. **What it proved in week 2** — three things nobody had 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. ### Delivery map | Milestone | Evidence produced | Exit condition | Retires | Owner · target | | --- | --- | --- | --- | --- | | Path walks | One request deploys, persists, crosses the port, and is traceable end to end from a clean build | Repeatable from a clean checkout; a forced failure is visible in the logging stack within one minute | Integration and deployment risk | Dana · week 2 | | Policy works | The 200 sampled agent decisions run as tests against `assess` | Anya accepts the decisions *and* the refusal reasons on the sample; disagreements are logged as rules, not bugs | Assumption A1 | Sam · week 4 | | Team uses it | Internal users complete the accessible happy path and both refusal paths on their own devices | No severity-one usability, accessibility, or authorization defect open | Assumption A2 in part, and driver D3 | Marco · week 5 | | Pilot learns | 1% of eligible demand exposed against a matched control; outcome and guardrail measures readable | The pre-agreed continue / change / stop thresholds can actually be evaluated at n ≥ 120 | Assumption A6, risk R1, and the outcome itself | Priya · week 6 (29 Sep) | | Scale earns | Load at 40 rps, a carrier recovery drill, the support runbook exercised, a steady-state owner named | Every rollout gate passes and the disable path has been exercised twice | Drivers D1, D2, D5, and operational ownership | Nils · week 9 | Enabling work lives inside the slice it enables. The outbox migration, the adapter contract test, and the label-backlog alert are part of "an eligible customer reaches pending label" — not a separate architecture-runway phase nobody has yet earned. ### Dependency map | Dependency | Owner | Exact deliverable | Needed by | Readiness evidence | Fallback | Escalation | | --- | --- | --- | --- | --- | --- | --- | | Carrier sandbox credentials and rate limit | Asha (platform) | A sandbox key with 20 rps, plus the production key held in the vault | Week 2 | A test call succeeded on 26 Aug | The fake adapter behind the real port — the skeleton is designed to proceed without it | Not delivered by Wednesday → platform lead | | Payments refund API scope | Ravi (payments) | Written confirmation that partial refunds are out of scope for the pilot and that `return_id` is accepted as the idempotency key | Week 3 | Confirmed in writing, 8 Sep | Refund requests queue for an agent; the pilot still measures the decision outcome | No answer by end of week 3 → engineering director | | Warehouse receipt event access | Warehouse platform | Read access to the receipt stream plus 30 days of history for the A4 replay | Week 2 | Replay completed 3 Sep | Manual confirmation, which the pilot uses anyway per ADR 0005 | Access refused → escalate as a scope trade, not as a delay | | Privacy and security review | Ola | Sign-off on data minimization to the carrier, 30-day retention, and the log-redaction fitness function | Before the staff-accounts stage | Draft review 5 Sep; the log-retention finding was raised by the skeleton | **None. This is a gate, not a risk.** Exposure does not start without it | Not signed 5 days before the stage → CISO | | Support staffing for referrals | Nils | Two agents rostered for the 4-hour referral SLA during exposure hours | Week 6 | Roster published 22 Sep | Reduce the exposure percentage rather than break the SLA | A roster gap → head of support, same day | 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 is what converts an escalation from a complaint into a decision request. ### Forecast | Field | Entry | | --- | --- | | Fixed | The 30 September pilot-open date (seasonal). The team of seven. The outcome and its guardrails. | | Movable | **Scope.** With a fixed date and a fixed team, scope is the only control surface — and saying so in week 1 is what makes the week-6 trade a decision rather than a crisis. | | Forecast | Pilot open to 1% between **26 September and 3 October**, about 70% confidence, based on four completed slices at a measured 4–7 days each. Not "30 September": a single date at this range is a claim the evidence does not support. | | Smallest scope trade that preserves the outcome | Drop the in-product appeal flow to slice 2 and keep "refused, with a reason and a link to contact an agent". It costs a worse experience for the 11% of requests that are refused and saves about five days. It does not touch either 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 matched control cohort. Trading those buys days by removing the ability to know whether the pilot worked. | | Next reforecast | At the "Team uses it" milestone, or immediately if any dependency's escalation trigger fires — **not** only when the date becomes impossible. | **Traces to:** every milestone names the assumption, driver, or risk it retires; the "Pilot learns" milestone is the first point at which the outcome in `initiative-frame.md` is measurable at all; the scope trade is taken on evidence in `weekly-review-and-closeout-checklist.md`; the gates are `rollout-contract.md`.