Contact strategy & orchestration

The one set of contact rules every journey obeys: states before tiers, caps by message class, quiet hours on our clock only, plus the cross-channel timeline showing how the moments sequence without colliding on one customer. Edit home: Airtable · Contact & channel rules (source of truth once signed). Cap dials below are ratified 28 Jul as backstops, not selectors (the 28 July contact ruling).

How the lifecycle engine works, end to end

One home per layer: the global contact rules live on this page; each journey’s applications and exceptions live on its own review pack (the TO-BE map’s rules panel); unresolved arbitrations sit in the decisions log. The engine’s build requirements are tracked on the scoping board (rows tagged Lifecycle engine), scoped with Engineering on 30 Jul.

Ten journeys, one brain: a nightly table in the warehouse decides each customer's single next best action (the one message, or silence, we pick for them today), and Braze executes it. Built with dbt (the SQL modelling tool already running in the warehouse). Nothing here is new infrastructure.

One brain, two speeds. Slow decisions (who owns this customer, their next best action) are computed nightly in the warehouse. Fast moments (an auction closing, a train departing) stay event-triggered in Braze and never wait on the batch; they read the table for context only.

Architecture reference: how one decision is made

Working standard, DRAFT for ratification. This is the decision function every journey's decision table is authored to. The contact rules above are the constraint layer: they decide whether anything may send. This schema decides what sends, to whom, on which channel, and what happens next.

Five steps, fixed order. ① Eligibility gate: may anything send at all? Suppression, caps, active states and quiet hours rule first (the contact rules above); the verdict is serve, hold or queue. ② Targeting: which profile axes tailor at this moment (the discrimination rule below); only surviving axes create rows. ③ Treatment: the message and CTA per surviving cell, one job per touch, matched to the customer's barrier. ④ Channel arbitration: in-app first, push as the unseen fallback, email for considered content, forked by consent, never two channels doing the same job at once. ⑤ Timing: immediate, dwell-triggered, or anchored to the customer's clock, inside quiet hours.

The discrimination rule (the axis library). No customer axis earns rows by convention. Per moment, every library axis gets a verdict: tailors (it changes the message, timing or channel here, so it earns rows), same for all (considered, does not change treatment here, collapsed to one row with a one-line why), or not applicable. Typically one to three axes survive per moment; a table carrying every axis at every moment is unauthored. An axis enters the library only with band definitions, population sizes, evidence it discriminates, and its data status.

The road from rules to learning: Q3 runs this schema as authored rules executed in Braze. Q4 lets the decision log train a model that ranks candidate treatments inside the rules. The end state is real-time 1:1 arbitration across channels. At every stage the contact rules stay the guardrail the engine cannot override, and the build requirements stay the Lifecycle-engine rows on the scoping board (no new asks).

Segmentation & journey-state, the foundation

Lifecycle-stage cut-offs, how many days since a user last transacted defines their stage. Every journey targets off these, so we need one agreed set.

Who wins when a user qualifies for more than one journey → the arbitration order below.

Arbitration order: the layers

States & exceptions

Cap classes

The send class decides the treatment, never the platform (ruled 22 August). Every auction-linked send ships from Braze as service class: consent-free, uncapped, never suppressed by anything commercial. One guard: inside the final minutes before a close the native path still sends, because a status message landing after the close is a recorded harm. A second guard runs the other way: an open support complaint suppresses every marketing-class send until the complaint resolves, null-safe where the flag is missing so nothing waits on the feed. Service-class sends are exempt: auction status still reaches a customer with a complaint open.

Same-day priority order, when several comms qualify at once

Ruled 9 July. Higher tier wins the slot. A sell never leads on the highest-stakes day.

One lapse owner per customer

A slipping customer is owned by exactly one journey at a time, so nobody gets two lapse messages in one episode. Triggered outranks scheduled; DEFEND outranks RECOVER. The journey_state field arbitrates, and it is one write with one owner so there is no second clock to drift.

The six dials, ratified 28 July

Signed in one pass, as backstops, not selectors: the decision table picks the message, the dials only stop the Nth one.

Journey standards: the template every journey must fill before build

No template, no build. Every field below must be stated in the journey pack before a canvas is briefed.

Channel roles

• Push interrupts, for time-bound moments.
• Email carries considered content where consent is held.
• In-app surfaces convert consent-free, in the session.
• Content cards persist until acted on or expired.
• Live Activities track live events on the lock screen, iOS only.

Full mechanics library, limits and Native-vs-Braze build tags → Mechanic reference. Each journey's channel ladder lives on its pack's TO-BE map.

The cross-channel lifecycle timeline

How the moments sequence across channels through the lifecycle, the picture the arbitration rules above keep collision-free.