Home / Ops / More in this area

Affirmology - Automated Mirror Drip (spec v1)

Updated Jul 16, 2026 · Affirmology_MirrorDrip_Spec_v1.md

Affirmology - Automated Mirror Drip (spec v1)

Goal. A few days after a person receives their Origin Soul Song (in the normal demo flow), the system automatically renders and delivers their Mirror reading - no manual batch, no one remembering to press a button. It is the built-in re-engagement beat: the first "how did it know that?" gift arrives, then a deeper one lands unprompted while they are still thinking about the first.

Applies to the DEMO process (every real demo-taker), not just beta.

1. Behavior in one line

On Origin Soul Song delivery → schedule the Mirror for ~3 days later → a scheduled worker renders it from the person's stored Profile and emails it (link to their page), once, idempotently, honoring holds and opt-outs.

2. The trigger

• Fires when a demo render completes and is delivered (the same moment the "Your Origin Soul Song is ready" email is sent - demo_render.py, the delivered/job-complete path).
• At that moment, write a drip row (see §4) with due_at = now + DELAY_DAYS.
• One drip per person per Origin. If a person somehow re-renders, do not double-schedule (dedupe on email/profile_id + kind=mirror).

3. The delay

• MIRROR_DRIP_DELAY_DAYS in app_config (env-overridable). Default 3 days.
• Jeff can dial 2 - 5 without a code change. Delay is measured from Origin delivery, not from signup.
• (Optional later: a small send-time window, e.g. deliver 8am - 6pm the person's local morning, so it doesn't land at 3am. v1 can skip this and just send when due.)

4. Durable queue (survives restart/redeploy)

A new table (or reuse the consumer DB), e.g. mirror_drip: | field | meaning | |---|---| | id | pk | | email / profile_id | who | | origin_job_id | the Origin render it followed | | created_at | when scheduled | | due_at | created_at + DELAY_DAYS | | status | pending → sent / held / skipped / error | | mirror_job_id | the render, once made | | attempts, last_error | for self-heal |

Durable so a "drip opened days later" survives restarts (mirrors the pattern already noted in db_models.py). No in-memory scheduling.

5. The worker (scheduled, like growth_cron)

A Render Cron Job (or a boot poll loop, like chant_runner) runs on a cadence (hourly is plenty): 1. Select status=pending AND due_at <= now. 2. For each, run the gate checks (§6). If gated → mark held/skipped with reason, move on. 3. Render the Mirror from the stored Profile (reuse build_mirror_brief + the existing Mirror render path; length target 12 - 15 min / ~2200 words per the reading-render length rule). One at a time / paced (Fish + Sonnet cost). 4. On success: attach to the person's page, send the Mirror email (§7), mark sent. 5. On failure: increment attempts, store last_error, leave pending for retry with backoff; after N attempts mark error and surface it (no silent drops - self-healing loop principle).

6. Gate checks (do NOT send if…)

• On the email opt-out / suppression list (unsubscribe).
• On .mirror_hold (the Mirror is globally held during its rebuild - the drip must respect this; while held, drips just wait as pending, they do not fire).
• A founder / internal person (exclude Jeff, Sol, test emails).
• Incomplete Profile (no chart) - skip with reason, let the profile self-heal, retry later.
• Mirror already exists for this person (_has_mirror) - mark skipped (never double-send).
• Global kill switch MIRROR_DRIP_ENABLED (default OFF until Jeff flips it, since the Mirror is mid-rebuild and each render costs real money).

7. Delivery

• Email uses the canonical Affirmology_MirrorEmail_v1.html body.
• Audio is stream-only on their page (no attachment, no download) - the email drives them back to their results page, which is the re-engagement point. (Internal review copy to Jeff can still attach.)
• Respects the "deliver by link to the page" rule; the surprise is the point.

8. Cost + safety

• Each Mirror = a Fish voice render + a grounded Sonnet pass. Not free. So: MIRROR_DRIP_ENABLED gate, one-at-a-time pacing, a daily cap (MIRROR_DRIP_DAILY_MAX), and a per-run max_cost_usd like the existing batch. Ask-credit-before-bulk still applies for any backfill of the already-waiting queue.
• Idempotent everywhere: safe to re-run the worker; a crash mid-render never double-charges or double-sends (status transitions + _has_mirror guard).

9. Rollout

1. Build the table + the schedule-on-delivery write + the worker, with MIRROR_DRIP_ENABLED=false.
2. Verify end-to-end on a test person (schedule with a 5-minute delay via a debug override, confirm one send, confirm dedupe + gates).
3. Flip MIRROR_DRIP_ENABLED=true when the Mirror rebuild is approved and .mirror_hold is lifted.
4. Backfill (optional): for people who got their Origin in the last few days but no Mirror, enqueue them.

10. Open choices for Jeff

• Delay: 3 days (default) - or 2? or 4?
• Beyond the Mirror: this same queue can later drip a 3rd/4th gift (the "surprises") on their own timers. v1 = Mirror only; the table is built to hold other kinds.
• Local-morning send window: v1 sends when due; add the time-of-day polish later?