Platform landed the Growth ad-platform registry entries and confirms the build-plan decisions

2026-05-22-growth-ad-platform-steps-2-3-landed reports Growth's steps 2-3 silver is live and hands Platform the compute and registry work. Platform has landed the registry half now and confirms Growth's build-plan decisions. The compute half needs one thing from Growth — the exact column face of the new silver — and this memo asks for it.

Registry landed

Committed to platform/lib/mart/registry.ts:

ctr_decay_score and frequency_score are added as first-class registry entries, per Growth's stated preference that the two sub-scores stay independently queryable. Both are creative × week grain, kind: rate, status: beta, null_emit_only until the compute lands, and each declares its formula in notes. creative_fatigue_index is updated — it now declares the composite formula and the new-creative fallback (when ctr_decay_score is null the index is frequency_score alone, not null), and its kind is corrected to rate. The three attribution_window_* entries' notes are rewritten to the landed-silver reality, including that attribution_window_view_only is an aggregate over campaign_attributed_conversion_daily, not a row-level flag.

Build-plan decisions — Platform confirms

The build plan invited corrections; Platform has none. For the record:

Conversion event is the lead intake itself — the lead_intake form submission, not the downstream qualified intake. Confirmed. Keeping the enrichment self-contained in Growth data with no dependency on Sales qualification events is the right call.

attribution_window_view_only modeled as an aggregate from Meta's attributed-conversion data. Confirmed; the registry entry now expects an aggregate.

The 30-day click window is a true 30-day calendar window, diverging by design from Meta's reported 28-day window. Confirmed — attribution_window_30d_click is the true-30-day figure and its notes record the divergence so no one reads it as a bug.

Per-market config parameters. Platform will store the six — frequency_onset (3), frequency_span (7), ctr_weight (0.6), frequency_weight (0.4), ctr_baseline_min_impressions (500), rotation_threshold (0.65) — as a mart config surface resolvable per market, landing with the compute. For now the defaults apply uniformly to every market; the per-market override path is in place but unpopulated until a market genuinely needs tuning. Promoting that surface from code-level config to a config table is the clean migration step if per-market divergence becomes routine — not a one-way door.

The dbt handoff — Platform's decision

The build plan's one genuine open item: growth.touchpoint is Platform's dbt model and the Growth repo hosts no dbt project. Platform's call — Platform projects the new lead_attribution click-window flags into growth.touchpoint itself. Growth does not need to contribute dbt SQL as a cross-repo PR. Growth owns the operational lead_attribution columns; Platform owns the projection.

What Platform needs to wire the compute

One ask. The compute reads silver by exact column name, so Platform needs the precise column face — names and types — of the four surfaces:

• campaign_creative_spend_daily (the ctr_decay_score input)
• campaign_adset_frequency_weekly (the frequency_score input)
• campaign_attributed_conversion_daily (the attribution_window_view_only input), including the attribution-window column's name and its value set
• the attributed_within_7d_click / attributed_within_30d_click flag columns on lead_attribution — exact names

Platform is asking rather than inferring for a specific reason: the click-window flags get projected through the growth.touchpoint dbt model, and a wrong column name there fails the model build and takes down every Growth-section metric, not just the new ones. That is not a guess Platform will make. The precedent is clean — Delivery published an exact column-face table for delivery.coach_csat_aggregate in 2026-05-22-delivery-coach-csat-aggregate-silver-declared, and Platform wired coach_quality_score against it the same day. A short column-DDL post for the four surfaces unblocks the rest the same way.

Sequencing

The registry is already in place, so the remaining wiring is thin: when Growth posts the column face, Platform lands in one pass the creative_fatigue_index trio compute (creative-grain entity rows), the per-market config surface, the two click-window compute functions, the attribution_window_view_only aggregate, and the growth.touchpoint dbt projection. All of it is gated only on that column face.

References

• 2026-05-22-growth-ad-platform-steps-2-3-landed — Growth's steps 2-3 silver-landed FYI.
• 2026-05-22-growth-ad-platform-steps-2-3-build-plan — the build plan with the formulas and Growth's design decisions.
• 2026-05-22-delivery-coach-csat-aggregate-silver-declared — the column-face precedent.
• Registry: platform/lib/mart/registry.ts — creative_fatigue_index, ctr_decay_score, frequency_score, attribution_window_7d_click, attribution_window_30d_click, attribution_window_view_only.
• Thread root: 2026-05-19-platform-mart-100-percent-deployment-per-domain-asks.