SESSION HANDOFF — the journey page, Aga's rulings, and six retractions

7 Aug eve → 10 Aug 2026 · read this before touching the post-quiz journey, the abandonment lanes, 750 TMA | Welcome Sequence After Quiz, or the customer-journey page.

The one-line state: the post-quiz journey is now DECIDED and drawn; the abandonment machine is BUILT and drafting; nothing is blocked on analysis. Five things wait on Aga, and one of them is a one-minute click.

0 · WHERE EVERYTHING LIVES

🔴 Never hand-edit the page. Edit the docs or the partial, run the builder, deploy. It regenerates on every sync.

1 · AGA'S RULINGS THIS SESSION — all binding

2 · 🔴 SIX RETRACTIONS — READ THESE OR YOU WILL REPEAT THEM

Every one was mine, caught by Aga or by measurement. The estate's memory carries all six; the docs carry them inline so the page cannot mislead her the way I did.

🔑 The pattern in 1, 2 and 4: I treat a dead artefact as if it were the whole channel. Before saying "we never do X", name which artefact would prove it — usually a sent log, a --help, or one API call I have already made.

3 · THE DECIDED FLOW (what to build toward)

T+0    ① verification        ② the access email — plan · login · [N] free workouts · no card
                                (was Nic's T+1h login email; RETRIGGERED to email-capture, EVERYONE)
                                RETIRED: "{Name}, your results are ready!" (printed [Chosen Password])
T+2h   ③ welcome E1 — they MEET us          ← first-timers don't know us; this must come first
~24h+  ④ the abandonment note — now the ASK  ← the lane's own ≥24h rule enforces this order

✅ No builder change is needed for the ordering. The lane already refuses to draft before 24h ("the Django send owns the first hour", 7 Aug). "Wait 3 days" was an unexamined phrase inherited from the strategy doc's "recovery owns days 0–3" — it is retired.

The welcome: evolve 750 TMA | Welcome Sequence After Quiz slot by slot. Live scoreboard, 10 Aug (13 slots clear the ≥200-send bar):

⚠️ 2985 and 3715 share a subject line at very different volumes — never treat them as one slot. The estate's older "769 sends / 2.86% unsub" figure matches neither live campaign.

4 · MEASURED FACTS WORTH INHERITING

• 52 of 52 contacts tagged NEW quiz-reached-checkout are also inside 750 TMA | Welcome Sequence After Quiz — recovery and welcome talk over each other today.
• 750 TMA | Welcome Sequence After Quiz carries 29 attached campaigns, not the "10" the estate kept saying — including "Gareth Case Study | 50% OFF | 48h LEFT" (~16k sends: a hard discount deadline inside a welcome) and two zero-send "New Campaign" strays.
• There is NO send path for the hello@ note. Its docstring: "drafts only, Aga sends; no --live exists." 40 drafts created · 39 sent · 1 waiting in Gmail now (gate-cleared).
• cart_abandon_reconcile.py (v3 / normal checkouts) has NEVER RUN — no state file, not scheduled, absent from the job register. v3 has ≈0 identifiable abandoners anyway ($24.97/90d), so: wire the capture job, defer the arc behind ≥20 abandoners/30d.
• 756/757 Abandoned Cart Reminder: 0 ever entered. Enrolment refused (sentinel absent).
• Cross-system handshakes: quiz→AC ✅ · workout-1 via com.tma.funnelstage ✅ (fields 78/79) · purchase→AC ✅ · "they reached checkout" → the welcome ❌ · "has anyone emailed them today" is one-way — only our note asks; AC and Django never ask anybody.

5 · WHAT SHIPPED (code + page)

Queue: AGA-137 closed on arrival evidence (750 paused 16:41 → un-paused 18:03; the proof was a new entry at 18:22:50, not the status flag). FLEET-49 opened for the deferred wording sweep.

6 · OPEN — AND WHOSE

🔴 Uncommitted: this session's code is on disk on branch proto-deploy-1777257452, not committed — Aga was told and hasn't asked for a commit.

7 · THE TRAPS THIS SESSION PAID FOR

1. filters[automation]= on /contactAutomations is SILENTLY IGNORED — returns every automation. The tell: total 611,152 exceeded the automation's own entered 19,805. Use automations/<id>/contactAutomations. Cross-check a filtered total against a count you already trust.
2. ACTIVE is a status, not an arrival. A closure needs the artefact working, not the flag.
3. open(P,"w").write(open(P).read()...) truncates before it reads — a canary of mine "passed" a guard by testing an empty file. Read first, then write.
4. Two dicts sharing a key + .index() = the wrong insertion point. Anchor on the enclosing structure.
5. A "MUST NOT GO BACK" note I wrote myself is a decision with a premise, not a law. Write the premise beside the rule.
6. Goals and branches are API-invisible; a campaign's parent automation is NOT. So "AC structure is builder-only" over-claims — say "cannot create or edit structure, and cannot see goals or actors."
7. A naming lookup is also a liveness probe — ac_registry.py printing inactive where the markdown registry said ACTIVE is the only reason the 82-minute welcome outage was ever noticed.

8 · MEMORY (already written — start here, not with this file)

aga_the_four_email_post_quiz_flow_2026-08-10 · aga_rulings_2026-08-10_buyer_exit_and_evolve_750 · reference_the_hello_abandon_lane_detects_but_does_not_send (name is a misnomer, corrected inside) · feedback_active_is_a_status_not_an_arrival · reference_ac_automation_state_watchdog · ac_api_traps_filter_silently_ignored_2026-08-07 · reference_transactional_email_architecture_and_abandon_trigger · feedback_never_hand_run_netlify_deploy_use_estate_sync

Personalisation, explained — what we know, where it goes, how an email becomes personal

The plain-language home of the personalisation engine. Ordered by Aga, 7 Aug 2026: "a subpage that talks about personalization… step by step, everything that needs to be known, so the engines are gonna live here… explained as it would be to a layman's person." One engine powers every journey — quiz, abandonment, win-back, and whatever comes next. The technical contract lives in ABANDONMENT_PERSONALISATION_ENGINE_2026-08-07.md; this page is the version a human reads first.

1 · What we actually know about each person

When someone finishes the quiz, they don't just give us an email address. They tell us, in their own words, who they are. Since 7 August we save all of it — before that, it was thrown away the moment the quiz ended.

Two honest limits, so nobody over-promises:

• The richer answers only exist for people who reached their results screen. Someone who typed an email and left told us their goal and their obstacle — nothing else. The emails must work either way (see §4).
• This started on 7 August. Anyone from before that date has only their goal and plan saved. The data grows richer every day from here.

2 · Where it all lives

Think of it as one card per person inside ActiveCampaign (our email system). The quiz writes the answers onto the card the moment they happen. The app reports every night who trained. The checkout reports who opened it. Everything about one person, one place.

Two things worth knowing about the plumbing, in passing:

• The "your results are ready" and login emails come from a different system (the website itself, via SendGrid). That system knows nothing about the card — which is one reason today's first-day emails feel disconnected from each other.
• The app's "did they train?" signal updates once a night. So "send the pitch after their first workout" means the next morning — which is honestly the better moment anyway.

3 · How an email becomes personal — step by step

Here is the whole trick, and it's simpler than it sounds:

1. A small program reads the person's card and writes finished sentences onto it — one per slot. Not codes, not labels: real sentences. For a man in his forties with gym experience whose obstacle is plateaus, it writes: "And you told the quiz that hitting a plateau is what's been holding you back."
2. The email contains slots. Where a generic email says "training is hard to stick with", ours has a slot that says: put this person's obstacle sentence here.
3. ActiveCampaign fills the slots at send time — the same way it already fills in a first name. Each person gets the sentence that was written for them.
4. A matching real member is chosen as proof. The engine picks a verbatim quote from a real member who matches their goal, age band and gender — a 45-year-old man chasing muscle sees a 45-year-old man's words, never a random testimonial.

So a real email reads like this (this is actual output, not a mock-up):

Subject: about the plateau you mentioned The quiz built you a muscle plan that starts at your actual strength level. And you told the quiz that hitting a plateau is what's been holding you back. For men in their forties, with years of gym training behind them, progressive calisthenics is actually perfect. And the quiz says that's exactly where you are. …followed by a real member, his age, his words.

Why we do it this way and not "smart templates": ActiveCampaign cannot do if/else inside an email. We tested this properly — zero of 539 real emails in our account use conditional blocks, because they don't exist in AC. Any "conditional" markup just shows every version to every reader. So the intelligence lives in our program, and the email stays dumb and reliable.

4 · The safety rules — in plain words

These are laws, enforced in the code, not preferences:

1. If we don't know something, the sentence degrades gracefully — it never guesses. No age? The "people like you" line talks about their goal instead of their age. No obstacle? That paragraph simply isn't there. Guessing wrong ("in your 40s" to a 25-year-old) is worse than generic — it turns "Jesse knows me" into "this is a template that missed".
2. An empty slot must never leave a hole. A missing field renders as nothing in AC — so every slot is always written, with a sensible default when the data is missing, and slots are whole paragraphs, never half-sentences.
3. A buyer never gets a sales email. Every lane checks "have they paid?" at the moment of sending — and if the check itself fails, we treat them as paid and skip. Losing one send is fine; selling to a customer is not.
4. One conversation at a time. If the recovery emails own someone this week, the welcome waits. Nobody gets two competing offers at once.
5. No claims the code doesn't keep. The $97 window is not enforced by the checkout yet, so no email may say "expires in 48 hours" until it truly does.
6. Real quotes only, word for word, from the tagged testimonial database — and the member's own real details carry the proof even when we know little about the reader.
7. Everything is logged. Every run writes a per-person record: what we knew, which sentence each slot got, which quote was chosen, which link was used and that it worked. Anyone can audit any email after the fact.

5 · What's live today vs being built

6 · Who does what

• The engine renders sentences and picks proof. It never invents copy.
• The email fleet writes every sentence variant, through the full review gates (voice, formatting, facts, deliverability). The engine only stores what the fleet wrote.
• Aga approves copy, arms anything member-facing, and owns the decisions.
• ActiveCampaign just delivers — the same way it always has.

The one idea to keep: we stopped trying to make the email system clever. The cleverness happens on our side, per person, before the send — and every journey (quiz, abandonment, win-back) draws from the same card, the same engine, the same rules.

THE POST-QUIZ JOURNEY — the strategy of record

⭐🔴 THE master strategy for everything a person receives after finishing the quiz — ordered by Aga, 7 Aug 2026: "I really need a strategy on the quiz journey sequence… a document outlining the proper right way. Emails that are currently going out are still not personalized, and then obviously there is the abandonment on top." Scope: from the second the quiz ends until they buy, opt down, or hand off to re-engagement — both the free-app journey and the money journey, and how the abandonment estate overlays it. Sister master: ABANDONMENT_STRATEGY_2026-08-07.md owns Stage 4 (recovery) in full; this doc owns the journey it overlays. Data law: LEAD_SIGNAL_CONTRACT_2026-08-06.md §8. Engine: ABANDONMENT_PERSONALISATION_ENGINE_2026-08-07.md. Every number tagged [LIVE] / [MODELLED] / [UNVERIFIED]. Nothing in §7 executes without Aga's approval of the J-decisions below.

🟢 STATUS UPDATE — 10 Aug 2026 (live-verified, gate-passed): three of this doc's findings are now RESOLVED. (1) The welcome arc no longer sells — Aga ruled "no welcome emails should have 50% off" and it was executed the same day: 0 offer references across all 24 live messages of 750 TMA | Welcome Sequence After Quiz (measured via the API, tma-ac-upload-integrity PASS). (2) The welcome CTA question is RATIFIED LAW: activation-first, per WELCOME_CTA_DOCTRINE_2026-08-10.md (owner seat tma-welcome-sequence-owner) — and W7 (day 7) now carries the arc's ONE soft ask: the 7-day free trial (checkouts-v3/trial/12month/, all 3 split variants, fleet-written and QA-gated). This replaces §5.1's "move or change price" options for the old E5/E7/E8 asks — they are gone, not moved. (3) Stage 2's data question is answered: the workout-1 signal lives in Intercom (workouts_finished_number, minutes-fresh — verified live 10 Aug; ~48 people/day hit workout #1; census: 2,805 trained-never-paid). The Stage-2 morning-after email is designed as an event overlay (nightly 0→1 tag → mini-automation → send at ~8am; W7 skip-condition for the already-pitched) and awaits Aga's build GO. Note: the Stage-2 ask shipped as the free trial, not the $97 — per the ratified doctrine and Aga's no-offer ruling; J4's two-price design now applies to Stages 3–4 only.

0 · THE VERDICT — and the six decisions

TMA treats a new quiz lead as an email list to drip on, when they are actually a free user we have 72 hours to activate. The journey a lead meets today was assembled system by system — four transactional sends, a welcome drip, a planned sales arc, an abandonment overlay — and no layer knows what the person has actually done. The result, measured: five to six emails in the first 18 hours with no single ask, a welcome arc personalised by first name only while ten fields of quiz data sit unused, the product's own free trial (3 workouts, no card) treated as a consolation prize instead of the conversion mechanism, and the highest-intent moment in the entire funnel — the minutes after someone completes their first workout — carrying no email at all.

The fix is one journey with five stages, gated on behaviour rather than time, built almost entirely from assets that already exist. Behaviour-triggered onboarding beats time-drips by ~22%, and activated users convert at 5–10× — the strategy below is the industry-standard shape applied to TMA's actual assets.

The six decisions (J1–J6). Everything else in §7 is fleet work:

1 · THE CURRENT STATE, MEASURED — what a quiz lead actually receives

Sources: the SendGrid census (sendgrid_transactional_check.py), the AC live reads behind REVIEW.html (build_review_page.py), the abandonment master §1a, and the estate sweep of 7 Aug. 🔴 One law inherited from building that review: the AC API cannot tell you an automation's order — ordernum ties and parent is empty. Order is read from SEND VOLUME (the first email always carries the highest), and any step under ~55% of the top is badged position uncertain.

1a · The first 18 hours (both funnels' shared trunk)

1b · The drip after day one

750's 10 live emails run on time, not behaviour. Personalisation census across the whole journey (750's 10 + the evergreen's 19 + 760's 13 = 42 emails): %FIRSTNAME% 42/42 · any quiz field 0/42 [LIVE census 7 Aug] — Aga's complaint is exactly correct and not an exaggeration. 🔴 And the evergreen arc's %FIRSTNAME% has NO fallback in 19/19 files (750 and 760 use %FIRSTNAME|there%) — a no-name contact opens with ", If you're…". Fix in build_evergreen_sales_arc.py, never the output files.

🔴 [RESOLVED 10 Aug 2026 — the arc no longer sells; kept as the record of what was.] 🔴 750 is not a pure welcome — it already SELLS. Three of its ten emails carry /50promo (E5 "Marcus waited 11 years" — the real first ask · E7 soft mention · E8 "last one"). So the journey's CURRENT state has the 50%-off ask landing from ~day 10 inside the welcome — before any sales arc — which collides with both the $97 quiz window AND any future evergreen event. §5.1 resolves this. (Historical trap, fixed 6 Aug: E4/campaign 3107's "50% OFF | 48h LEFT" existed ONLY in the plaintext alternative — the phantom-offer class.)

Its terminal enter-block (ordernum 19) points at 751 Nurture Sequence 1 today [LIVE 6 Aug API read]; the chain runs 751 → 758 → 759 where 758 holds 14,619 in flight with zero offer on any surface (registry's 4,163 is stale — two independent Aug reads agree on ~14.6k) and 759 reads 0 entered despite a live inbound block [UNVERIFIED why — builder-only]. The planned repoint to 760 School of Strength (NEW) (AGA-113, open) would insert a second sales clock — see J3. 🔴 Two 4-Aug rulings on 750 remain unexecuted: pull campaign 3715 from E1 (still sending — 5,540→5,622) and move 750 to a day-3–4 start (gated on the [Chosen Password] fix).

1c · The sales layer that exists but has never fired

The evergreen 50% arc: 16 emails (D-3→D13, PLF shape, $78.50 annual as "six months free"), built 6 Aug from the proven Memorial Day library, all 19 files lint-PASS, not uploaded, entry undecided (DEPLOY_SPEC.md §2 offers two mutually-exclusive entries and defers to Aga). Its promo opt-out is a mailto: because no preferences page exists — all five candidate URLs 404 [LIVE 6 Aug].

1d · What this adds up to

• Volume without an ask: 5–6 emails in 18h, none of which asks for the sale (the abandonment master's headline — it holds for the whole journey).
• Data without personalisation: persona + obstacle on every lead, eight more fields on results-seen, ten AC fields live — used by zero live sends.
• A free trial without a journey: the product gives 3 workouts free with no card, and no email is triggered by whether the person ever does one.
• A sales engine without an entrance: 16 finished sales emails wait on one builder decision — and no queue row authorises their deployment at all (fixed this session: J3 carries it).
• 🔴 The buyer exit is UNVERIFIED — the highest-stakes unknown in the journey. Two sources contradict: the Aug reads cite 750's If customer — END goal as "what stops buyers being sold to"; the June architecture audit measured exit_on_conversion=0 on every automation. Goals are builder-only to inspect — a five-minute check for Aga (§7 Phase B). Independent evidence the exit LEAKS regardless: a paying customer (jacnast@) was found inside 992's lead welcome.
• 🔴 The verify-email double-welcome is live and was UNOWNED. Clicking "Verify Your Account" runs activteUserAndToList() → tag free_signed_up_mobile_&_web → enrols into 992 TMA | Welcome Sequence AFTER APPSIGNUP AB TEST Aug4th. Half of 992's first entrants were the wrong audience (a quiz lead in TWO full welcome arcs; a paying customer in a lead arc). A fix row now exists (minted 7 Aug PM — J1 kills the email; the row covers the tag routing).

2 · THE STRATEGY — one journey, five stages, gated on behaviour

Design principle: email follows what the person DID, not how long ago they quizzed. The quiz's promise is "your plan is ready" — every touch either helps them use it or asks them to own it.

quiz ends
   │
   ▼
STAGE 0 · ARRIVAL (T+0, transactional — ONE email)
   "Your results are ready — your plan, your login, your first workout."
   (results-ready + login/free-workouts merged · verify killed · nothing else sends day 0)
   │
   ▼
STAGE 1 · ACTIVATION (day 0–3 · goal = WORKOUT 1, not money)
   branch nightly on field 78:
   ├─ did workout 1 (`no_trial`)  ──────────────► advance to Stage 2 NOW
   └─ never opened it (`no_workout`) → ≤3 nudges, zero price talk
        └─ still nothing by day 4 → Stage 2 anyway (soft fallback form)
   │
   ▼
STAGE 2 · CONVERSION (behaviour-triggered · the pitch)
   "You just felt what it does. Here's the year." — $97 while their quiz window lives (J4)
   persona/obstacle-personalised via the engine's pre-rendered fields
   2–3 beats: the ask → objection+guarantee → the smaller door (quarterly $49.97)
   │  buys → STAGE B (buyer) · 975 onboarding — exits everything, everywhere
   ▼ unconverted by ~day 8–10
STAGE 3 · THE SALES EVENT (the evergreen 50% arc, 16 emails, D-3→D13)
   the scheduled second-chance engine · $78.50 · enters HERE (J3), never in parallel
   │ unconverted
   ▼
STAGE 5 · THE LONG POOL
   751/758 nurture (with a designed exit, not a dead end) → 991 re-engagement → sunset

STAGE 4 · RECOVERY (event-driven OVERLAY, any time)
   reached checkout + didn't pay → the abandonment estate (its own master)
   entering recovery PAUSES whatever stage arc is running (00g: one conversation)

The one clocked table (extends the abandonment master's §5.2b — that table remains the timing authority for Stage 4; this is the journey view):

Frequency stays legal by construction: one arc owns the contact at any moment; the Core-tier 1/day ceiling and the 00g one-offer-conversation rule are properties of the design rather than checks bolted on. abandon_collision_gate.py remains the pre-send instrument for the Gmail and Django layers AC cannot see.

3 · PERSONALISATION — the plan for "the emails are still not personalized"

3a · What powers what

The three laws travel everywhere (from §8 + the engine): stage-gated completeness · an unset AC field renders as an empty string, so every slot is written with a default · AC cannot branch — personalisation is pre-rendered in code, one merge tag per slot, never data-ac-condition.

3b · What this looks like in a real email

Tier-A pitch opener, rendered per person by the existing engine:

subject: "about the plateau you mentioned" · "The quiz built you a muscle plan that starts at your actual strength level. And you told the quiz that hitting a plateau is what's been holding you back — that's what the first month is built around."

3c · 🔴 The one honest constraint — the behaviour signal is NIGHTLY

Fields 78/79 refresh from Intercom once a night (02:30). So "the pitch lands after workout 1" means the morning after workout 1, not the hour after. That is still ~100× better than day-0 pitching, and next-morning is arguably the better moment anyway (they wake up feeling it). If we ever want same-hour triggering, that is an Intercom-webhook build for Nic — deliberately NOT in this strategy's build plan; the nightly grain ships now.

4 · GOVERNANCE — priority, exits, and the rules that keep it honest

1. Priority ladder when two things could touch one person: Stage 4 recovery > Stage 3 sales event > Stage 1–2 arcs > Stage 5 nurture. Entering a higher stage pauses the lower (756-entry already removes 750/751 — the same mechanic generalises).
2. A buyer exits everything, everywhere, at once — goal-stops on every arc + the fails-safe paid-check on every non-AC send. No exceptions, no new lane without it.
3. No deadline claims until D2 enforcement ships (Aga ruled the window binding, the code does not enforce it yet) — Stage 2 sells on the plan, the guarantee and the price, not a countdown.
4. One offer per email · ladder descends only post-refusal ($97 → quarterly → the evergreen's $78.50 event → win-back's reason-gated SAVE30). The free app is not on the ladder — it is the product, given at Stage 0 by design (Aga's reframe, 7 Aug).
5. Locked facts as everywhere: 4.8★ never 4.9 · under $2/week · the exact accelerator line · 60-day guarantee · no Liquid, AC merge tags only · no fabricated imagery.
6. The journey's exits are designed, not accidental: Stage 3 unconverted → nurture with the D13 survey's six utm_content reasons segmenting the hand-off; nurture → 991 re-engagement; nobody ever "completes into silence" again.

5 · WHAT CHANGES FOR EACH EXISTING ASSET

5.1 · 750 TMA | Welcome Sequence After Quiz — restructured, not rewritten (J5, J6)

Its front (E1/E2 burst) is replaced by Stage 0+1; its content/story emails become the body that runs alongside Stage 1–2 at a legal cadence; the unsub-outlier slot (1.14%, campaign 3715 — already ruled out by Aga on 4 Aug, never executed) is the EVOLUTION LAW's worst-eligible-slot and gets the first single-slot fix; its terminal enter-block points at the Stage 3 entry, not 751 directly.

🔴 [RESOLVED 10 Aug 2026 — the three asks were REMOVED under Aga's no-offer-in-welcome ruling; W7 now carries the doctrine's soft trial ask instead. See the status banner at top.] 🔴 And its three /50promo asks (E5/E7/E8) must move or change price. As-is they offer 50% off from ~day 10 — undercutting the $97 Stage-2 pitch (why pay $97 on day 2 if day 10 brings $78.50?) and pre-empting the evergreen event (the same offer with no event mechanics). Under J4's two-price rule they either become the Stage-2 $97 ask (single-slot swaps) or they retire and the 50% ask lives only in the Stage-3 event. This is the price-integrity fix that makes J4 real, and it was invisible until the census — the strategy's clean staging cannot coexist with a permanent 50%-off ask buried in the welcome.

5.2 · 760 School of Strength (NEW) — superseded as the bridge (J3)

It sells the same offer as the evergreen arc on a second clock — the exact collision 00g exists to prevent. AGA-113's one-field repoint should not be executed as written. Aga's options: retire 760, or keep it exclusively for the LEGACY pool (contacts who predate this journey and will never enter it). The doc recommends retire — one sales engine, one clock. (If Aga keeps it for the legacy pool: its E1 "Marcus could deadlift 435 lbs" collides with 750 E5's different Marcus ~10 days apart — the single-slot rename is mandatory before both run to anyone.)

5.3 · The evergreen arc — gets its entrance (J3) and three finishing tasks

Enter at the journey exit (~day 8–10 unconverted). Before arming: the preferences page (the opt-out is a mailto: today and every candidate URL 404s — one page + one AC automation + tag promo-opt-out in every promo exclusion set) · the 760 decision · Aga's shells/upload per its DEPLOY_SPEC.

5.4 · The abandonment estate — unchanged, better fed

Stage 4 as designed; the arrival email raises checkout-reacher quality; recovery E1's "mirror their plan" now lands on people who may have done a workout — the copywriter seat gets that context via field 78 in the enrichment.

5.5 · SendGrid transactional — from 4 sends to 2

Arrival (merged) + password reset. The verify email dies (J1); [Chosen Password] dies with the merge. Every remaining transactional send is measured by sendgrid_transactional_check.py.

5.5b · 🔴 J1 AS AGA SIMPLIFIED IT — one trigger change, and a collision dissolves

Her instruction, 7 Aug eve: "Nic is already sending the 'Your login' email to a checkout abandoner — why not just send this email with password generated to EVERYONE who finished the results, and that's it. The rest we can take care of from the ActiveCampaign side."

Her shape is right and it is better than the merge I proposed — take an email that already exists and works, and point it at everyone. Two of my three objections do fall away. The third does not, and I got it wrong twice before getting it right.

🔴 RETRACTION — read this before quoting anything about %QUIZPASSWORD%. At 21:10 I wrote that this was verified and the credential was already plumbed. It is not. Measured against the live ActiveCampaign API twenty minutes later: 54 custom fields exist and not one is a password. %QUIZPASSWORD% resolves to nothing.

How the error was made, because the mechanism is reusable: the file I read (…/TMA_QUIZ_CHECKOUT_BUILD_PACK_2026-07-29/04_EMAIL_FREE_WORKOUTS.html) is a BUILD PACK — a spec for an AC email that was to be built, in AC merge syntax. Nic's live "Your login is in this email" is a Django/SendGrid send. I bridged the two on content similarity — both carry free workouts and a login — and credited the live email with the spec's variable. Two estates, one plausible-looking bridge. This is the estate's own a label is not the thing rule.

What IS verified, from code (apps/quiz/serializers.py:71): python password = self.validated_data.get('password', settings.SECRET_KEY) Three outcomes, no fourth — the user typed one → real password · the key is blank → line 81's if created and password: is falsy, set_password never fires, the account has an unusable password · the key is absent → the password becomes settings.SECRET_KEY. ⇒ There is no password generation anywhere in the funnel, so "with password generated" describes something that does not exist yet. (The SECRET_KEY branch is worth flagging to Nic on its own merits, separately from this journey work.)

⚠️ And the tag lies: add_tag_to_contact(email, 'QuizPasswordProvided') fires at line 67, unconditionally, before the password is ever read. Never read it as evidence a password exists.

🔑 The estate already knew, and said so in writing. marketing/email-sequences/sendgrid-transactional-snapshot/MANIFEST.json records TX3's source as "tma-paywall-spec.netlify.app/email (Aga's spec) — sender postdates our clone" — i.e. an earlier session had already established that this artefact is the spec, not the live sender. That same snapshot's annotation flags the deeper problem: the spec's own build note says "B6 (quiz password logs into the app) must be verified before the first send" — and no B6 pass is recorded anywhere in the estate. So even where the variable appears, whether the password actually logs anyone in was never verified. ⇒ I did not just misread a file; I contradicted a finding already written down. Check-before-you-ask applies to our own records, not only to Aga's.

Whether the live email can state a working credential is therefore [NOT KNOWABLE] from here — the sender postdates our 2 Apr Django clone, and SendGrid delivers only, so it holds no bodies. ⇒ Ask Nic for a one-tap login LINK, which is the right shape regardless: it is the industry-standard mechanism, it needs no B6-style verification of a password nobody chose, and it sidesteps mailing a plaintext credential entirely.

And the part worth noticing: it dissolves the collision that has been shaping our whole arc. Results-completion happens before the checkout, so everyone who reaches the checkout has already received this email. The ~1h post-checkout trigger therefore becomes redundant, and should be removed — one email, one trigger, no duplicate.

⇒ The T+1h Django send that our abandonment lane was holding 24 hours to avoid stops existing at T+1h. quiz_abandon_sync.py's --hours 24 floor was there only for that collision, so once this ships E1 can return to ≤60min — the timing the arc was designed for, and the timing §5.2b flags as the one that makes E3's window beat coherent again. D1's whole problem also disappears: the free app now arrives before the price rather than an hour after it was declined.

The ask to Nic — one trigger change and one question:

1. Fire "Your login is in this email" on quiz/results completion for everyone, instead of ~1 hour after an abandoned checkout — and drop the [Chosen Password] line from the results email.
2. Can that email hand the person a one-tap login link? If not, what is the cheapest way for a brand-new quiz finisher to get into the app without typing a password they never chose?

Question 2 is the whole open item. Everything else about J1 is settled: the trigger, the audience, and the collision that dissolves. Until it is answered, no email may promise a password or state login credentials — the results email has been shipping a literal [Chosen Password] to every quiz finisher, and repeating that failure in a bigger audience is the one way this change makes things worse rather than better.

5.5c · 🔴 THE DECIDED T+0 STATE — Aga's ruling, 7 Aug eve, and the message to Nic

Aga ruled the SendGrid layer. After the change a quiz finisher gets TWO emails at T+0, not five — and the T+1h abandon send goes away with them, because email 2 has already done its job:

The trigger she picked is EARLIER than the one I had drafted. Not results-completion — the moment the person gives their email, which is the same post_save on Quiz that fires #3 today. Measured consequence, from the tag census: that reaches 16, not the 10 who see results — it deliberately includes the ~6-of-16 who finish the questions and never view their results, who today end up with an account and no way into it. That is the right call and it is a bigger expansion than mine.

🔑 It is ONE template swap, not "move a trigger + stop an email"

signals.py:14 → send_post_quiz_email_for() → mail.py:47 renders quiz_email.html. Point that one call at the new template and both halves happen at once — the old email stops because it is the thing being replaced, on a trigger that is already correct. Then the ~1h checkout trigger is removed separately. Simpler than the two-step the brief describes.

🔴 …and the swap exposes the credential gap rather than solving it

send_post_quiz_email_for(email, first_name) receives no password. The new template wants one. So the swap forces the very plumbing that was in question — and this is now the only thing between this plan and shipping. 🔴 The failure mode scales with the audience: the spec has never sent (SendGrid, 2 days: 22 × "Your login is in this email", 0 × "Try the app on us"), so %QUIZPASSWORD% has never been observed rendering, and the spec's own build gate — "B6: quiz password logs into the app must be verified before the first send" — has no recorded pass. If it resolves to nothing, every quiz finisher receives a raw %QUIZPASSWORD% string instead of 22 checkout-reachers receiving it. ⇒ Ask for a one-tap login LINK, which needs no password, no B6, and cannot render as a broken token.

⚠️ Two defects to fold into the message before it goes

1. The number 3 appears FOUR times, not three. The brief names "We want to give you the first 3 workouts", "Free to download · your first 3 workouts included · no card", and the P.S. "The 3 free sessions don't expire" — but there is a fourth in the app-store link block, also "your first 3 workouts included". Change three of four and a stale number ships next to the corrected ones.
2. 🔴 The accelerator wording on the live spec page is wrong and is a claims defect. It reads "Lead Sports Accelerator — led by Adidas and ex-Red Bull executives." Canon is "the LEAD Sports Tech Accelerator — run by the Adidas family and ex-Red Bull executives." Adidas does not lead it. This ships to everyone once the audience expands. ✅ Good news alongside it: the 4.9★ defect is already fixed — the page now reads 4.8★, so that one needs no instruction.

Still open and only Aga's: [N]. The copy cannot ship with a placeholder, and the number of free workouts is a product decision, not a copy one.

5.5d · 🔴 AGA'S CATCH, 10 Aug — the new design deleted the ONLY abandonment email we send

She asked: "so just for the record, in this new one we don't send an abandonment email at all? So far the ideal was that if someone started the checkout we immediately send them the email to recover. What is the industry standard?"

She is right and §5.5c was wrong. Verified live 10 Aug:

So the red box saying "recovery owns days 0–3 (the abandonment arc)" describes an arc that has never fired, while §5.5c struck out the T+1h send — the one email that actually reaches these people. Net effect as drawn: a checkout abandoner would receive nothing. Corrected in the diagram: the T+1h slot is KEPT, and the checkout branch now says on its face that 756/757 have never sent.

🔴 …and she meant the hello@ 1:1 lane, not the AC arc. It is not sending either.

Clarified by Aga: "I am talking about the email jobs that are personalised and going out straight from our Gmail, at hello@." That is quiz_abandon_manual_notes.py — the lane behind the 39 notes. Verified live 10 Aug:

⇒ The machine finds abandoners every half hour and then does nothing with them.

🔴 And the window was mine, not the machine's. I moved --hours from 1 → 24 on 7 Aug to dodge the Django T+1h collision. That reasoning was right then and is retired now — the 1h slot is being repurposed, not duplicated, so there is nothing to collide with. Restored to --hours 1, which also lands on the 30–60 min benchmark. The obsolete rationale is preserved in the docstring so nobody re-derives it, with the condition that would justify bringing 24 back.

With 1h restored, the lane immediately sees 91 abandoners · $8,827 at stake · checkout conversion 18.3%. ⚠️ That $8,827 is GROSS AT STAKE, not recoverable revenue — good-performer recovery runs 10–14%, and RevenueCat 2026 finds ~20% of lapsed users reactivate with zero intervention, which is exactly why the 1-in-5 holdout is armed. Treat the honest prize as a fraction of it, measured against the holdout, never as the headline.

🔴 THE DECISION THAT IS AGA'S: does this lane auto-send, or stay manual?

The 39 notes went on her explicit GO. Arming continuous auto-send of personalised 1:1 notes from hello@ to members is a send decision, and it is hers — it is one command, and I will not run it unasked. The two shapes:

Recommendation: arm it, once the recovery copy asks for the sale. The lane's own collision gate (abandon_collision_gate.py) already reads all three sending systems plus live Stripe buyer-safety before each send, so the guardrail for auto-send exists. What is missing is not safety — it is that the current note still inherits the free-access angle rather than the ask (§5.5d).

The industry standard, and where we already sit

First recovery email at 30–60 minutes is the 2026 benchmark; under ~15 minutes reads as too reactive — the person may still be on the page or retrying a card. Then email 2 at ~18h, email 3 just over a day. 🔑 Nic's existing ~1h trigger is already AT the benchmark — the timing was never the problem.

🔴 And checkout abandonment is the higher-intent event, distinct from cart abandonment: the person had begun paying and hit an obstacle, so it responds to structural fixes and a direct ask, where cart abandonment responds to information and price framing.

⚠️ The TMA-specific caveat that weakens "send instantly": our trigger is "landed on the checkout with an email already on it" — and the quiz PREFILLS that email, so the person never typed it. That makes our signal closer to a page view than to a real checkout start, and a slice of the audience is simply seeing the price for the first time. Which argues for 60 minutes, not 5.

⇒ The fix: two emails, two jobs. Keep both.

That is the actual prize here, and it has been hiding in plain sight: today an abandoner receives a free-access email and is never asked to buy, while the arc that would ask has never run. The timing was right all along; the content was doing the wrong job. So the instruction to Nic is "repoint email 2 to email-capture and leave the 1h slot in place" — not "remove the 1h trigger."

✅ The collision worry also resolves cleanly: the two now fire at different moments (T+0 capture vs T+1h post-checkout) with different content and different asks, so there is nothing to double-send. Personalisation for the recovery slot is already built — the Tier A engine behind the 39 notes.

5.6 · Nurture/re-engagement — receives designed exits

751/758 keep their role for the long pool but stop being the default destination for a 3-day-old hot lead; 758's zero-offer problem and the 973 migration stay owned by the email fleet's existing rows — this doc only fixes who arrives there and when.

6 · MEASUREMENT — activation first, money second, honesty always

The holdout philosophy generalises: any claim that a journey change "lifted conversion" needs either a control cohort or the honesty tag [UPPER BOUND]. Pre/post comparisons across the switch are inadmissible without noting the funnel discontinuity (promo calendar law).

7 · BUILD PLAN — phased, owned, nothing big-bang

Phase A — no approvals beyond this doc (fleet, this week): 1. The Stage-2 pitch + Stage-1 nudges written through /email-fleet gates against the engine's fields (extends FLEET-42/FLEET-44 — same renderer, new slots). 2. The preferences page + promo-opt-out automation spec (unblocks the evergreen arc's opt-out). 3. The activation census baseline: what % of the last 90 days' quiz leads ever reached no_trial? (One run of the funnel-stage census, filtered to quiz cohort — the number J2's success will be judged against.)

Phase B — Aga (~1h, after ruling J1–J6): 4. 🔴 FIRST, the five-minute builder check: does 750's If customer — END goal actually exist and fire? The estate's two sources contradict (Aug citations vs the June audit's exit_on_conversion=0), goals are API-invisible, and everything in this journey assumes buyers exit. If it is missing, that is the most urgent fix in the whole document. 5. Approve J1 for Nic's brief (the merged arrival email + verify kill, ~1h of his time). 6. The evergreen shells + upload per DEPLOY_SPEC, with its entry per J3. 7. The 760 ruling (J3) — retire or legacy-only. AGA-113 updated accordingly, not executed as written. 8. 750's single-slot fixes approved one at a time (J5) — starting with the two she ALREADY ruled on 4 Aug (pull 3715; fix the E1→E2 five-minute gap).

Phase C — Nic (~2h total, sequenced behind his current queue): 9. The merged arrival email (one Django template replaces two, kills verify) — J1, which also closes the verify→992 double-welcome at its root (the tag routing row covers the interim). 10. (Already deferred by Aga: the 48h enforcement, AGA-132.) 11. Optional, later: the Intercom workout webhook for same-hour triggering (§3c) — only if the nightly grain proves too slow in the data.

Explicitly sequenced LAST: nothing in Phase A blocks on B or C. The pitch can ship against the nightly signal and current arrival emails — each later phase upgrades the journey without rebuilding it.

8 · SOURCES

Estate: the abandonment master + engine + ladder + ops manual (7 Aug) · LEAD_SIGNAL_CONTRACT §8 · REVIEW.html + build_review_page.py (the 3-layer render + the AC-order trap) · the evergreen DEPLOY_SPEC.md/CHANGE_LOG.md · EMAIL_REVENUE_STRATEGY_2026-08-05.md (the two-engine model this journey implements at lead level) · BROADCAST_CADENCE_AND_COLLISION_DOCTRINE · the SendGrid census · the AC field censuses (7 Aug). External (2026): behaviour-triggered onboarding +22% vs time-drips; activation-first trial doctrine (activated users convert 5–10×); 3–4 segmentation tracks max; opt-out-style trials ~31% vs freemium ~2.6% — Mailgenius onboarding guide · Digitalapplied SaaS onboarding playbook · Custom.one quiz funnel guide · Sequenzy trial-email benchmarks · involve.me assessment-quiz churn study.

THE WELCOME SEQUENCES — what runs, why, and how it works

The map of every welcome email TMA sends, and the reasoning underneath it. Written 12 Aug 2026 so that anyone — Aga, Nic, a future session — can see the whole estate at once instead of reconstructing it from four documents. The law it implements: WELCOME_CTA_DOCTRINE_2026-08-10.md (ratified by Aga, amended §7). Every number here was measured live, not taken from a doc.

1 · THE ONE IDEA: three doors, one system

Three different kinds of person arrive at TMA, and each gets their own welcome arc. Until 11 Aug they pulled in three different directions. They now all point at the same thing.

The idea in one sentence: nobody can train well until they have been measured, so every door leads to the measurement, and the ask for money comes only after they have felt the product.

There is a fourth arc, 988 TMA | Welcome Sequence AFTER APPSIGNUP, which is the app-signup arc's predecessor. It is retired as an entry — nobody new joins — but ~162 people are still finishing it, so on 12 Aug its door was repaired too, and it now says the same thing as its successor.

2 · WHY MEASUREMENT IS THE DOOR (the thing most people get wrong)

🔴 A free app signup has never been measured. Aga's own correction, 11 Aug: they answer a few setup questions, land on a home screen showing an example workout built for somebody who has already done the fundamentals, and the app asks them to upgrade to get the assessment.

So in-app measurement is behind the paywall. The web quiz is the free measurement door.

That single fact decides most of the estate:

• It is why the app-signup arc points at the quiz and not at the app.
• It is why, before 11 Aug, that arc was doing real damage: it told people "you need to be measured" and then sent them to pay to be measured — re-presenting the exact paywall they had just walked away from. One slot was unsubscribing at 8.77% against a 0.5% ceiling.
• It is why the lead-magnet arc points at the quiz too: a PDF about the planche cannot know whether this reader's shoulders are ready for step 4 or step 11.

3 · WHAT EACH ARC ACTUALLY SAYS

750 TMA | Welcome Sequence After Quiz — 8 slots

They are measured; the plan exists. Every email's job is to get them into the app and through workout 1. W1 the plan wasn't built for you · W2 what your quiz said · W3–W4 have you trained yet · W5 Jesse's origin story · W6 Gareth's proof · W7 the arc's one soft trial ask · W8 the final story. No offer, ever (Aga, 10 Aug) — the discount belongs to 993 SALES SEQUENCE.

967 TMA | Welcome Sequence After LEAD MAGNET — 8 slots

🔑 Who they really are was measured, not assumed: sampling the arc's own contacts shows they downloaded skill guides — planche 6, handstand 3 of 30 sampled. So the argument is: the guide gave you the steps; the quiz tells you which step you're standing on. Because the arc serves many different guides, the copy may never name one skill — naming the planche to a handstand downloader is a lie the reader will notice.

992 TMA | Welcome Sequence AFTER APPSIGNUP AB TEST Aug4th — 8 slots

The copy was already right; only its door was wrong. "The app knows your name and whatever you tapped during setup. It has never seen you move… you'll have seen the example plan when you set it up. That was a demonstration of the shape, built for nobody in particular." Every button now goes to the free quiz; E8 keeps the arc's single soft trial ask.

4 · THE WORKOUT-1 MOMENT — the piece being built now

The highest-intent moment in the whole funnel is the morning after someone completes their first workout, and today it carries no email at all. About 48 people a day reach it.

Why it matters: someone who trained yesterday has felt the product. The ask stops being "buy something" and becomes "keep doing what you did yesterday" — an appeal to consistency rather than to belief.

How it works, end to end:

1. They train (evening). The app tells Intercom within minutes — verified live, not nightly.
2. 03:15 — a nightly job (com.tma.workout1) reads every 90-day-active contact's workout count out of Intercom, compares it against last night's snapshot, and finds everyone who went 0 → 1.
3. Payers are excluded four ways — Intercom's plan field, live Stripe subscriptions on both accounts, the ever-paid set (lifetime is a one-time charge a subscription check cannot see), and the segment gate before any send.
4. Those people get two labels in ActiveCampaign: workout1-yesterday (the trigger) and workout1-done (permanent).
5. 08:00 — an automation triggered by that label sends one email: session 1 is a nervous-system event, not a muscle one; soreness tracks unfamiliarity, not effectiveness; two free sessions left; and the 7-day trial with its honest mechanics.

🔑 The label is the bridge — ActiveCampaign never has to see the app. That is what makes this a six-click build instead of an integration project.

Three safety rules built into the job: - The first run can only seed, never tag. With no previous snapshot every existing member looks like a first-timer, and the entire back catalogue would receive "you did your first workout yesterday". That is missing data, not an overridable setting. - It refuses outright above 400 people in a day — that means a stale snapshot or a data backfill, not 400 first workouts. - The snapshot only advances after a successful pass, so a crash re-runs the same day rather than losing the cohort.

5 · WHAT HAPPENS WHEN SOMEONE TRAINS — and why only ONE arc ends

This is the subtle part, and the first version of the plan got it wrong.

The rule this gives us, for any future behaviour trigger: before ending an arc on a behaviour, ask whether the arc's argument survives that behaviour — not merely whether the behaviour happened. An activation arc dies at activation. A measurement arc does not.

6 · THE RULES THAT BIND EVERY WELCOME EMAIL

1. 🔴 No offer. Ever. No discount, no percentage, no deadline, no sale. The offer lives only in 993 SALES SEQUENCE, which receives the reader afterwards — so the discount lands as an escalation on someone warm, not as an unexplained coupon on someone cold. (Aga, 10 Aug.)
2. The trial is asked for exactly twice: the morning after workout 1, and once at the end of an arc for people who ignored every free invitation. Never twice in a row.
3. Trial language only against a trial checkout. The 50off/ family charges immediately — trial copy against it is a shipped lie. Every URL comes from the v3 checkout map.
4. Content links use the quiz root, never a frozen variant path.
5. A subject or preview may never promise what the body cannot deliver.
6. Every claim must be true of the artifact — if the copy says free, the page must be free.

7 · WHAT IS DONE, AND WHAT IS LEFT

Done (10–12 Aug), all live-verified: - 967 — 30 stale quiz links repointed; both ghost emails (old quiz-audience copy telling a non-quiz reader "remember your movement diagnosis") replaced; a hidden offer link removed; 13 of 15 emails moved off a grey canvas; 15 of 15 given a first-name fallback that no longer renders as an empty string; 30 untagged links given attribution; E1 rewritten. - 992 — every checkout link (2–3 per email) replaced with the free quiz, 45 quiz links now present, per-slot buttons, and an honesty fix where the copy had claimed all calibration sits behind the trial. - 988 — the retired twin, still sending to 162 people, repaired the same way (42 → 0 paywall links) plus 8 sentences that described card mechanics and became false under a free button. - The workout-1 job — built, seeded with 15,410 contacts, registered, health-checked.

Left: - One builder visit (AGA-161) — create the automation, end 750 on workout1-done, and add the promo-opt-out exclusion to 993. Everything else is fleet work. - 🔴 The gap after activation. They exit 750, receive one morning-after email, and then nothing — 993 SALES SEQUENCE exists but nothing routes an activated person into it. That handoff is the next real build. It blocks nothing today (one email at the highest-intent moment beats the current silence), but it is why the numbers may look thin before it exists. - Fleet backlog: preview lines that contradict their own emails (FLEET-59, FLEET-64), a non-canonical footer on five variants (FLEET-61), campaign-tag inconsistency (FLEET-65).

8 · HOW ANY OF THIS GETS CHANGED

Never by hand in the builder, and never by editing a live email directly. The route is:

Read the doctrine → the fleet writes the copy → email_lint.py → email-qa → a script with byte-exact targets that refuses to guess → backup every message → write plaintext from the final HTML in the same call → read back → tma-ac-upload-integrity (blocking) → verify independently.

Two laws that came out of doing it wrong: a read-back must assert what the plan promised, not merely that the bytes came back, and two rules editing the same region must not be able to match each other's output. Both were learned from real defects, on live emails, this week.

🚀 THE PERSONALISATION ENGINE LEAVES THE ABANDONMENT LANE — welcome sequence first

⭐🔴 CANONICAL design + build plan for extrapolating the abandonment personalisation engine to the whole email estate, starting with the welcome sequence. Written 7 Aug 2026 on Aga's directive: "take this personalisation engine and extrapolate it for the email sequence, starting with the welcome sequence … very strong fallback … works for people we have data for and for the old people that we don't."

The engine being extrapolated: tools/retention/quiz_abandon_manual_notes.py (code = canon) documented in ABANDONMENT_PERSONALISATION_ENGINE_2026-08-07.md. Data law: LEAD_SIGNAL_CONTRACT_2026-08-06.md §8 + AUDIENCE_DATA_DICTIONARY_2026-08-07.md. Missing-data law (abandonment estate): ABANDONMENT_DATA_FALLBACK_LADDER_2026-08-07.md — §5 of THIS doc is the welcome/LEAD-tier ladder that file says "has not been written yet." Every number below is tagged [LIVE date + instrument] / [MODELLED] / [UNVERIFIED]. Nothing in §7 executes on a live automation without Aga's approval (§0 decisions). Shareable: https://claude.ai/code/artifact/9bd17095-a7ac-4cca-be28-c5a5340d690a

0 · THE VERDICT — one paragraph, then Aga's decisions

The engine extrapolates cleanly because it was built for this. Its renderer (assemble()) is surface-agnostic, its adapters are swappable, and its own doc (§5) already defines the three extension moves: add a SLOT, add a SURFACE, add an AUDIENCE. The welcome sequence is a new AUDIENCE (quiz leads, not decliners) on a new SURFACE (an ActiveCampaign automation, not Gmail 1:1). What is genuinely missing is four things: (1) the AC field-delivery adapter (designed, unbuilt — FLEET-44), (2) a welcome copy pack with a LEAD-tier + zero-data fallback ladder (§5 — the ladder the abandonment estate names as unwritten), (3) an enrol-writer job that renders each person's sentences into AC custom fields before the automation reads them, and (4) five wiring points in /email-fleet so personalisation is enforced by gates, not stated in briefings (§6 — today the law is carried by 29 seats and enforced by zero pipeline checks). And the welcome sequence is the right first target on the merits: 750 TMA | Welcome Sequence After Quiz is Tier A (17,076 sends/28d), OVER-HARDSTOP on unsub (0.60% arc) [LIVE 7 Aug scoreboard], runs one generic track to all 7 paths, its first ask is a 50%-off at email 6 (contradicting its own SPEC-WELCOME doctrine), and two of Aga's own 4 Aug rulings against it are still unexecuted (§2).

The decisions only Aga can make (everything else in §7 is fleet work)

1 · WHAT IS BEING EXTRAPOLATED — and the split that makes it portable

The engine (ABANDONMENT_PERSONALISATION_ENGINE_2026-08-07.md, code canon tools/retention/quiz_abandon_manual_notes.py) is three separable layers:

The build therefore starts with a refactor, not a rewrite: lift the renderer machinery into tools/retention/personalisation_core.py; quiz_abandon_manual_notes.py imports it and keeps behaving identically (its --example/--verify/manifest contract unchanged — the abandonment lane must not notice); the welcome pack becomes the second consumer. The engine doc's "code is canon" pointer gains one line naming the core module.

The one constraint that shapes everything (engine §3, verified 0/539 live bodies): ActiveCampaign cannot branch inside an email body. An unset field renders as an EMPTY STRING, not a skipped sentence. So all welcome personalisation is pre-rendered into custom fields by our code; each email carries one bare merge tag per slot. AC can branch at the automation level (if/else on tags, goals — the "If customer - END" goal on 750 TMA | Welcome Sequence After Quiz is the live proof), which is where stage-routing lives (§4).

2 · THE WELCOME ESTATE AS IT ACTUALLY IS — measured, with what's broken

The lead welcome for quiz leads is 750 TMA | Welcome Sequence After Quiz (registry: ACTIVE, 19,535 entered as of 27 Jul; 19,798 by the 7 Aug live snapshot). Its sibling 967 TMA | Welcome Sequence After LEAD MAGNET (Tier B) serves lead-magnet leads. Buyer-side (975 Onboarding | After The Purchase, 992 TMA | Welcome Sequence AFTER APPSIGNUP AB TEST Aug4th) is out of scope here.

The facts that justify a REPLACEMENT rather than a slot change:

• Arc health OVER-HARDSTOP [LIVE 7 Aug — data/email-analytics/scoreboard/LATEST.md]: 17,076 sends/28d · CTR 0.66% · unsub 0.60% vs the 0.50% §D hard-stop. Worst slot: campaign 3715 ("The systematic approach to unbreakable strength") — 769 sends, 2.86% unsub, flagged STRUCTURAL.
• One generic track to all 7 paths — 13 Jul audit: "no evidence of PATH branching in the spine"; only %FIRSTNAME% merge tags in 3 of 10 slots. The 28-directory path×tier arc library built 25 Apr was never deployed.
• The ask contradicts the spec — SPEC-WELCOME: free-trial CTA only, /start-training/; live: zero /start-training/ links, first ask = 50%-off at email 6 of 10 [EMAIL_OFFER_LAYER_FORENSICS_2026-08-05.md §2.1].
• E1 open ~18–20% vs a 45–65% norm — 15 Jul CMO analysis: deliverability + trigger timing are lever #1; copy is lever #2.
• Aga's two 4 Aug rulings — pull 3715 from E1; start the arc day 3–4 — are UNEXECUTED [verified 7 Aug: no queue row, no FLEET_LOG entry, slot still sending]. → W-D5, W-D2.
• Collision at T+0: entry fires on the list-209 subscribe, into the same hour as the two Django sends ("results are ready" + "verify") — 3–4 emails in the first hour, 5 for a checkout-opener (Nic's T+1h login email). E1-position campaign 3715 unsubs 3.6× its sibling at identical engagement (z≈7.6) — "a placement problem, not a copy problem" [QUIZ_FUNNEL_EMAIL_MASTER_2026-08-04.html Failure 4].
• [UNVERIFIED — builder-only]: true slot order (the API cannot express it; three blocks share ordernum 1) and the second entry trigger. Both must be read from the AC builder during Phase 5 — never asserted from the API.

Volume for design + power maths: entrants ≈ 140–200/wk [WEEKLY_2026-08-03: 141/wk; day-one tag census 7 Aug: 8 by midday]. New-lead flow carries LEAD-tier data at minimum from 7 Aug (§3).

3 · THE DATA CONTRACT, PER STAGE — what exists for whom (the whole fallback question)

Verified live 7 Aug (python3 tools/retention/quiz_lead_signal_check.py --sample 2 — HEALTHY, tag total at baseline, real contacts carrying both tiers):

Three laws travel with every placement (contract §8a): stage-gating (RESULTS-tier tags only to the results-seen cohort), the empty-string render (never a merge tag as the subject of a sentence), TAG = state / FIELD = data (segment on the 15 NEW quiz-* tags only; the 5,623 legacy tags are never a segment).

4 · THE TARGET ARCHITECTURE

4a · One automation, stage-branched at the automation level

New automation (fleet-built shells, Aga arms the trigger — see Phase 5): TMA | Welcome After Quiz — PERSONALISED (2026-08). Entry: the same list-209 subscribe that feeds 750 TMA | Welcome Sequence After Quiz today.

ENTER (list 209 subscribe)
  ├─ exclusions: is-customer → exit to 975 Onboarding | After The Purchase
  │              in 992 TMA | Welcome Sequence AFTER APPSIGNUP AB TEST Aug4th → do not enter
  ├─ WAIT ~2h        ← lets NIC-54 fields + the enrol-writer land; clears the T+0 Django pair
  ├─ IF tag NEW quiz-reached-checkout
  │     → WAIT until day 3–4 (the offer window + abandonment estate own this person)
  │     → re-check is-customer → join spine with checkout-aware slot copy
  ├─ ELIF tag NEW quiz-results-seen  → Path R: E1 mirrors their results
  └─ ELSE (gave-email only)          → Path L: E1 = "see the results you built"
SPINE (SPEC-WELCOME doctrine, 5 emails / ~7 days — not 10/23):
  E1 identity + stage-aware hook · E2 origin story · E3 mechanism (obstacle-personalised)
  · E4 proof (engine-matched member quote) · E5 soft ask (W-D3)
EXIT GOALS: buys → exit to 975 Onboarding | After The Purchase (already-proven mechanism)
            trial starts → exit (SPEC-WELCOME rule) · end → enter 751 Nurture Sequence 1

The branching is automation-level if/else on tags — the thing AC provably does. The personalisation inside each email is pre-rendered fields — the thing AC provably renders. Nothing in the design asks AC to do anything unverified.

4b · The slots — new fields, never shared with the abandonment arc

~7 welcome-owned custom fields, minted at Phase 0 (titles → perstags): TMA_WELCOME_HOOK_LINE · TMA_WELCOME_GOAL_LINE · TMA_WELCOME_OBSTACLE_LINE · TMA_WELCOME_JLY_LINE · TMA_WELCOME_PROOF_INTRO · TMA_WELCOME_PROOF_QUOTE · TMA_WELCOME_NEXT_STEP (the stage CTA line).

🔴 Why not reuse the abandonment adapter's planned fields (72–74): the same person can be in both estates in the same week (reached-checkout → abandonment arc → welcome spine at day 3–4). Shared fields + the SLOTS-FREEZE-AT-ENROL law = one arc silently rewriting the other's sentences mid-flight. Separate field sets per audience is dumber and safer. The freeze law then applies per audience: the welcome writer refuses to touch a contact already in the welcome arc (readable via the contactAutomations endpoint — the same read that exposed the 992 cross-enrol defect); re-render is allowed only at arc boundaries (welcome → nurture).

🔴 Field capacity is a PROOF, not an assumption (engine §4 / FLEET-44 step one): all 54 existing fields are type: text, ZERO textarea in the account, our sentences run 100–200 chars. Write ONE full sentence to ONE test contact, read it back, confirm no truncation. If it truncates → mint as textarea. Only then mint the seven.

4c · The enrol-writer — tools/retention/welcome_personalise.py

The welcome twin of the abandonment lane, built on the proven funnel_stage_export.py pattern (PUT fieldValues at 11,500 contacts · ~4–5 req/s · retry 429/5xx · abort >200 errors · clear-stale · read-back verify):

1. Every 15 min (launchd, registered in AUTOMATION_JOB_REGISTER.md + cockpit watchdog): pull contacts new on list 209 / the NEW quiz-* tags since last run.
2. Read the §8 profile by stable field id — never by name.
3. assemble_welcome(persona, prof, stage) → one rendered sentence per slot, by the §5 ladder.
4. ONE PUT per contact, every slot always written — a slot with no data gets its floor sentence, never a blank (adapter law 1).
5. Manifest row per person (welcome_personalise_manifest.json): stage, tier, fields present, rung chosen per slot, quote id, decision — the same auditability contract as the abandonment manifest.
6. Freeze check before any rewrite (4b). Read back a live sample per run (adapter law 3).

The timing race and its three nets: the automation's ~2h entry wait vs the 15-min job cadence means every entrant has fields before E1 renders (net 1). If the job ever dies, slots render EMPTY — so every slot is placed as a standalone paragraph, never mid-sentence (net 2: a missing paragraph degrades the email; a broken sentence discredits it), and the E1 send is the render-with-everything-empty test made permanent (adapter law 4). Net 3 is a hypothesis to test in Phase 0, not to assume: AC's pipe-default merge syntax (%FIRSTNAME|there% works on live 750 TMA | Welcome Sequence After Quiz slots today) may accept a full-sentence default on a custom field tag (%TMA_WELCOME_GOAL_LINE|<floor sentence>%). If a real test send proves it renders (punctuation and all), the floor lives in the email itself and an unwritten contact is indistinguishable from a floor-rung contact. Proven on the wire or not used.

4d · What the welcome copy pack may NOT do

Locked facts and laws travel unchanged: 4.8★ never 4.9 · "LEAD Sports Tech Accelerator — run by the Adidas family and ex-Red Bull executives" exactly · testimonials verbatim from marketing/TESTIMONIALS-DATABASE/ only (provenance-gated) · no invented urgency, no deadline claims the code doesn't enforce · enum values never render raw · stakes words are echoed, never quoted back (surveillance vs memory) · subjects never carry age/gender · %FIRSTNAME% never leads a subject (−4.3pp, n=10,843). All slot copy is written by Agent 07 inside /email-fleet — the engine stores it; it does not author it (the EMAIL RULE).

5 · THE WELCOME FALLBACK LADDER — the LEAD-tier/zero-data ladder, written

The abandonment ladder governs its own estate. This §5 is the ladder ABANDONMENT_DATA_FALLBACK_LADDER_2026-08-07.md §0a names as "a different, shallower ladder that has not been written yet." Same one law above it: a missing field DEGRADES the sentence gracefully. It never fabricates it. Every degradation is recorded in the manifest. Rung copy below describes the JOB of the sentence — the sentences themselves are Agent 07's, through the fleet.

Tier detection per person at render time, from which fields actually return values (never from a date): FULL = any RESULTS-tier field present · LEAD = persona and/or obstacle only · FLOOR = nothing.

Two rules the AC surface adds on top of the abandonment ladder: every floor is a real sentence (the empty-string law makes "omit" impossible), and every slot is a standalone paragraph (§4c net 2). A slot with no floor rung is not finished (engine §5).

6 · PERMANENCE — where the engine lives in the email fleet, enforced not stated

Today the personalisation law is stated in 29 seat briefings and enforced by zero pipeline artifacts. The wiring that fixes it (each item is a named gap found by the 7 Aug architecture sweep):

Ownership: tma-email-architect owns the engine's estate map (which audiences consume it, which fields belong to whom); email-variable-auditor is the correctness gate; tma-segment-integrity-officer + segment_guard.py remain the blocking audience gate for the enrol-writer's bulk writes (Step 1.4c already covers bulk AC writes — no new gate needed, it must simply be run).

The expansion path after welcome (each = new copy pack + stated tier, zero new machinery): 967 TMA | Welcome Sequence After LEAD MAGNET (zero-quiz-data audience — proves the floor), the nurture estate (751 Nurture Sequence 1 and siblings, LEAD-tier ladder), 976 Cancelled Win-Back (LEAD-tier + exit-survey reason), broadcasts (floor + engagement tier).

7 · BUILD PLAN

Estate corrections executed with this analysis (defects found during research): AUDIENCE_DATA_DICTIONARY_2026-08-07.md §2b still recommended AC "Conditional Content" — the instruction corrected as impossible everywhere else (missed by the 30-file sweep); fixed. DOCUMENT_MAP.md cited the pre-purge funnel-stage pool (4,356/6,775/2,809) as stamped %TMA_FUNNEL_STAGE% coverage — actual stamped: 3,276 / 5,872 / 1,909 (11,057 labelled, AUDIENCE_INTEGRITY_MASTER_2026-08-07.md); fixed.

Open questions this analysis leaves honestly open: the Django T+0 pair ("results are ready" with the literal [Chosen Password] + the verify email) stays Nic's lane — the master doc's sequencing note holds (fix the results email before moving the welcome start); whether 967 TMA | Welcome Sequence After LEAD MAGNET or the nurture estate goes second; CIO migration timing (the quiz-funnel build direction is Customer.io — this engine's pure-renderer split is exactly what makes that a new adapter, not a rewrite).

ABANDONMENT & WIN-BACK MASTER — every email, every dataset, and the plan

⭐ Strategy of record for the Abandonment Recovery Fleet (/abandon-fleet) — and, since the 7 Aug evening rewrite, THE master document for how TMA talks to the person who almost bought, on BOTH funnels, plus the win-back estate. Rewritten on Aga's directive the same day the three things that obsoleted the morning version landed: the SendGrid measurements (a read-only key now exists), Nic's NIC-90 answer (his abandon email's real trigger), and the full v3 + win-back sweep (3 exploration agents, every claim file-quoted). Fleet: tma-quiz-checkout-abandon-owner (chairs) · tma-abandonment-data-analyst · tma-abandonment-copywriter. Data law: LEAD_SIGNAL_CONTRACT_2026-08-06.md §8. 📖 OPERATIONS (how it runs, hour by hour, rules + enforcement points): ABANDONMENT_OPERATIONS_MANUAL_2026-08-07.md · 🪜 missing-data law: ABANDONMENT_DATA_FALLBACK_LADDER_2026-08-07.md — this file owns the WHY and the decisions; those two own the HOW. Every number is tagged [LIVE date] / [MODELLED] / [UNVERIFIED] with its re-run command. Nothing in §7 executes without Aga's approval of this document.

0a · 📚 THE DOCUMENT REGISTER — every sub-doc of this estate, from here (Aga's rule, 7 Aug)

Nothing about abandonment floats outside this register. Adding a doc, tool or seat to this estate = adding its row here in the same session.

0 · THE VERDICT — one paragraph, then the five decisions

TMA already sends an abandoner five to six emails in the first eighteen hours — from three systems that cannot see each other — and the one thing none of them does is ask for the sale. The paid recovery arc (756 Part 1 - Abandoned Cart Reminder / 757 Part 2 - Abandoned Cart Reminder) is the only piece of the machine that has never fired. Meanwhile the piece that fires most reliably — Nic's Django email — gives the product away free one hour after the person declined $97. The quiz funnel now stamps everything we need to personalise recovery properly (goal, obstacle, their own words for what they fear); the v3 funnel has effectively no abandoners to recover; and the win-back estate has a live mis-tagging risk and two contradictory canonical prices. The fix is not more emails. It is one recovery conversation per abandoner, sale-first, free-fallback last — built from parts that almost all already exist.

The five decisions only Aga can make (everything else in §7 is fleet work):

1 · EVERY EMAIL AN ABANDONER RECEIVES TODAY — the clocked map

1a · Quiz funnel ($97 checkout) — the first 18 hours, measured

A person finishes the quiz, sees their results, opens the $97 checkout, and does not pay. This is what actually reaches their inbox [LIVE 4–7 Aug 2026 — SendGrid census, tools/retention/sendgrid_transactional_check.py]:

Read that table again: five to six touches in ~18 hours, zero of which ask for the $97 sale, from three sending systems (Django/SendGrid · ActiveCampaign · Gmail) that cannot see each other. An AC collision check is incomplete by construction — Nic's send appears in no AC automation, trigger or calendar. [Nic, NIC-90, 7 Aug]

Nic's email, precisely (his own answer, 7 Aug — NIC-90 resolution): fires ~1h after someone opens the quiz checkout page with an email on it and does not buy. No password, no card needed. NOT on quiz start; NOT for an email typed earlier that never reached checkout. Held by a safety switch until 7 Aug — now fixed and sending. Body: free first 3 workouts + login credentials (repo copy: docs/company/PRICING/TMA_QUIZ_CHECKOUT_BUILD_PACK_2026-07-29/04_EMAIL_FREE_WORKOUTS.html — which carries 4.9★, a banned figure, and the wrong accelerator spelling; whether the live Django template matches the repo copy is [UNVERIFIED — SendGrid shows events, not bodies]).

1b · v3 checkouts (trial/ · 50off/ · normal/ · upgrade/ · 30trial/)

A v3 abandoner receives NOTHING, at any stage. — CHECKOUT_EMAIL_COVERAGE_AND_GAPS_2026-08-04.md §2.1, verbatim. There is no v3 abandonment sequence of any kind, and until this rewrite the strategy of record did not mention v3 at all.

What v3 does have: stamp-abandon-email + email-blur mint shipped 3 Aug (NIC-19 change 1, verified against the served JS), so a typed email now creates an identifiable Stripe record. And tools/retention/cart_abandon_reconcile.py — the hourly Stripe→AC bridge, hard-coded to v3 (tag 63598, field 56) — is written but has never run: no launchd job, no state file, absent from AUTOMATION_JOB_REGISTER.md. §3 has the audience numbers; they change the conclusion.

1c · Win-back (cancelled members) — for completeness of the map

2 · THE DATA WE NOW HOLD — four sources, what each answers, and its traps

Companion, written the same day by a parallel session: docs/company/ANALYTICS/AUDIENCE_DATA_DICTIONARY_2026-08-07.md — "everything we know about a contact when writing email", combining the quiz signals with the app funnel stage (the Intercom census in §3c). Read it alongside §8 of the contract; it answers "which journey is my reader on?" for a writer who has both datasets available.

What the quiz now tells us about a real abandoner — contact 378032, created 06:43 on 7 Aug [LIVE census]: goal SKILL_SEEKER · obstacle CONFUSION · age 18_24 · background GYM · weakest Abs · and in their own words: "Never unlocking the skills I know are possible." That sentence is the strongest copy asset this company owns, and until this morning it died at the end of the quiz. The rules for using it: echo, never quote; RESULTS-tier fields only to the results-seen cohort; every merge placement passes the empty-string test (§8 of the contract).

3 · THE TWO FUNNELS, MEASURED — and the honest prize

3a · Quiz funnel ($97) — works, leaks at a known rate

[LIVE 7 Aug — quiz_abandon_status.json 09:31]: 30-day window — 63 checkouts · 8 paid (12.7%) · 44 distinct abandoners · $4,268 attempted. Personas: FAT_BURNER 15 · MUSCLE_BUILDER 10 · SKILL_SEEKER 7 · STRENGTH_BUILDER 5 · JUST_START 3 · PAIN_FREE 2 · AGE_STRONG 1. Nearly all abandoned the $97 annual. 0 of 44 ever attached a card — these are price decliners, not cart abandoners; copy that says "you left something in your cart" is false and stays banned.

🔴 The three denominators, reconciled — the estate carried two conflicting prize sizings because each read a different feed, and both were "right":

Re-derived 7 Aug PM, and it is the soundest number we have: on the two COMPLETE days in the log (5–6 Aug) the abandon email sent 21 times = 10.5/day, and it is one per person — 32 distinct recipients across 32 sends, zero repeats. So the recoverable pool is ≈ 315/month, band 250–350 given only two clean days.

At the 3–5% recovery benchmark for a considered $97 purchase: ≈ $730–$1,700/mo [MODELLED] — superseding both the earlier "$130–430" (Stripe denominator) and "$900–1,500" (job-register denominator) figures, and superseding this document's own first-pass "$440–1,450", which was built on a pool estimate lower than the measured send rate. Never quote the $4,268 attempted total as the prize.

🔴 A trap this document walked into, recorded so nobody repeats it. The morning pass cited "42 sends, 4–7 Aug" from the per-message log. Four hours later the same query returned 32 — the 3–4 day retention floor had advanced and 4 Aug fell from 11 sends to 5. Per-message counts are a moving snapshot and are not reproducible; the full-day rate is the stable statistic. Cite the rate, never the raw total, and never read the earliest day in the log as a start date.

Why Stripe sees so much less — the mechanism, worth knowing before anyone "fixes" the gap: the quiz hands the checkout a prefilled email, so Nic's system has an address at page load, while the Stripe record only mints on email blur — an interaction a prefilled field never fires. Hence 10.5/day of real abandoners against 1.5/day visible in Stripe. Nothing is broken; the two systems are watching different events, and the tag (63773) is the one that matches the audience.

The $97 window is UI-only today [LIVE probe 4 Aug, AGA-68]: TMA_QC_OFFER_EXPIRED never returned true — including for a 90-hour-old abandoner — and lapsed cache entries re-mint a fresh 48h. Aga ruled the window binding (4 Aug) but the enforcement is assigned to nobody (AGA-109 open, NIC-44 stranded at moved-to-aga). Until enforcement ships, no email may claim a deadline — which is why E3/E4 carry do-not-paste banners and only E1/E2 can launch.

3b · v3 checkouts — nothing to recover yet

[LIVE]: 5 weeks = 53 GA4 visitors → 4 cards → 1 payment; 90 days (8 May–6 Aug) = 66 starts, 8 matured trials, 0 conversions.

🔴 AND THE ONE "SALE" IS NOT A SALE. Re-derived 7 Aug PM from tools/finance/quiz_sales_by_version.json: the single paid record on this rail is nic+testtracking+1@themovementathlete.com, created 22 Jul, since cancelled. checkouts-v3 has produced ZERO real revenue in 90 days — the "$24.97" figure that circulates for this rail is a test transaction. Anything that quotes v3 revenue is quoting Nic testing his own checkout.

My dry-run of the reconcile bridge (7 Aug): 19 PIs in 48h, 0 abandoned carrying an email. The 117-subscriptions/2.2-per-visitor phantom-mint figure (NIC-92) was measured over a window that is 90% pre-defer-mint — likely debris; no post-3-Aug census exists yet. The 16 past_due subs with real addresses are a dunning population (retention rail), not abandonment.

Verdict: v3 abandonment recovery is worth ≈ $0/month today — the funnel has ≈ 0 identifiable abandoners AND zero real sales to recover toward. The binding constraint is traffic, not machinery. What we do anyway is cheap and makes the audience visible from day one — §5.4.

3c · The wider funnel, for scale (Intercom census, 90-day-active with email [LIVE 7 Aug])

A survey-unfinished 4,356 · B finished-no-workout 6,775 · C workouts-no-trial 2,809 · checkout-reached 432 · payers ~1,126. The quiz stage tags will grow into these numbers from 7 Aug forward. Audiences A–C belong to the funnel-stage export lane (Task 11) and nurture/ re-engagement — mapped here so nobody double-sends, owned there.

4 · THE AUDIENCES — in priority order, with what we may say to each

Buyer-safety law on every lane, unchanged: a buyer can never receive a recovery email — paid check at sync AND at send, fails safe (any Stripe error = treat as paid, skip).

5 · STRATEGY — one recovery conversation, sale-first, free-fallback last

The design principle everything below serves: an abandoner should experience ONE coherent conversation that remembers them — not five systems firing independently. The sale is asked for while the intent is warm; the free door opens only after the sale has been genuinely declined; every touch proves we remember who they are (their goal, their obstacle, their words).

5.1 · D1 — Nic's email MOVES to day 4. It should not die, and it must not stay at T+1h.

The case against T+1h (our own coverage audit, 4 Aug, now backed by measurement): arriving free one hour after someone declined $97 actively undercuts the live window and teaches the reader that declining a price produces a better one. 90.7% of annual sales in 24 months went at exactly 50% off — this list already waits for edges; training decline→free is the most expensive lesson we can teach. External data agrees: over-generous free access cannibalises paid (~2.6% freemium conversion vs 31.4% opt-out trial).

The case against stopping it: it is the ONLY reliably-firing recovery asset TMA has — 10.5 sends/day, 29.3% opens, zero maintenance — and its content (start free, no card, exact-level plan) is genuinely the right last door: an honest fallback for the person who was never going to pay $97 this week. Killing it recovers nothing and discards a working asset.

Therefore: move it to day 4 — the slot the master doc's Decision 1 already recommended and Aga never ruled on. It becomes E4's free door (alongside the quarterly $49.97 standard — see the E4 note below). One Nic change (timing), ~15 min. Interim, already enforced in code: our arc holds at 24h+ (quiz_abandon_sync.py --hours 24, docstring-locked), so nothing collides regardless of when he ships. 🔴 If Aga instead rules "keep at T+1h", the arc below still works — E1 then leads with the sale AND acknowledges the free email ("you'll have my note with your login — that stands"), and we never repeat its content. If she rules "stop entirely", day 4 loses its free door and E4 becomes quarterly-only. The arc is robust to any D1 outcome; the recommendation changes only which door opens last.

While it lives, wherever it lives: the copy carries 4.9★ (banned — 4.7/4.8 only) and the wrong accelerator spelling in the repo version — one-line fixes for Nic in the same deploy [UNVERIFIED against the live template — verify then fix].

5.2 · The quiz recovery arc — the rebuild spec

Feed fix first (fleet, no Nic, ~1h): re-point quiz_abandon_sync.py's supply from Stripe incompletes to tag 63773 NEW quiz-reached-checkout (Stripe stays as the buyer-safety check and the KPI read). This alone takes the lane from seeing 1.5/day to ~5/day — and it is the same audience definition Nic's email uses, so the two systems finally agree on who an abandoner is.

The arc (756 = E1–E3 · 757 = E4; fresh AC shells — the current ones are defective and the E11 row describes a dead July build):

The personalised rebuild (FLEET-42, queued): the current E1–E4 pass lint but use ONLY persona — zero of the ten new fields. The rebuild adds the obstacle line and stakes echo for Tier-A leads with AC conditional content, a LEAD-tier-only fallback variant for Tier B, and every placement passes the empty-string test. %TMA_QUIZ_OFFER%/%TMA_QUIZ_PLAN% (declared, never used) get used or dropped. E4 gains the email/path params its CTA currently lacks.

The hello@ 1:1 lane stays exactly as designed (HELLO rules: no formatting, no urgency, no discount, converts on replies) — it is the interim surface until 756/757 arm, then retires. D4: the 39 waiting drafts should go this week — the oldest are already past the window where E-arc copy would make sense to them. Two wiring gaps to close when sending: STOP/reply capture for the subject "your signup didn't come through" is not in reply_fulfil.py (HELLO rule 6), and the AGA-125 row title still quotes the dead v1 subject.

Burst hygiene this arc depends on (owned elsewhere, tracked here): 750 E1/E2 five-minute gap + E1's 1.14% unsub (email fleet / EVOLUTION LAW slot work) · verify-email double-welcome into 992 — 🔴 this doc previously said "(NIC row exists)"; the 7 Aug estate sweep proved NO such row existed. Minted 7 Aug PM (see the queue); J1 in the journey master kills the email at its root · [Chosen Password] literal in the results email (Nic, one line) · on 756 entry the contact is DELETEd from 750/751 with no re-enrol — acceptable for the window, but the exit hand-off (above) must exist so completers don't fall into silence.

5.2b · 🔴 THE ONE TIMING TABLE — every surface, one place, reconciled against the WINDOW

Six files carried four different E2/E3 timings, and the master contradicted itself between §5.2 and §5.3. This table is now the only timing authority in the estate; nothing else restates a number.

🔴 THE CONFLICT NOBODY HAD SPOTTED, and it invalidates E3 as written. Under the interim timing, E3 lands at ~66h — but the window dies at 48h. So E3's subject ("Tonight, $97 becomes $157") fires ~18 hours after the price already reverted. The original design (E1 ≤60min → E3 at ~40h) was coherent; the 24h collision shift broke E3's premise and no document noticed. Two valid resolutions, and the fleet must pick one in the rebuild:

• (a) If D1 ships (Nic's email moves to day 4): E1 returns to ≤60min, E2 ~+21h (22h), E3 ~40h — inside the window, and the arc is coherent as originally designed. Preferred.
• (b) While the interim 24h floor stands: the honest window beat is E2 at 45h (~3h left), and E3 must be rewritten as a "the window closed" beat, not a "closes tonight" one. Shipping E3's current copy on the interim timing is a false claim regardless of D2.

Two different 24-hour floors exist and must never be conflated: MIN_AGE_H = 24 in quiz_abandon_manual_notes.py governs the 1:1 note; --hours 24 in quiz_abandon_sync.py governs the AC arc's supply. Same number, two scripts, two purposes — change one and the estate reads as if both moved. 🔴 And the 1:1 lane has a 7-day ceiling (MAX_AGE_H = 168) with no equivalent on the arc, which means a >7-day abandoner today receives nothing at all — a silent exit no document stated until now.

5.3 · Collision architecture — one map, three systems

Until D1 ships, the timeline for a fresh decliner is: Django burst (T+0) → Nic free email (T+1h) → quiet gap (enforced by --hours 24) → our E1 (24h) → E2 (45h) → [E3 66h once D2] → hello@ note only if the arc hasn't touched them (the manual lane excludes synced contacts) → E4/free door day 4–5 → hand-off. Frequency stays inside the Core-tier ceiling (max 1/day after T+0 — the T+0 burst itself is the defect being fixed, not a budget). Rule for every future collision check: AC-only checks are incomplete — Nic's Django sends must be checked explicitly, from reference_transactional_email_architecture_and_abandon_trigger / the SendGrid instrument.

5.4 · v3 — capture now, sequence later

1. Wire cart_abandon_reconcile.py hourly now (launchd + register row + status file, ~30 min fleet work). It is dry-run-verified correct and idle; wiring it costs nothing and means the day v3 gets traffic, the audience is already tagged (AC tag 63598 + field 56 — currently orphaned assets, claimed by this).
2. No v3 sequence until the audience exists. Trigger to build: ≥20 identified v3 abandoners in a rolling 30 days (the reconcile status file makes this a number someone can watch). When built: separate AC shells (756/757 are the quiz lane's — never shared), reusing the quiz arc's structure with plan-family-aware copy.
3. Fix the recovery path defects that bite returners today: NIC-59 (the 50off expired-state button 404s — and expired-state is NORMAL for returners because of the evergreen localStorage countdown) is on Nic's brief; upgrade/ links never go to logged-out audiences.
4. 16 past_due v3 subs → dunning lane (already flagged to retention).

5.5 · Win-back — fix the gate, then the offer, in that order

1. 🔴 FLEET-10 first, this week (30 min, fleet): the limit=10 Stripe pagination bug is still live in check_saves.py/r1_daily.py while wb_tag.py tags wb-eligible daily — a paying member on an 11th record can be mis-tagged expired. The day 976's offer ever fires, that's a paying member receiving a win-back discount. Fix the pagination (or pause wb_tag.py the same day).
2. D3 — the price contradiction, Aga's call: 21 Jul canonical ruling says reason-gated, price branch ANNUAL SAVE30 $109.90, reply-based, no link, $9.99-forever RETIRED; OFFER_LADDER §1b says re-offer $9.99-ONGOING; FLEET-32 currently instructs the fleet to wire the latter. Recommendation: SAVE30 reason-gated (newer, built on the exit-survey evidence that 65–71% would pay nothing — blanket discounting is out; ~89% of discount-saved re-churn). Whichever wins, the loser gets banner-stamped the same day.
3. Then FLEET-32: move 976's ask into a step that actually sends, with the D3 offer — the current state (offer at step 6/day 38 with 0 sends, holding a banned /30trial/ link) is "cleanest offer in the estate" on paper and unreachable in practice.
4. The §1b gate stands: no checkout link to cancelled payers until Nic answers (a) does a reactivation link/coupon exist, (b) cancel-event semantics (85/112 recent cancellers still have access — a checkout link double-bills them). Reply-based delivery (no link in the email) sidesteps this and is already the 21 Jul design.
5. R1 rail: untouched. It works (1 save, 5 dunning recoveries, 4 replies); its economics are the retention fleet's, mapped here only so nobody double-sends its audiences.

6 · MEASUREMENT — what the KPI is, and what is honestly readable

KPI: recovered purchases within 96h of a recovery touch, read from Stripe money. Never opens (MPP-inflated), and — until AGA-130 is decided — never clicks (tracking is OFF account-wide; every clicks_count in the estate is 0 by construction). The zero-risk click path: UTMs on the recovery CTAs (quiz-root law) read in GA4 — already how E1–E4's links are built.

Weekly persona-split audit → _lifecycle-audits/, findings feed SPEC-CART-ABANDONMENT. Experiments (one at a time; ~5–10/day volume means weeks per read, so sequence them): QCA-02 E1 latency (24h vs ≤60min — becomes readable the day D1 ships) → QCA-03 persona-conditional vs universal → QCA-01 E4 quarterly vs free-door order. At this volume a formal split on anything subtler is theatre — ship the doctrine, read Stripe monthly.

6b · ⭐ WHAT MAKES THIS WORLD-CLASS — and the three things we built to get there

Benchmarked against standard practice, the engine was already ahead (real per-person prose with graceful degradation and a per-run audit manifest — most DTC brands never get past token substitution). Three gaps separated us from top-tier. All three are now built.

(1) Honest incrementality — the holdout · quiz_abandon_recovery_read.py

Almost every "recovery revenue" number in the industry is fiction, because it counts people who would have bought anyway. RevenueCat's 2026 win-back figure is the same shape: ~20% of lapsed users reactivate with zero intervention, so any campaign claiming credit below that baseline is claiming credit for gravity. The master cited that law in its own footnote and never applied it to this lane.

The instrument now reports two rates and refuses to conflate them: TOUCHED vs HOLDOUT (a stable per-person hash, so nobody flips arms between runs). The lift is the difference. The lift is the only honest claim.

First read, 7 Aug PM [LIVE]: touched 39 · 0 recovered (sends were ~3h old — the 96h window has barely opened; the honest read is ~11 Aug). Untouched-and-not-holdout: 5 · 1 recovered (20%) — a tiny sample, but exactly the natural conversion a holdout exists to measure, and a preview of why the holdout matters.

🔴 The holdout is DISABLED by default (HOLDOUT_EVERY = 0) and is a decision for Aga, not an engineering default — deliberately not emailing someone who might buy is a commercial choice. D7 below. Until it is on, the tool prints: "NO HOLDOUT — recovery is NOT attributable. The touched rate is an upper bound."

(2) One collision map, enforced in code · abandon_collision_gate.py

Every collision check in the estate before this read ActiveCampaign only — incomplete by construction, because Nic's Django send appears in no AC automation, trigger or calendar. An all-clear from an AC-only check was never an all-clear.

One gate, one person, four systems: Gmail sent logs · Django→SendGrid live Email Activity (impossible before the read-only key existed on 7 Aug) · ActiveCampaign current automations and unsubscribe status · Stripe live buyer check, failing safe. Exit 0 clear · 1 HOLD · 2 undetermined-treat-as-HOLD.

It caught a real collision on its first run [LIVE 7 Aug]: a live abandoner held because "Nic's abandon email sent 9.8h ago (< 20h) — would double-touch", plus a warning that they are currently inside 750 TMA | Welcome Sequence After Quiz. That is the exact double-send the estate could not see before today.

🔴 It also closes a real suppression hole: the 1:1 lane checked only suppress.csv, so someone who unsubscribed in ActiveCampaign could still receive a personal note. The gate now treats an AC unsubscribe as a HOLD.

(3) Reply-as-a-channel · reply_fulfil.py (quiz-abandon rule)

Every one of the 39 notes ends "just hit reply", and replies are the hottest signal this lane produces — a human who declined a price and then chose to write back. There was no fulfilment path: a reply saying "yes, send me the link" met a generic draft with no link in it, no SLA, and no owner. It had already cost money — a reply promised a comped premium (AGA-127) with no budget rule behind it.

Now: intent is classified (link-wanted vs question), the draft carries that person's own persona checkout resolved live and HTTP-verified — never a generic link — STOP suppresses instantly, and the run surfaces SLA 12h: a reply from a price-decliner is answered the same working day. Still drafts-only; Aga sends.

6c · 🔴 D6 + D7 — two more decisions this work surfaced

And one defect the timing work exposed, already fixed: the 39 sent notes linked to the checkout without &email=, so the page could not resolve that person's real deadline and minted a fresh 48h window instead — the exact defect the coverage audit fixed in E1–E3 in early August. Corrected in the engine as part of D6.

7 · BUILD PLAN — ordered, owned, sized

Phase 1 — fleet, this week, no approvals beyond this doc:

Phase 2 — Aga (~1h total): D1–D5 rulings · build 4 fresh AC shells (3 in a new-generation 756, 1 in 757) and paste the fleet's HTML (~20 min, click-by-click spec exists) · un-pause 756 only · one end-to-end test contact · create QUIZ_ABANDON_ENROL_ARMED (the QA gate is already 18/18 green, and re-runs before arming) · send the 39 notes (D4).

Phase 3 — Nic (~1–2h total, via his brief once Aga approves): move the free email to day 4 + fix its 4.9★/spelling (D1) · $97 window enforcement at charge time (D2 / AGA-109 — the engineering half currently assigned to nobody) · [Chosen Password] one-liner · (already on his brief: NIC-59 dead return-path, NIC-92 post-ship mint census, RETURN_URL).

Sequencing truth: Phase 1 and the 39 notes recover money in week 1. E1/E2 can arm without either Nic item (the arc simply starts at 24h with no deadline claims). E3 waits on D2 enforcement; the day-4 free door waits on D1. Nothing waits on v3 or win-back — they run on their own tracks.

8 · STANDING LAWS + the contradictions this sweep found

Laws carried forward, unchanged: buyer-safety fails-safe · stage-gated personalisation + empty-string test (§8 of the contract) · HELLO rules on 1:1 (no formatting/urgency/discounts) · one offer per email, ladder descends only post-refusal · E4 quarterly $49.97 standard, no coupons · never "you left something in your cart" · never claim a deadline the code doesn't enforce · 4.7/4.8★ only · AC-only collision checks are incomplete (Django sends exist) · TAG=state FIELD=data.

The estate contradictions found by this sweep — each with its disposition:

Provenance: three read-only exploration agents (v3 estate · quiz lane · win-back/constraints), 7 Aug 2026, every claim file-quoted; SendGrid census via the read-only key created the same day; AC census via quiz_lead_signal_check.py; Stripe via quiz_abandon_sync.py dry / the reconcile dry-run; external benchmarks: Klaviyo/Attribuly/Sendtric 2026 cart-recovery series + RevenueCat 2026 (win-back natural-reactivation baseline ~20%, a campaign must beat it to claim credit).

CANCELLATION & WIN-BACK — the strategy of record

Built 11 Aug 2026 · every number measured live the same day against Stripe, ActiveCampaign and the operational cancel queue — never from a doc. Owner seats: tma-retention-lead (the lane) · tma-email-offer-strategist (the offer) · tma-email-architect (the arcs).

🔴 Read this before touching 976 Cancelled Win-Back, the hello@ R1 lane, the in-app cancel downsell, or any "come back" offer. It supersedes the working assumption — carried by OFFER_LADDER.md §1b and by FLEET-32 — that the cancelled-payer lane's job is to re-offer the $9.99-ongoing rate. That is the wrong offer for 73% of the people in it, and it is not the floor it claims to be.

§0 — The decisions this document exists to force

§0a — WHAT IS ACTUALLY TRUE (the source-of-truth block)

Everything below was measured live on 11 Aug 2026 against Stripe, ActiveCampaign and the operational cancel queue. Where a belief the estate held is overturned, the old belief is named.

🔑 The one-line version: three in four people we call "cancelled" are still paying customers with three months left, and the only thing we say to them is a price cut for a product they told us they weren't using.

§1 — The measurement that reframes everything

tools/retention/cancel_queue_export.csv, read 11 Aug 2026 — 115 people:

🔴 Three in four have not left. They switched auto-renew off and are still training — on average for another ~3.5 months. "Win-back" is the wrong job for them. A checkout link is also the wrong mechanic for them — not because it reliably double-bills (§2c measured that: 355 of 370 repeat purchases resolve cleanly), but because modifying the subscription they already hold is cleaner, keeps auto-renew intact, and avoids the 4.1% of cases where something does slip.

Context: retention is the company's binding constraint (76 cancel-ends MTD, ~$1,090 MRR lost; churn out-running sales 52:38 in 7 days). This is the lane where that is decided.

§2 — 🔴 THE OFFER IS WRONG, AND THE ARITHMETIC IS THE PROOF

OFFER_LADDER.md §1b states: "$9.99-ongoing is the floor; you cannot out-discount the save." For an annual member — 73% of this queue — that is arithmetically false.

Annual-at-50% is $41.38 a year CHEAPER for the member AND roughly 2.9× the cash for us. The modelled $27 is $9.99 × the ~2.7-month mean life implied by the monthly cohort's 36.7%/mo churn (annual churns 9.1%/mo, and is locked regardless). Tagged [MODELLED] — the multiple is directional, the direction is not in doubt.

⇒ We have been treating our worst offer as our best one, because "deepest monthly discount" was mistaken for "deepest discount". The member's own decision is annual-shaped; the save should be too.

The plan-aware rule this sets:

🔴 Open, and it collides with this: AGA-114 — we currently quote two different prices for annual ($97 on the quiz paywall, $78.50 via the email offer). Settle that before this ships, or a win-back reader can be shown a third number.

§2a — 🔴 AGA IS RIGHT: RETIRE $9.99/mo AS THE DEFAULT CANCEL-SAVE

Aga, 11 Aug: "in the past we said that $9.99 doesn't make sense to us monthly and it really undermines our app… it's also really hard to build revenue and MRR on this." Agreed, and the evidence sharpens it three ways.

1. It is not even our cheapest price. Annual at 50% is $78.50/yr = $6.54/mo. The "deepest discount" is 53% MORE per month than what we sell to brand-new customers every day (90.7% of new annual sales go at 50% off). It is not a deep discount — it is a small single payment. We have been calling one the other.

2. It cannot build MRR — now MEASURED, not modelled. 🔴 Correction to my own first pass: I said "21 people are on it" — that was survivors only, and it understated the footprint 25×. Every subscription ever created on nine-ninetynine, all statuses: 516, of which 493 have cancelled, 20 remain active, take rate ≈ 6.5 people/month over 79 months.

The save does not save — it defers, by two months, at 40% of the price. Against annual-at-50%, which banks $78.50 on day one, the $9.99 rate returns $34. (My earlier [MODELLED] ~$27 was close; this supersedes it with measurement.)

🔑 The break-even that makes this testable: annual-50% only needs 43% of $9.99's take rate to win ($34 ÷ $78.50). It can convert less than half as often and still be the better offer.

3. It is aimed at a reason that mostly is not price. 210 exit-survey responses (tools/retention/reason_log.csv), keyword-classified — crude, multi-label, 30% unclassified, so read as DIRECTIONAL not precise:

And the price answers are frequently value answers in disguise — verbatim: "Too costly, but not using it enough to justify" · "Price and dont use". A discount cannot fix "I wasn't using it" or "the app kept crashing." It only makes the same loss cheaper.

⇒ The replacement: branch on the REASON, not on the plan alone

Keep $9.99/mo as a rare human-granted exception on the hello@ rail — never an automated popup. That preserves the tool for the one-off case Jesse judges worth it, without teaching the list that cancelling is how you get a better price. Do not disturb the 21 members already on it.

🔑 The reframe: a cancel-save is not a discount mechanism, it is a diagnosis mechanism. We were answering every reason with the same price, and it was the wrong price.

§2b — 🔴 THE SAVE AT CANCEL IS A COUPON, NEVER A CHECKOUT (correcting myself)

I nearly shipped a double-billing instruction to Nic. I recommended pointing the cancel screen at checkouts-v3/50off/12month/. At the cancel moment the member still holds an ACTIVE subscription — 88 of 115 have access, median 106 days — so a fresh checkout opens a SECOND subscription and bills them twice.

This is not a new discovery. The 10 Jul R1 rebuild had already caught the identical defect in the old sequence: "/50promo/ = fresh checkout = double-billing risk for still-active subs." I proposed the same mistake in a new place because I did not read the prior work first.

🔑 The rule — CORRECTED 11 Aug, see §2c: PREFER modifying a live subscription over selling a new one, but the checkout path is proven, not forbidden.

§2c — 🔴 "A LIVE SUB + A CHECKOUT = DOUBLE-BILL" IS FALSE AS AN ABSOLUTE (Aga's catch, then measured)

I wrote that rule twice in this document and once in the memory index. Aga rejected it: "it doesn't double bill — our system recognises their email and they can upgrade and rebuy." She is right, and rather than argue it I measured every customer since 2024.

355 of 370 repeat purchases resolved cleanly. The upgrade/rebuy path works as she said.

🔑 My error was generalising a documented RISK into a claimed OUTCOME without measuring it — the same shape as reading a queue row as a state. 🔑 And the test matters: overlapping subscription date ranges returns 193 hits and is meaningless, because that is exactly what a normal upgrade looks like. The honest test is overlapping paid invoice periods (lines[].period > 3 days apart, across two different subscription ids).

The corrected rule

Prefer modifying a live subscription over selling a new one — but the checkout path is proven, not forbidden. At a 4.1% slip rate, any flow that sends a live subscriber to a checkout must end the old subscription.

The cancel-screen save is still a coupon (§10) — because it is the cleaner mechanic and keeps auto-renew intact, not because a checkout would double-bill.

💸 But 15 people did pay twice — $1,662.86 on the redundant subscription

Rare, but each is a real person charged for something they already had — and nothing in the estate was watching for it.

🔴 STANDING RULE — REFUNDS ARE NEVER THE FLEET'S (Aga, 11 Aug 2026): "you are not allowed to do refund ever… THIS IS NOT ALLOWED, DO NOT EVER DO THAT." I had closed this section by offering to execute the refunds via the Stripe API once she picked which ones. The offer itself was the violation — a refund is money leaving the business and an irreversible act on a real person's card, so both the decision AND the execution are a human's. The fleet's whole job here ends at surfacing the finding with the accounts and the money named. No fleet, seat or session proposes, shortlists or performs a refund. This applies estate-wide, not just to this section.

What the fleet MAY do next, and it needs nobody: diagnose how these happened — whether a specific path leaves the old subscription running — from Stripe alone. That is a defect investigation, not a money movement.

§3 — Two jobs, two rails, two arcs

What is missing today, and it is the biggest gap in the lane: we ask the still-inside 88 one question at cancel, then go silent for ~106 days while they are still paying us. The only thing that reverses a cancel decision is the product working again.

Proposed re-earn arc (no offer at any point): 1. T+0 — the existing R1 note. One question, no pitch. Keep exactly as is. 2. ~day 30 of remaining access — behaviour-gated: "you've got N days left — here's the one thing to do with them." Aimed at a session, not a sale. 3. ~day 75 — the honest checkpoint; surface what they'd lose that isn't the subscription (calibration, skill-tree position). 4. At access-end — hand off to the win-back arc, which is where price finally appears.

Proposed win-back arc (976, entering at access-end): reason-to-return → proof → the plan-aware offer as the last beat, once, with a real deadline. Never re-pitch an identical-or-worse offer than the one they already declined at cancel — which is exactly what it does today.

§4 — What is actually blocked, and on whom (I got this wrong first)

Correction, same session. I first told Aga the $9.99 checkout was a Nic build. It is not needed for the recommended path — the annual-50% door already exists and is the better offer (§2). Recording the retraction because the wrong version was said out loud.

§5 — 🔴 Our self-serve billing portal offers exactly one door, and it is the exit

Live config bpc_1PVK9OI6s6pBAbnm6Al4K8la (default, active), read 11 Aug:

A member can cancel themselves and cannot change plan, downgrade to $9.99, or pause. The only self-service action we offer is leaving. Enabling subscription_update is a configuration change, not development, and it turns the $9.99 rate from a popup that appears at the single worst moment into a standing alternative to cancelling.

⚠️ UNVERIFIED, and it needs one look: whether the portal still offers "Renew" on a cancel_at_period_end subscription with subscription_update off. Both R1 templates promise it — "turning renewal back on takes about a minute… renewal is one click from there." If it does not, every cancel-save email we send points at a button that isn't there.

§5a — PAUSE: withdrawn, then REINSTATED by Aga — and the research says she is right

I proposed pause, then withdrew it after reading the 10 Jul rejection. Aga pushed back: "maybe we could leverage the pause for a different type of user — maybe this still makes sense." She is right, and the industry evidence is not close (§8): pausers resume at 40–60%, against 3–10% win-back rates for fully-cancelled subscribers, and ~25% of would-be churners pause rather than cancel. Pause is the single most effective mechanism in a cancel flow. Nothing else we can build competes with a 5–10× multiple.

What July got right, and it still binds: the mechanic must differ by plan.

🔑 The annual insight is the one everybody misses. An annual member has already paid, so "stop billing me" is meaningless to them — but "I'm injured for eight weeks and my year is burning" is exactly why they cancel. Freezing the term costs us nothing and converts a cancel into a deferral. That is the different type of user Aga was pointing at, and it is 73% of the queue. (July measured pause against monthly-only and correctly found it thin — the term-extension framing was never on the table.)

Two hard requirements before it ships:

1. 🔴 Entitlement gating. Stripe's pause_collection leaves status: active, so an app that gates access on status alone hands out free accounts. Documented 10 Jul, re-proved 11 Aug.
2. Not a portal toggle. The portal field reads "subscription_pause": {"enabled": false} and the feature is deprecated; the real path is native POST /subscriptions/{id}/pause or an app-side term extension. 🔴 And our web cancel button is CUSTOM, not the Stripe portal (Aga, 10 Jul), so portal settings do not govern that screen at all.

Record correction: the July note says Stripe "removed subscription_pause… no such feature field". Measured 11 Aug, the field exists and reads enabled: false. Whether it can still be set is [UNVERIFIED] — deprecated, and testing means writing to live billing config. Immaterial to the plan: the native path is the one we want anyway.

And WB4 stays retracted. "Toggle plan-switching OFF until Nic confirms webhook consumption — would desync entitlements" (10 Jul). The portal writes to Stripe only; the app learns via webhooks nobody has verified (our key is 403 on webhook_endpoints).

§6 — Today's cancellers never enter the win-back arc at all

Of the 115 in the cancel queue, 105 resolve in ActiveCampaign and ZERO are enrolled in 976.

Good: the two systems do not collide. Bad: when a current canceller's access ends, nothing fires. 976's 331 entrants are a different, historic population — it has sent 1,476 emails across 6 campaigns at ~0.2% CTR and produced no measurable return.

And it is armed wrongly: 2 of its messages carry /30trial/, banned for this audience — message 13204 has already sent to 219 people. No harm resulted (0 human clicks; the one recorded click is IP 127.0.0.1 / OkHttp, a prefetch — and 0 of 648 active subscriptions are duplicated), but it remains live. Now machine-watched: tools/retention/audience_banned_link_check.py, registered in estate_selfcheck.py.

§6a — 🔴 976 Cancelled Win-Back ALREADY FIRES AT ACCESS-END (measured, and it corrects us both)

Aga believed it fired at cancel-click; I had said the trigger was unknowable from the API and proposed moving it. Both wrong — and her instinct that it was checkable was right. Entry triggers are not API-readable, but you can infer the trigger from behaviour: join each entrant's AC adddate to their Stripe canceled_at and current_period_end.

14 of 14 sampled entered on the day their access ended. The gap to cancel-date ranges 3–347 days. A member who cancelled 22 Aug 2025 entered on 5 Aug 2026 — the day their annual expired. Independently corroborated by §6: the live cancel queue (people who still HAVE access) has zero overlap with this automation.

What this changes

1. WB3 dissolves. No builder change. The arc's entry is already correct — the split in §3 is how it already behaves, not a migration.
2. 🔻 The /30trial/ finding is DOWNGRADED from a safety defect to an offer defect. The ban exists because "a still-paid-up annual who clicks it starts a SECOND subscription" — but nobody in this arc still holds a live subscription when they enter. That matches the measured outcome exactly: 0 double-bills across 648 active subs. It is still the wrong offer (the acquisition rate, and worse than what they refused at cancel — §2), and it still must be replaced. It is not the live hazard I first called it.
3. The re-earn gap is the whole story. With win-back already correctly placed at access-end, the untouched opportunity is the 88 people with a median 106 days of paid access left, whom nothing addresses after the single T+0 note.

🔑 Method worth reusing: when a config is unreadable, measure the behaviour it produces. "Not API-readable" is a statement about one endpoint, not about the question.

§8 — THE INDUSTRY STANDARD we are being measured against

Researched 11 Aug 2026. These are other people's numbers, not ours — use them as the bar, not as evidence about TMA.

The two rules that indict our current flow

1. Survey FIRST, then an offer matched to the stated reason — downgrade for an oversized plan, pause for "not the right time", a discount only for price. 🔴 We show one price to everyone before we have asked anything.
2. 🔴 Measure the 90-day retention of the people you save, not the save rate. The standard's own words: "a save that only delays cancellation by two weeks is not a real save." Our $9.99 save has a median life of 2.0 months (§2a). We are the textbook anti-pattern, and the only reason we could not see it is that nobody had measured what happened after the save.

Sources: Finsi — cancel-flow best practice · Userpilot — cancellation flow examples 2026 · Subscription Index — cancellation flow · Recurly — pause as a retention tactic · Chargebee — the power of pause · Finsi — win-back timing · Airbridge — subscription-app win-back · Klaviyo — win-back examples

§9 — THE TARGET JOURNEY — what should happen to someone who cancels

What changes versus today: stage 0 asks nothing and offers the wrong price · stage 2 is silent · stage 4 exists but pitches the acquisition offer and reaches an audience the hello@ lane never hands over (hello@ ∩ 976 = ZERO, §6). Stages 1 and 3 already work and should not be touched.

§10 — THE OFFER STANDARD — one price, two mechanisms

🔴 Four different win-back prices are live in our own records. This section ends that.

Why $78.50 and not $109.90 — and the argument is fairness, not arithmetic. 90.7% of new annual sales already go at exactly 50% off. $78.50 is simply what a stranger pays. Quoting a returning member $109.90 charges loyalty a premium, and $9.99/mo bills them $119.88 a year for the same product. A member who comes back should never pay more than a cold lead.

The mechanism differs by moment; the number the member hears never does.

🔑 One price keeps the copy honest. A member who sees the T-30 email and the win-back email should never be quoted two numbers — which is exactly the trap AGA-114 already flags ($97 vs $78.50 for the same annual plan). Settle AGA-114 before this ships.

The rule for every other sequence — CORRECTED, see §2c

Prefer modifying a live subscription over selling a new one. The checkout path works — Aga was right and the measurement backs her — but at a 4.1% slip rate any flow sending a live subscriber to a checkout must end the old subscription.

§7 — Verify any of this yourself

python3 tools/retention/audience_banned_link_check.py         # banned links live in a cancel arc
python3 -c "import csv;r=list(csv.DictReader(open('tools/retention/cancel_queue_export.csv')));print(len(r))"
# Stripe: /billing_portal/configurations · /coupons (all duration=once) · /prices unit_amount=999

Companions: OFFER_LADDER.md §1b (amended 11 Aug with the measured answer) · CHECKOUTS_V3_URL_MAP_AND_USE_CASES_2026-08-04.md (never invent a checkout URL) · tools/retention/HELLO_EMAIL_RULES.md (the 1:1 rail's copy law) · AUDIENCE_INTEGRITY_MASTER_2026-08-07.md (segment gate before any send).

⚙️ THE PERSONALISATION ENGINE — how one person's email is actually built

⭐🔴 CANONICAL for how TMA renders per-person copy. Written 7 Aug 2026 on Aga's directive: "the mechanism / engine of this is very important as it's building the personalisation that we need to expand on our abandonment sequence." Sub-doc of ABANDONMENT_STRATEGY_2026-08-07.md (§0a is the register). Companions: the ABANDONMENT_OPERATIONS_MANUAL (when things happen) and the ABANDONMENT_DATA_FALLBACK_LADDER (what to do when a field is missing).

The engine is tools/retention/quiz_abandon_manual_notes.py. The code is the canon — this document explains it and must be checked against it, never the reverse. Verify any claim here with python3 tools/retention/quiz_abandon_manual_notes.py --example --tier A|B.

1 · WHY THIS IS THE IMPORTANT PART

Most "personalised" email is token substitution: Hi %FIRSTNAME%, still interested in %PRODUCT%? Everyone can do it and nobody is fooled by it.

This engine renders a different sentence per person — chosen from what we actually know about them, degrading gracefully when we don't, and carrying a real member's verbatim words matched to their goal, age and gender. A Tier-A abandoner receives:

subject: "about the plateau you mentioned" The quiz built you a muscle plan that starts at your actual strength level. And you told the quiz that hitting a plateau is what's been holding you back. For men in their forties, with years of gym training behind them, progressive calisthenics is actually perfect. And the quiz says that's exactly where you are. "…" — a real member, matched on theme × age band × gender.

That is the asset. The 1:1 hello@ note is only the first surface it drives — the same engine is what makes the ActiveCampaign arc (756/757) personalised instead of persona-generic, and what will make any future audience (results-abandoners, v3, win-back) personalised on day one.

2 · THE ARCHITECTURE — a pure renderer plus interchangeable adapters

🔑 Everything above the adapter line is surface-agnostic. Adding ActiveCampaign does not mean rewriting the engine — it means adding a second adapter (§5).

The slot inventory (what the renderer produces)

Full rung logic and the conflict rules live in the FALLBACK LADDER; this table is the index.

Tier detection — measured, never assumed

tier = "A" if any(prof.get(k) for k in ("obstacle","age","gender","background","recency")) else "B"

Per person, from which fields actually returned values — not from the date. A Tier-A person with a half-written profile automatically gets Tier-B rungs for the missing slots. That single line is why the engine cannot fabricate: absent data isn't defaulted, it changes the rung.

3 · 🔴 THE CONSTRAINT THAT SHAPES EVERYTHING DOWNSTREAM: ActiveCampaign CANNOT BRANCH

AC has no HTML conditional content. Verified three ways: data-ac-condition|%IF|%ELSE% matched 0 of 539 live AC message bodies in the repo's API-pulled backups; the scan of 69 live bodies across five automations found 0; and the only two files in the entire repo containing data-ac-condition are our own E1.html (7 blocks) and E2.html (8) — a marker our own fleet invented so a human could rebuild the blocks by hand in AC's designer.

⇒ Load E1 as-is and every reader sees all seven persona paragraphs stacked. Neither file has a default/else block. Liquid {{ }} is separately hard-banned by email_lint.py (AC prints it literally).

What AC provably does: straight merge-tag substitution of a custom field, including inside an href query string. Nothing else.

Therefore the only design that works is PRE-RENDERING — which is exactly what this engine already does. The persona prose moves out of the HTML and into the engine; the email carries one merge tag per slot.

4 · THE AC ADAPTER — designed, not yet built (FLEET-42)

The delta is BODY.format(...) → PUT /api/3/contacts/{cid}. The slot values assemble() returns already are the rendered sentences.

Field ids — live census 7 Aug 2026 (read-only): 54 custom fields, max id 79. - FREE: 57, 72, 73, 74, 75, 76. Six slots, enough for the 3–4 sentence fields needed. - 58/59/60 are utm_source/utm_campaign/utm_content (previously unknown in our docs). - 🔴 All 54 fields are type: text. There are ZERO textarea fields in the account. Field 56 holds a full checkout URL, so text takes ~70+ chars, but our sentences run 100–200. ⇒ STEP ONE IS TO PROVE IT: write one full sentence to one test contact, read it back, confirm no truncation. If it truncates, mint as textarea. Do not mint six fields on an assumption.

Write shape — one call, not four:

PUT /api/3/contacts/{cid}
{"contact": {"fieldValues": [{"field": 72, "value": goal_line},
                             {"field": 73, "value": objection_line},
                             {"field": 74, "value": ps_line}]}}

Proven at 11,500 contacts by funnel_stage_export.py:200. Rate ceiling ~4–5 req/s (sleep 0.18–0.25), retry on 429/5xx, and abort after 200 errors so a systemic fault cannot masquerade as progress. Field creation already exists: ensure_fields() in quiz_abandon_sync.py mints a missing field from a 4-line dict edit.

Four laws for the adapter, each learned the hard way:

1. 🔴 EVERY SLOT IS ALWAYS WRITTEN, with a non-empty default. An unset AC field renders as an empty string — it does not skip the sentence. "the thing standing in your way is " is a shipped defect. A slot that is legitimately absent (the obstacle block) gets a universal sentence, not a blank.
2. 🔴 SLOTS FREEZE AT ENROL — one writer, no mid-arc rewrites. The arc sends over four days, but the fields are shared mutable state on the contact. If anything rewrites them mid-arc (a re-abandon, a second sync pass, a future audience build), E3 renders copy that contradicts what E1 promised. Any writer must refuse to touch a contact whose state is enrolled-*, and the manifest records what was written so the sent copy stays reconstructible.
3. READ BACK — the write is not the truth. Re-read a sample of stamped contacts live, per funnel_stage_export.py:241. And note the one thing that cannot be verified from here: that AC renders the tag at send. That is observable only on a real send.
4. The email must render sensibly with every tag empty. That is the test for whether the default is doing its job.

The collapse this buys: E1's 7 divs → <p>%TMA_ABANDON_GOAL_LINE%</p>. E2's 7 → one objection tag. E2's 8th (the JUST_START P.S.) needs a full-sentence field with a universal default, because an empty field inside <div class="ps"> leaves a styled empty block. 15 fake conditionals → ~3 merge tags, and 30 lines of persona prose move into a dict.

5 · HOW TO EXTEND IT

Add a SLOT (a new personalised sentence): add its lines dict + its rungs, add it to assemble()'s return, add its placeholder to BODY, add its rung row to the FALLBACK LADDER, and check --example on both tiers. A slot with no floor rung is not finished.

Add a SURFACE (a new delivery target): write a new adapter that consumes assemble()'s output. Do not touch the renderer. For AC, follow §4's four laws. For anything with a character limit (push, SMS), the adapter owns truncation — never the renderer.

Add an AUDIENCE (results-abandoners, v3, win-back): the renderer is reusable, but the copy is not — a results-abandoner never saw a price, so price copy is nonsense to them. New audience = new BODY + new subject/goal lines + a stated data tier (a win-back contact holds LEAD-tier fields only). The coverage doc's own line applies: "Nothing about it is quiz-specific except the data source."

Change COPY: edit the engine's constants → the fleet loop (CRO seat → humanizer → Aga) → --example both tiers → --rebuild to re-render existing drafts in place → log the version to FLEET_LOG.jsonl. Locked facts: $97/$157 · under $2/week · 4.8★ (never 4.9) · "LEAD Sports Tech Accelerator — run by the Adidas family and ex-Red Bull executives" exactly · the 60-day guarantee · max 2 dashes.

6 · OPERATOR TRAPS — inherited from the sessions that paid for them

• 🔴 Person-grammar. "for men in their forties, with years of gym training behind them" — when a slot switches to third person, every phrase joining it must switch too. That is why a separate BACKGROUND_THIRD/AGE_THIRD map exists next to the second-person one. A mixed sentence ("for men in their forties… behind you") is the tell that a template assembled the copy.
• 🔴 A multi-line source string defeats a single-line replace. One humanizer edit silently missed because the string was split across lines. Always grep-verify after a bulk replace.
• 🔴 An inherited ANTHROPIC_API_KEY outranks the Mac's claude.ai login in the claude CLI ("Credit balance is too low"). Strip ANTHROPIC_* from the env before shelling out.
• 🔴 A card on a board ≠ uploaded. 756/757 were "built" — meaning files on disk — while live AC held one old 50%-off email and literal placeholder subjects ("r"). Always ac_email_read.py the automation.
• 🔴 Never reconstruct a send from memory. quiz_abandon_sent_log.csv + quiz_abandon_verify_manifest.json hold the timestamps and every per-person choice.
• Pre-7-Aug leads have no AC profile beyond persona (field 61 only, 38/39 findable) — but Stripe always had persona, so checkout routing never degrades for old cohorts.

7 · VERIFY THE ENGINE IS BEHAVING

python3 tools/retention/quiz_abandon_manual_notes.py --example --tier A   # a full rendered email
python3 tools/retention/quiz_abandon_manual_notes.py --example --tier B   # the degraded version
python3 tools/retention/quiz_abandon_manual_notes.py --verify             # manifest, no drafts
python3 tools/retention/abandon_collision_gate.py --email <addr>          # safe to send?
python3 tools/retention/quiz_abandon_recovery_read.py                     # did it recover money?

Every run writes quiz_abandon_verify_manifest.json: per person — tier, which fields were present, persona sources + mismatch flag, the chosen checkout + why + its HTTP status that run, the quote id, and the decision or skip reason. That file is how anyone checks the ladder was obeyed without trusting this document.

📖 ABANDONMENT OPERATIONS MANUAL — what happens, when, to whom, under which rules

⭐🔴 THE operating manual for the quiz-checkout abandonment machine. Ordered by Aga, 7 Aug 2026: "deeply detailed documentation on what is happening, when — hardened, followed rules." Companion to the STRATEGY master (ABANDONMENT_STRATEGY_2026-08-07.md — the why and the decisions); THIS doc is the how, hour by hour. Every time, count and rule below was read from the live system on 7 Aug 2026, and every section names its enforcement point — a rule that lives only in prose is not a rule.

§0 · THE REGISTER — it lives in the MASTER, not here

🔴 One register, one place: ABANDONMENT_STRATEGY_2026-08-07.md §0a. This file used to carry a second copy, which is how two registers with different memberships appear in one estate. If you are looking for "what documents/tools/seats exist", go there.

Scope of THIS file: the quiz-checkout lane only. v3 abandoners and cancelled-member win-back are in the master (§5.4, §5.5) and have no operations of their own yet — that is a real gap, not an omission here.

§1 · THE TIMELINE OF ONE ABANDONER — hour by hour, system by system

A person finishes the quiz, sees results, opens the $97 checkout, starts paying, stops.

§2 · THE RULES IN FORCE — each with its source and its enforcement point

§3 · WHO DOES WHAT

Aga: sends (AGA-125), rules on decisions D1–D5, arms the AC sentinel. Nic: 756/757 upload + activation (E11), the 48h enforcement (AGA-109), his Django send (D1). The fleet: everything else — tma-quiz-checkout-abandon-owner chairs; the data analyst proves the audience (Stripe money only); the copywriter writes inside the ladder; FLEET-42 = the E1–E4 personalised rebuild. The machine: sync every 30 min; the lane on demand; the reply watcher daily at 05:35; all visible in the cockpit's ⚙️ Daily Jobs tracking band.

§4 · THE RUNBOOK — the five commands

python3 tools/retention/quiz_abandon_manual_notes.py            # dry: who would get what + manifest
python3 tools/retention/quiz_abandon_manual_notes.py --verify   # audit only, verbose
python3 tools/retention/quiz_abandon_manual_notes.py --draft    # draft NEW eligible people into hello@
python3 tools/retention/quiz_abandon_manual_notes.py --rebuild  # re-render existing drafts (copy change)
python3 tools/retention/quiz_abandon_manual_notes.py --example --tier A|B   # print a full example email

Sending = Aga in Gmail, or the fleet on her explicit "send them" (throttled, ids logged).

§5 · HARDENING — how this cannot silently drift

The estate-separation assert crashes loudly if a non-quiz sub ever appears · every checkout URL re-verified per run · the manifest makes every run auditable after the fact · the daily tracking band shows the sync's health every morning · the QA gate + sentinel stand between the AC arc and real sends · the copy canon lives in ONE file under version control, changed only through the fleet loop and logged to FLEET_LOG.jsonl · and all four docs of this estate are now pointed to from every abandonment seat and the runbook (verified 7 Aug PM: 4/4 in each of tma-quiz-checkout-abandon-owner, tma-abandonment-copywriter, tma-abandonment-data-analyst and /abandon-fleet) — 🔑 this sentence previously claimed that and it was FALSE: the manual was referenced by ZERO seats and the master by one of three. A hardening claim that is not measured is the most dangerous line in a document, because it is the one a future session trusts.

Three instruments make the claims above checkable: quiz_abandon_recovery_read.py (did it recover money — with the holdout caveat) · abandon_collision_gate.py (all three sending systems + Stripe + AC unsub, before any send) · --example --tier A|B (the rendered email).

🪜 THE ABANDONMENT DATA FALLBACK LADDER — what we do when a field is missing

⭐🔴 CANONICAL for the Abandonment Recovery Fleet (/abandon-fleet). Ordered by Aga, 7 Aug 2026: "They need to understand: if you're missing data, here's what we do." Enforced in code: tools/retention/quiz_abandon_manual_notes.py implements every rung; quiz_abandon_verify_manifest.json records every resolution, every run. Carried by: tma-quiz-checkout-abandon-owner · tma-abandonment-copywriter · tma-abandonment-data-analyst. Data dictionary: LEAD_SIGNAL_CONTRACT_2026-08-06.md §8.

0a · 🔴 THIS LADDER IS SURFACE-AGNOSTIC — it governs every abandonment surface

The rungs below are not a property of the hello@ 1:1 note. They are the contract of the renderer (assemble() in quiz_abandon_manual_notes.py), so the same ladder governs:

• the hello@ 1:1 note (live — 39 sent 7 Aug),
• the ActiveCampaign arc 756/757 once the rendered slots are delivered as merge fields,
• any future audience (results-abandoners, v3, win-back) that reuses the engine.

🔴 The AC surface makes the floor rung load-bearing, not optional. ActiveCampaign renders an unset field as an empty string — it does not skip the sentence. So a slot whose rung-3 is "omit entirely" (the obstacle block) cannot be omitted on that surface: it must carry a universal sentence instead, or the email ships with a hole in it. And AC cannot branch at all (data-ac-condition is not real AC code — 0 of 539 live bodies), which is exactly why the rendering happens here and not in the HTML. See ABANDONMENT_PERSONALISATION_ENGINE_2026-08-07.md §3–4.

Scope note: the cohort boundary and field ids below are the QUIZ estate's. A win-back or broadcast audience holds LEAD-tier fields only (LEAD_SIGNAL_CONTRACT §8a) — a different, shallower ladder that has not been written yet.

0 · The one law above the ladder

A missing field DEGRADES the sentence gracefully. It never fabricates it. Personalisation that guesses ("JUST LIKE YOU, in your 40s" to an unknown-age reader) is worse than none — one wrong guess converts the email from "Jesse knows me" to "this is a template that missed." Enum values never render raw. Every degradation is recorded in the manifest row.

1 · The two cohorts — the data boundary is a TIMESTAMP, not a guess

The quiz began writing the full profile into ActiveCampaign at 2026-08-07 02:47 (NIC-54's first complete lead). That instant splits every abandoner into:

Tier is detected per person at build time from which fields actually return values — never assumed from the date. A Tier-A person with a half-written profile automatically gets the Tier-B rungs for the missing slots.

2 · The ladder — slot by slot

3 · Where each datum comes from, in priority order

1. Stripe subscription metadata — identity, persona, plan, offer, timestamps. Always present on this estate (the checkout stamps itself: checkout_version: quiz_checkout). 🔴 The estate-separation belt: a v3 sub can never enter this lane (hard assert).
2. ActiveCampaign fields by STABLE ID (61/64–71/77) — the deep profile, Tier A only. Never looked up by name; the 5,623 legacy junk tags are never read.
3. The testimonial database (tagged: gender, age band, 18 themes) — the member side of the personalisation; always real, always verbatim.

Conflict rule: Stripe wins for the checkout (it is what they were buying); AC wins for who they are. Conflicts are counted in the manifest (persona_mismatch) — currently 0.

4 · Verification — how anyone checks this is being obeyed

Every run of the lane (dry, verify, draft, rebuild) writes tools/retention/quiz_abandon_verify_manifest.json: one row per person — tier, fields present, persona sources + mismatch flag, chosen checkout + WHY + its HTTP status this run, quote id, decision or skip reason. --verify produces it without touching a draft. Buyer-safety (live has-paid, fails safe), suppression, one-note-ever, the 24h Django-collision floor and the 7-day ceiling all run before any body is assembled.