All 1 sends the app fires itself, out of the app, each with its call: 0 move to Braze, 1 stay native, the rest retire, need a decision or belong to another journey. These calls are this pack’s proposals, to be agreed with Engineering.
| The send | When in the journey | The call | Who does the work |
|---|---|---|---|
| Booking and ticket confirmation view (in-app surface) In-App | STAYS NATIVE | No work▸ What fires it, and whyWhat fires it Live. The app's confirmation view shows the booked trip and the won upgrade. It is the only surface in the window that requires no marketing permission.Why, in one line Evolves into the persistent trip state: the consent-free home of the whole arc, the deep-link target of every send, and the entire journey for the non-contactable.What decides or enables it The Product surface decision; the interim live platform source, since the live rail feed integration is blocked and product-led. |
One rule across the moved sends: a trigger that fires in the final minutes before a close is sent by the app, not Braze, so a delayed message can never land after the auction has closed. The release work sits on the switch-off row below.
12 rows: 9 data points and 3 computed traits (Analytics builds, no engineering hours). The D badge is the walkthrough pin number. Delivery fixes and app defects follow in their own sections.
The events and payloads the arc fires on. Each row is the contract; the board carries the sized asks.
| The data point | What exists today | The work | What it must carry | Phase · status · depends on |
|---|---|---|---|---|
D1The arc's entry and anchorupgrade_confirmed + departure timestamp + scheduled arrival · the departure time from the customer's boarding station · the trip id for the trip-by-ID deep linkEntry and departure need nothing new: both are live, and the webhooks already fire on the departure offset. Scheduled arrival is still needed, for the trip-completed event that ends the arc and hands to the post-trip journey (a trip completes at its scheduled arrival, 29 Sep 2026), never for an arrival message: the arrival beat is retired and arrival is a designed silence (the older arrival-beat line corrected 15 Oct 2026). | PARTLY LIVE IN BRAZE Entry and departure live and console-confirmed; whether scheduled arrival is on the trip object at the sender is unconfirmed. | Existing events | The arc's entry, every departure-anchored send's clock, and the trip-completed event's clock. Used where: Entry, and every beat's timing | PHASE 1 ships now Scheduled-arrival read to confirm The scheduled-arrival timestamp per trip reaching the sender. |
D2The live platform payloadplatform (and any coach change on the day), at fire timeThe fire-time lookup for the platform the station announces, and any coach change on the day, for the wayfinding push and the trip state; the interim source pre the live rail feed. The reserved coach and seat are booked data and come from D12, never from this lookup. | DOES NOT EXIST YET The live platform does not exist in Braze. | Connected Content + the interim source | The wayfinding push without wayfinding is a sell slot in disguise: no payload, no send. Used where: The wayfinding push and the trip state | PHASE 2 gated Signed off for the platform slice (Sheran, 15 Oct 2026, her reply to Dirk's scoping assistant): SOL051 qualifies the existing SilverRail call as the live source, one source is decided, then the platform part of SOL050 with I196, I200 and I289, so the morning push names the platform and the Live Activity shows it; the reserved coach and seat (D12) join the slice. Only a coach change on the day needs this live source. The rest of Journey 2 comes last (item 10 of the 13 Oct order): the on-board modal is Product's screen and follows the Braze send, and SOL049 and the rest of SOL050 follow the other journeys. SOL051's qualification of the source; the platform-change event. |
D12The reserved coach and seatcoach + seat per upgraded leg, from the bookingSend the reserved coach and seat on each upgraded leg to Braze with the trip, from the upgrade booking. A counted place carries no seat number: send the coach alone, and the copy falls back to it. | EXISTS, NOT IN BRAZE Held in the trips service from the upgrade booking (each leg carries coach and seat pairs; engineering documentation, not a production read). Braze holds no coach or seat attribute (custom attribute list read by API, 15 Oct 2026); whether the upgrade-won object carries them is unverified. | Trip sync extension (booked data, no live feed) | The day-before email's coach and seat line and the morning push's coach. A message never names a coach or seat that is not on the record. Used where: The day-before email (row 2), the morning push (row 3) and the trip state | PHASE 1 ships now Signed off with the platform slice (Sheran, 15 Oct 2026, her reply to Dirk's scoping assistant) Nothing new to build at source: the booking already holds it. |
D5The episode flagtrip / arc state, canvas-writtenThe canvas writes it at entry and clears it at exit; the seasonal weekly and successors exclude on it. | BUILDABLE TODAY The shared convention exists; this journey's wiring lands with the build. | Braze configuration | Broadcasts stand down inside the arc; one owner per customer, made real in audiences. Used where: The broadcast stand-down | PHASE 1 ships now With the Braze developer Nothing new. |
D6The disruption flag at fire timelive disruption, booked routeCheckable when a send fires, not at entry: every commercial send in the arc suppresses on it. | VERIFY FIRST Source and freshness unconfirmed. | Live event / fire-time check | Until it is readable, the yield rule cannot bind and nothing commercial launches inside the arc. Used where: Every send's eligibility | PHASE 1 ships now Launch gate, with Backend Engineering Nothing else. |
D8The Live Activity start tokenstart token, existing attributeThe canvas fires the pin's start webhook where the device and token allow. The Live Activity is trip-scoped, not consent-scoped: it runs for any iOS customer with the trip. Its named job is the platform reveal: it updates the moment the station announces the platform. Where it is running, the wayfinding push suppresses and the pin carries every platform or coach change (Sheran, 6 Sep 2026); the push re-issue exists only where no pin is running, which needs the Live Activity active state readable at send time. | BUILDABLE TODAY The attribute exists; the surface build is the open scope. | Existing Braze attribute + webhook | The Phase 2 pin; the push stands where the start fails. Used where: The lock-screen pin: the platform reveal at the departure board | PHASE 2 gated With App Engineering, on the release train The re-scope decision, and the live service feed's platform half in near real time (the Darwin board row). |
D9The pending-bid state at send timepending_bid: auction id, route, close timeA live open-bid read the sender can query when the wait email fires: bidders get the expectation-setting variant, and the variant exits the moment the auction closes. Evaluated at send time, never at entry. | DOES NOT EXIST YET The auction engine holds the state; no live read reaches the sender. Braze's active_auctions and active_auctions_info are written when a customer joins an auction and carry the auction-wide bid count, not this customer's pending bid, so they do not establish the state (Engineering's source check, 15 Oct 2026); a per-customer state projection or a live lookup is still needed. | Live state read / fire-time check | Without it the wait email cannot fork, and a bidder gets the generic sell while their bid is live. Used where: The wait email's bidder variant | PHASE 2 gated On the engineering board Nothing else. |
D10Live Activity active state at send timela_active (and la_state) readable by Braze at send timeWhere a Live Activity is running, the wayfinding push suppresses and the pin carries every platform or coach change (Sheran, 6 Sep 2026, J2-04); the push re-issue exists only where no pin is running. The same signal downgrades Journey 4's status pushes. Board row: la_active + la_state signal to Braze. | DOES NOT EXIST YET No readable state; the pin's start is fire-and-forget. | New attribute, written by the app when the pin starts and ends | One wayfinding answer per customer, never two Used where: Rows 3 and 3b; Journey 4's status rows | PHASE 2 gated Ruled 6 Sep 2026 (J2-04) The Live Activity start webhook (D8). |
D11Running status or delay at the on-board momentservice running status (delay minutes) at send timeThe on-board push holds where the service is delayed or its running status is unknown, so it never lands on a train that has not left; until the Darwin feed lands the send fires on the scheduled time and never claims the customer is on board. | DOES NOT EXIST YET No running-status read reaches Braze. | The Darwin feed row (the home row) or an interim read | Row 4's hold Used where: Row 4 | PHASE 2 gated Ruled 6 Sep 2026 (J2-06) The Darwin feed. |
Named here so the full picture is one table. The standing pattern: computed nightly, synced as traits, never live lookups at send time (fire-time Connected Content is the deliberate exception, and only for the wayfinding payload).
| The computed trait | What exists today | The work | What it must carry | Phase · status · depends on |
|---|---|---|---|---|
D3The persona register labelpersona_register + confidence, nightlyThe register label for the day-before copy: register changes copy only, never timing. | BUILDABLE TODAY Derivable; the same classifier other journeys consume. | Computed trait | Three copy registers on the journey's biggest reachable beat. Used where: The day-before beat | PHASE 1 ships now With Analytics The nightly sync. |
D4Booked cabin and operatorcabin + operator, at fire timeGates the per-operator inclusions and the Avanti First-against-Standard-Premium label. The lookup also carries the First Class lounge (station and operator) for the day-before email and the wait email, which absorb the retired catering email (Sheran, 6 Sep 2026, J2-01). | BUILDABLE TODAY On the trip attribute. | Fire-time attribute | The one place the class confusion (1,856 tickets a year) is resolved before travel. Used where: The wait email and the inclusions block | PHASE 1 ships now Nothing to build The per-operator content block (Design). |
D7On board: the push on the boarding-station departure, the modal latersaved_amount per trip, batchThe first version is a Braze push deep-linked to the trip's ticket screen, fired a few minutes after the scheduled departure from the boarding station and held on delay or unknown running status (Sheran, 6 Sep 2026, J2-06); the consent-free in-app modal is the later version. Board row recnqrGpirsD75YS6 carries the four asks: which station the trip timestamp refers to, the trip sync, the delay hold, the trip-by-ID link. | VERIFY FIRST Derivable; the anchor needs substantiation. | Braze push on the trip attribute (no app release); the modal is an app build later | The value moment's number; a made-up saving at that moment would be the worst possible lie. Used where: The on-board modal | PHASE 2 gated Ruled 6 Sep 2026 (J2-06) The substantiation. |
Not listed because there is nothing to build: the purchase entry event and departure timestamp (live today, the webhooks fire on them), and the day-before family's trigger, kept unchanged as the control.
Seven changes the customer never sees: what is broken today, the fix we are asking Engineering for, and why it belongs in this journey rather than a general engineering backlog. None is a comm and none needs a decision from Marketing. Each one either loses a message this journey depends on, or decides whether something else can be built at all.
The builds and investigations the arc waits on: the two data paths that decide phases, the two app builds, and the estate's one unexplained send path.
| The delivery fix | The fix we are asking for | Who does it | Phase |
|---|---|---|---|
| The journey ownership flag (journey_state): the shared build | Build journey_state once, estate-wide: one attribute carrying the owning journey, the episode id and the entry time. Every owning canvas writes it at entry and clears it at exit; every broadcast and wave segment excludes on it; it is mirrored nightly to the warehouse and readable at render by the home surface. The Braze developer wires the canvases and the exclusion segments, Engineering mirrors it to the warehouse and exposes the render read, Analytics keeps the state history. One board row carries it for all ten journeys. | BACKEND ENG | PHASE 1 ships now ▸ The problem today, and why it sits hereThe problem today Every journey's stand-down and hand-off assumes one owner per customer, and the flag those rules read is campaign-written today: invisible to broadcast segments, the warehouse and the app, so the rule cannot be enforced. Two live journeys can reach one customer in one week with clashing messages.Why it sits in this journey Here it stands the seasonal weekly and every broadcast down while the pre-travel arc owns the customer. |
| The interim live platform source | Engineering confirms the interim source and its freshness; a platform-change event Braze can act on comes with it. | BACKEND ENG | PHASE 2 gated ▸ The problem today, and why it sits hereThe problem today The live platform does not exist in Braze today, and the live rail feed integration is blocked and product-led. The reserved coach and seat are booked data and reach Braze by the trip sync (D12), not this source.Why it sits in this journey It decides the wayfinding row's phase: an existing attribute pulls it into Phase 1, a new feed holds it in Phase 2. |
| Refund and cancel events at Braze | Confirm the path and latency; wire arc suppression on both. | BACKEND ENG | PHASE 2 gated ▸ The problem today, and why it sits hereThe problem today Whether the events reach Braze fast enough for instant arc suppression is unconfirmed, and nothing consumes them today.Why it sits in this journey A cancelled trip must flip the state and suppress pending sends instantly, or the arc congratulates a dead trip. |
| The trip-state surface and the on-board modal | Product rules the surface; App Engineering builds both; the reskin is the smaller build. | BACKEND ENG | PHASE 2 gated ▸ The problem today, and why it sits hereThe problem today The persistent trip state (reskin or net-new is Product's call) and the consent-free on-board modal are the journey's two app builds.Why it sits in this journey The state serves the 18 percent with no proactive channel and is the deep-link target of every send in the arc. |
| The legacy swap push's caller | Identify the caller in the console with Lisa, confirm the rebuild covers its cohort, then retire under the archiving rule, reason recorded. | BACKEND ENG | PHASE 1 ships now ▸ The problem today, and why it sits hereThe problem today It fired daily through 13 August though its only known trigger stopped on 20 July: the estate audit's one unexplained send path.Why it sits in this journey A duplicate reminder from an unidentified trigger, in the window where contact pressure costs most. |
Live defects in the window: the swap-eligibility defect, and the legacy swap push firing with no known caller.
| The defect | The fix we are asking for |
|---|---|
| The swap-eligibility defect | The fix date is with Product and Engineering.▸ The problem today, and why it matters hereThe problem today The defect gates the seat-swap path inside the arc.Why it matters here Until it lands, the swap path stays closed for the won-trip cohort. |
| The unexplained send path | Identify, confirm coverage, retire.▸ The problem today, and why it matters hereThe problem today The legacy swap push fires with no known caller, outside every rule.Why it matters here A customer in scope for both can receive the same reminder twice in one morning. |
Source: the console trigger pass of 14 to 16 August 2026, the 13 August pull, and the matrix spec. Board rows are the system of record for the sized asks.