Phase 0 · Foundation Assessment — BEA-20 Marketing Email Builder
The permanent base layer (FAD) for all subsequent work on BEA-20. Written to be consistent with — and to ground — Phases 1–5, which converged on a RETHINK gate and a "measure the binding constraint before building anything" conclusion.
One-liner (manifest): Improve consumer-email build efficiency to scale send volume. Category: Production Automation · Build type: ui-forward-app · Owner/sponsor: Peter Barnett · Proprietary: No.
Foundational caveat (decisive, carried forward to every later phase): The mandate verb is "scale send volume," but the term volume was never disambiguated, and the candidate-constraint set used downstream (authoring labor / approval latency / deliverability ceiling) omitted a likely-dominant fourth constraint — creative/content production. Phase 5 validators (Okafor, Lindqvist, Souza) surfaced both gaps. This Foundation therefore treats the success criteria, scope, and assumptions as provisional pending the measurement study and a mandate-disambiguation conversation with the owner. The honest baseline state is: we do not yet know which constraint binds, or even which definition of "volume" is meant.
1. Success criteria (measurable, time-bound)
These criteria are deliberately split into decision-gate criteria (what must be true to honestly choose a build) and outcome criteria (what a shipped build must achieve). The decision criteria come first because Phases 4–5 proved that committing build capital before measuring the constraint is the central failure mode (innovation theater).
- [ ] Mandate disambiguated within 2 weeks of project (re)start. Owner (Peter Barnett) confirms in writing whether "scale send volume" means (a) campaign-count throughput (more distinct campaigns shipped per month) or (b) recipient fan-out volume (more recipients per campaign / total sends), and states the target multiple (e.g., 2x vs. 10x) and horizon. Metric: a one-page signed mandate definition exists; ambiguity flagged by Okafor is closed. (Without this, the constraint analysis is undefined — at ~90–140 campaigns/year there is no campaign-count volume problem at all.)
- [ ] Binding constraint measured within 8 weeks, before any build commit. A time-motion study decomposes end-to-end campaign cycle time (30–60 hrs assumed) across creative/content production, authoring, approval/coordination, and deliverability/send, and a baseline inbox-placement + headroom study quantifies recoverable deliverable volume. Metric: each of the four constraints has a measured % of cycle time (±10pp) and placement headroom is stated to ±5pp; study cost held to ≤ $60K. Gate rule: no architecture is funded until the study identifies a constraint that the chosen architecture can move.
- [ ] Chosen architecture moves its own measured constraint by a pre-agreed margin within 12 months of build start. Metric depends on what the study finds binds: e.g., if authoring labor is ≥30% of cycle (Architecture A's precondition), authoring hours/campaign drop ≥30% on the head templates; if deliverability binds, effective deliverable volume rises ≥15% on a dedicated subdomain with no reputation-tier regression. The criterion is only valid once the study selects the constraint — a placeholder until then.
- [ ] Zero brand/compliance regressions attributable to the tool over the first 12 months of production sends. Metric: 0 off-brand or non-compliant emails reaching a real segment via any path (including export/edit/re-import); locked-region / required-copy / AA+ contrast enforced at the data-model and export boundary, not the UI. This is the criterion any architecture (and Brand/Legal, per Mercier) can hold the tool to regardless of which constraint binds.
2. Decision-maker profile (Three Ledgers)
- Public ledger (what we pitch): A modern, brand-safe email builder that lets the Beats consumer-marketing team produce and ship more email faster — "improve build efficiency to scale send volume" — on the internal Vibe Elements stack, reducing reliance on hand-coded HTML and external agency build cycles.
- Shadow ledger (what the decision-maker actually optimizes for): A defensible, low-embarrassment internal-tooling win that demos well to leadership and shows the AI/automation initiative producing tangible output, while not provoking a Brand/Legal incident or a cross-org turf fight. The structural pull (Phase 5 Brandt/Chen) is toward the option that ships cleanly and demos beautifully (Architecture A at score 58) even if it does not move the headline metric — because a shipped tool reads as success and "flat volume" can be attributed to other causes. The shadow optimization is shippability and optics, with volume as the stated-but-unfalsifiable cover story.
- True ledger (what will actually get built): Absent the funded measurement study, the realistic default is Architecture A (Locked-Shell Block Assembler) — the cheapest, safest, most demo-able option, and the only one Brand/Legal (Mercier) actively endorses because locked zones make compliance structural. It will likely ship as an authoring front-end on Vibe Elements, deliver real labor/risk-reduction value, and have an ambiguous-to-null effect on volume. The risk this Foundation must guard against is exactly the gap between this true ledger (a compliance/authoring tool) and the public ledger (a volume-scaling tool).
- Owner / sponsor: Peter Barnett (manifest). He owns the mandate definition (criterion 1) and is the person who must fund the measurement study as a precondition rather than allow it to be skipped (Brandt's explicit warning).
3. Constraint inventory
| Constraint | Type (hard / soft / assumed) | Notes |
|---|---|---|
| Brand/Legal governance veto over send mechanics | Hard | Apple/Beats brand-control culture is the load-bearing wall (Mercier, Phase 5). It effectively kills SLA auto-approve (Architecture B's differentiator → ~0 confidence) and escalates programmatic per-recipient entropy injection (Architecture C). Any value that depends on relaxing brand control is organizationally non-viable here. |
| Send-path / DNS / MTA authority | Hard (and likely unobtainable) | Consumer email very likely sends from shared Apple-owned infrastructure the project cannot control; obtaining a dedicated warm-up subdomain or per-subdomain Postmaster data is doubtful (Okafor downgrades to ~0.15). This is a binary precondition for Architecture C — without written authority, C has nothing to actuate and is infeasible, not merely risky. |
| Apple privacy / consent governance on recipient-level data | Hard | Per-recipient build-time processing (entropy injection, frozen segments) triggers DPIA-class privacy/consent review (premortem C:31). Bounds any design that processes recipient-level data at build time; pushes designs toward aggregate/segment-level signals. |
| Receiver (Gmail/Yahoo/Apple Mail) policies, reputation, entropy & auth rules | Hard, external, non-stationary | SPF/DKIM/DMARC chain, reputation warm-up calendar time, complaint thresholds, entropy/fingerprinting — all imposed by adversarial third parties that change unilaterally (e.g., 2024 bulk-sender mandate). Anti-spam expert (Whitfield) holds receivers are unsteerable by construction; the act of building a control loop is itself the anomaly signal. |
| The actual binding constraint is unmeasured | Assumed (and unresolved) | The crux. Cycle time (30–60 hrs/campaign assumed) is split across creative / authoring / approval / deliverability in unknown proportions; ~45%+ of model scenarios assume the wrong constraint. No time-motion study exists. This is the single highest-leverage unknown in the entire program. |
| Vibe Elements / design-token stack stability | Soft | The repo's own git status shows live component-library migration churn (Raghavan, premortem A:8). A canvas tightly coupled to a moving stack risks a mid-build rewrite. Mitigable by pinning a version and wrapping base components behind an internal adapter. |
| Existing ESP import contract | Soft / assumed | The plan assumes the current ESP accepts clean imported MJML/HTML without rework (conf ~0.75). Brittle file hand-off, not an API contract; ESP-side format drift can erase authoring time savings (premortem A:4). |
| Team capacity & specialist scarcity | Soft | ~3–5 engineers for 9–14 months. Architecture C additionally requires a scarce deliverability-engineering specialist; losing that one hire turns C's control loop into an unexplainable black box (premortem C:29). |
| Creative/content production capacity (the omitted constraint) | Assumed, likely-dominant | Multiple validators (Lindqvist, Souza) name creative/copy generation and brand back-and-forth as the largest time block, sitting entirely outside the A/B/C decomposition and upstream of every architecture. If creative is ~50% of cycle, all three architectures attack sub-dominant constraints. Must be added as a first-class candidate in the Phase-1 recursion. |
| External agency incentive alignment | Soft | An external creative agency whose revenue depends on building these emails may slow-walk asset hand-off and template migration (premortem A:9), starving any block library. Requires up-front role renegotiation. |
4. Scope boundary
- In scope:
- Disambiguating the mandate ("volume" = campaign count vs. recipient fan-out) with the owner.
- The time-motion + volume-headroom measurement study as the funded first action (this is the true Phase-6 step zero per Phases 4, 4.5, 5).
- Evaluation and (post-study) build of an internal email-build efficiency tool on the Vibe Elements stack for the Beats consumer-marketing team — most likely an authoring/assembly front-end (Architecture A class) with compliance-by-construction (locked zones, required-copy + AA+ contrast pre-flight).
- Integration with the existing ESP via its import format (read/export boundary), and brand-token/design-system binding native to Beats.
- Out of scope:
- Co-owning or modifying the live MTA/send path, sending subdomains, or DNS (Architecture C's actuation layer) — out of scope unless written send-path authority is separately secured; treated as infeasible here by default.
- Programmatic per-recipient structural variation / entropy injection to influence spam classifiers — out of scope on Brand/Legal and privacy grounds (Mercier escalation; Whitfield "self-defeating").
- SLA-timer auto-approval of campaigns/diffs without a human click (Architecture B's differentiator) — out of scope as effectively vetoed by Brand/Legal governance.
- Creative/copy generation itself (a candidate constraint to be measured, but building a content-generation system is a separate initiative, not this project as currently scoped).
- Multi-channel (push/SMS/web) authoring — email-first mandate; out of scope for the initial build.
- Recursion budget acknowledged: max 3 per phase. Phase 5 already recommends one scoped recursion to Phase 1 (Decompose) to add creative-production as a candidate constraint and disambiguate "volume" (
recursionCountcurrently 0 → 1 on re-entry). This Foundation reserves the remaining budget and does not pre-spend it.
5. Assumption log
| # | Assumption | Confidence (0–1) | Validated? |
|---|---|---|---|
| 1 | The mandate "scale send volume" has a single, knowable definition the owner can state (count vs. fan-out, with a target multiple and horizon). | 0.8 | No — flagged by Okafor as ambiguous; criterion 1 exists to close it. |
| 2 | The current program runs ~90–140 campaigns/year at ~30–60 working hrs/campaign end-to-end. | 0.5 | No — synthetic baseline; no operational data pulled. If true, there is no campaign-count volume problem (Okafor). |
| 3 | Authoring labor is a material (≥30%) fraction of total campaign cycle time — the precondition for Architecture A delivering volume value. | 0.45 | No — explicitly unmeasured; Lindqvist/Souza suggest it is small relative to creative. |
| 4 | Creative/content production (not authoring/approval/deliverability) is the actual largest time block. | 0.6 | No — surfaced in Phase 5 validation; never modeled in Phases 1–4; the reason for the recommended recursion. |
| 5 | The project cannot obtain authority over the live send path, sending subdomains, or DNS at Apple. | 0.7 | No — strongly implied by Okafor (shared Apple infra; authority ~0.15); not formally confirmed. Drives C's "infeasible-here" default. |
| 6 | Brand/Legal will veto SLA auto-approval and per-recipient entropy injection in this org. | 0.85 | No — strongly asserted by the governance owner (Mercier) but not yet a written ruling; treated as effectively binding. |
| 7 | The existing ESP will accept clean imported MJML/HTML without per-campaign rework. | 0.6 | No — assumed integration contract; premortem A:4 flags drift risk. |
| 8 | A funded measurement study will actually be run before a build is committed (i.e., org politics won't skip it). | 0.4 | No — Brandt's explicit warning is that "measure first" is the correct and least likely outcome; this is why criterion 2 makes it a funded precondition, not a suggestion. |
| 9 | The Vibe Elements stack will remain stable enough (once pinned/wrapped) to build a canvas against without a forced mid-build rewrite. | 0.6 | No — repo shows active migration churn (Raghavan, A:8); mitigable but unconfirmed. |
| 10 | A genuinely useful, brand-safe authoring tool (Architecture A class) can ship even if it does not move the volume metric. | 0.75 | No — A is "a Tuesday" to build (Raghavan) and Brand-endorsed (Mercier), but its volume contribution is the open question; risk-reduction value is real, volume value is conditional. |
Gate: success criteria defined (decision-gate + outcome, measurable and time-bound), constraint inventory mapped (10 rows across hard/soft/assumed), decision-maker identified via Three Ledgers with owner Peter Barnett, scope boundary and recursion budget set, and a 10-row assumption log recorded → set phaseGates.0-foundation = passed in manifest.json.