Overlap 261 · union 844 · WORKED-not-STARTED 304 · STARTED-not-WORKED 279.

The quarter, month and year columns are derived by the board from ts.planned_start_date — “Add Quarters to the SQL Code… Based on ts.planned_start_date::date”. That is why they answer a third question.

WF = authored in Workfront, CP = authored in Content Pantry. The test is one email address: in tactic_signals, created_by = workfrontfusion@marriott.com means WF; anything else means CP.

S = STARTED, W = WORKED.

End to end (tactic_creation_to_fulfillment_duration) — STARTED: 382 tactics, mean 52.6, median 40.0. WORKED: 538 tactics, mean 70.6, median 56.0.

Note how far the means sit above the medians on intake — a long tail of stalled intakes pulls the average from 36 days up to 129. The median is the more honest headline for every phase here.

The view’s own flags: is_bad_fulfillment_duration 3 (S) / 5 (W); is_bad_activation_duration 2 (S) / 1 (W); tactic_launched 382 (S) / 538 (W).

All eleven *_date columns on signals_all_data_qmy_04092026 are typed text and hold MM/DD/YYYY strings. Consequences:

• where tactic_creation_date >= date '2026-01-01' errors outright — text compared to a date.
• ORDER BY sorts lexically, so 03/01/2026 sorts before 12/01/2025.
• Every filter has to be wrapped: to_date(nullif(col,''),'MM/DD/YYYY').

The undated base revision signals_all_data types those same eleven columns as real dates. This is a change the later revision made, and it is treated as a regression worth reversing.

All six are email and all six travel the TLP Metadata route. Across the whole table the defect reaches -559 days and touches 36 rows on two routes.

Only creative disagrees, which usefully localises the problem: in that one phase the _start_date/_end_date columns and the _duration column are produced by different expressions.

(none) means the view recorded no route and no dates. Tactic Start Date (Fallback) means it recorded a route and dates that are not real signals.

STARTED — tactic_id = 7302

analytical_model.tactic_signals — status planned, created 2026-01-14, last updated 2026-05-05, created_by = workfrontfusion@marriott.com → a WF tactic.

public.darf_tracking — no rows for this tactic, so its targeting and fulfillment dates did not come from the DARF audience-delivery log.

WORKED — tactic_id = 3828

analytical_model.tactic_signals — status planned, created 2025-01-17, last updated 2025-04-29, created_by = workfrontfusion@marriott.com → a WF tactic.

public.darf_tracking — no rows for this tactic, same as above.

Note the shape of this one: created January 2025, creative phase closed January 2026 — 370 days. It is exactly the kind of row that makes WORKED look slower than STARTED, and exactly the kind of row STARTED cannot see.

Constraint first. These are production databases, so the walk was built to be cheap and auditable rather than exhaustive:

• One pooled connection, read-only, with SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY and a 120s statement timeout.
• Both cohorts measured in the same query using FILTER (WHERE ...), so answering the question twice costs almost nothing extra.
• Every query is an aggregate or LIMIT-ed. No row dumps.
• The 206M-row darf_tracking was never scanned. pg_index was read first, a btree on tactic_id found, and the table hit only with an equality lookup for a single traced tactic.
• All cohort work happens inside a 3,703-row materialised view.

Then the sequence.

1. Ask the catalog before the data. pg_index for what is safe to filter on, pg_attribute for column types. That is what surfaced the first finding — every date column is text — before a single analytical query ran.
2. Refuse to accept one definition of the quarter (section 2).
3. Walk the funnel before the averages (section 4 before section 5): a mean over 12 targeting rows means something very different from a mean over 422 fulfillment rows.
4. Let the data volunteer its defects. The negative fulfillment minimum appeared in a routine min/max row; it was not hunted for.
5. Reconcile the view against itself — _duration = _end - _start, per phase. Prompted by an oddity in a traced row, it turned a one-off into a bounded, quantified defect.
6. Trace real tactics down to source, one per cohort, against tactic_signals, signals_workfront_tasks and darf_tracking. This proves the lineage rather than assuming it.

Two corrections the data forced, both worth knowing:

• The first cohort filter compared a text column to a date and errored outright. The bug was the finding: these columns are MM/DD/YYYY strings.
• The first source-trace used task_status on signals_placement_status_updates, copied from the board’s own signal card. The live column is status; task_status exists only on some dated variants. The board’s formula does not run as written against the table it names.

Claim: 7,231 tactics exist; 3,703 rows in the report.

SELECT (SELECT count(*) FROM analytical_model.tactic_signals)              AS tactics,
       (SELECT count(*) FROM public.signals_all_data_qmy_04092026)         AS report_rows,
       (SELECT count(DISTINCT tactic_id) FROM public.signals_all_data_qmy_04092026) AS distinct_tactics;

→ 7231 | 3703 | 3703

The row grain is clean — one row per tactic, no fan-out duplication. The loss is entirely the WHERE clause, which is the last 12 lines of the view definition.

Claim: 151 production tactics dropped by the name filter; 326 by campaign-name filters; push/SMS excluded outright.

The view filters on ts.name NOT ILIKE '%test%' in addition to the explicit is_test flag. Tactics that pass the flag but fail the name test, and follow production naming:

SELECT count(*) AS production_named_but_dropped
FROM analytical_model.tactic_signals
WHERE is_test = false AND name ILIKE '%test%'
  AND (name ~ '^[0-9]{3,}_' OR name ~ '^(ACQ|RET|EMEA|CALA|APAC|MVW)_')
  AND current_status <> 'cancelled'
  AND tactic_type IN ('display media','email');

→ 151 — e.g. ACQ_Q4_LTO_US_Boundless_Chase_Review Res Animation TEST_FAIC_DME

SELECT count(*) AS dropped_by_campaign_name_filters
FROM analytical_model.tactic_signals ts
JOIN analytical_model.campaign_signals cs ON cs.id = ts.campaign_id
WHERE ts.is_test = false AND cs.is_test = false AND ts.current_status <> 'cancelled'
  AND ts.tactic_type IN ('display media','email')
  AND (cs.name ILIKE '%LPA%' OR cs.name ILIKE '%global module%' OR cs.name ILIKE '%100 days%'
       OR cs.name ILIKE '%RETARGETING_MIGRATION%'
       OR (cs.name ILIKE '%decision%' AND cs.name ILIKE '%engine%'));

→ 326

Push/SMS: the view’s predicate is (ts.tactic_type = 'display media' OR ts.tactic_type = 'email'). No push or SMS row can survive it.

Claim: 17 rows complete; 1,249 wholly blank; 1,601 measured / 1,895 substituted / 207 nothing; 36 negative fulfillment durations.

SELECT count(*)                                                                    AS rows,
       count(*) FILTER (WHERE intake_duration IS NOT NULL AND creative_duration IS NOT NULL
                          AND targeting_duration IS NOT NULL AND fulfillment_duration IS NOT NULL) AS all_four,
       count(*) FILTER (WHERE intake_duration IS NULL AND creative_duration IS NULL
                          AND targeting_duration IS NULL AND fulfillment_duration IS NULL)         AS none_at_all,
       count(intake_duration) AS intake, count(creative_duration) AS creative,
       count(targeting_duration) AS targeting, count(fulfillment_duration) AS fulfillment,
       count(*) FILTER (WHERE fulfillment_duration < 0) AS neg_fulfillment,
       count(*) FILTER (WHERE creative_duration    < 0) AS neg_creative
FROM public.signals_all_data_qmy_04092026;

→ 3703 | 17 | 1249 | 1232 | 809 | 454 | 1632 | 36 | 11

So each stage is known for only: intake 33%, creative 22%, targeting 12%, fulfillment 44%.

The measured/substituted split is readable directly off fulfillment_flow — the view’s own label for which evidence it used:

SELECT fulfillment_flow, count(*)
FROM public.signals_all_data_qmy_04092026 GROUP BY 1 ORDER BY 2 DESC;

→ measured 1,601 · substituted 1,895 · nothing 207

Observed-only cohort: WHERE fulfillment_flow IN ('DME','CP Email DARF Enabled','WF Email')

SELECT '04092026' AS v, count(*) n, count(*) FILTER (WHERE tactic_launched) launched,
       round(100.0*count(*) FILTER (WHERE tactic_launched)/count(*),1) pct
FROM public.signals_all_data_qmy_04092026
UNION ALL
SELECT '04162026', count(*), count(*) FILTER (WHERE tactic_launched),
       round(100.0*count(*) FILTER (WHERE tactic_launched)/count(*),1)
FROM public.signals_all_data_qmy_04162026;

→ 04092026 | 3703 | 3424 | 92.5
→ 04162026 | 4031 | 1603 | 39.8

Why this is the whole argument. Compare the observed flow counts across the two: WF Email 917 → 917, DME 568 → 568, CP Email DARF Enabled 118 → 116. The evidence did not move. 04092026 gained its 53 extra percentage points solely by adding the TLP Metadata and Tactic Start Date (Fallback) arms.

tactic_launched is defined in the view as fusi.fulfillment_end_date IS NOT NULL — literally “the ladder produced a date from any arm, observed or imputed.” It is not a launch status.

Claim: the view behind the per-stage duration charts computes a single project-wide span and reuses it for every stage; the whitelist is 124 hand-typed entries; the SMS/Push channel is dead code.

File: database/views/public.signals_no_darf.sql. Lines 182–192 — the join is on project_id alone, with no restriction to the stage’s own tasks:

completion_dates AS (
    SELECT cp.project_id, cp.project_name, cp.project_type, cp.id_campaign,
        min(ct.actual_completion_date) AS first_completion,
        max(ct.actual_completion_date) AS last_completion
    FROM filtered_projects cp
        JOIN signals_workfront_tasks ct ON cp.project_id::text = ct.project_id::text
    WHERE ct.actual_completion_date IS NOT NULL
    GROUP BY cp.project_id, cp.project_name, cp.project_type, cp.id_campaign
),

filtered_projects emits one row per (project_id, project_type). A project classified as both Creative Email and Email Fulfillment therefore yields two rows carrying identical first_completion / last_completion, computed over every task in the project regardless of type. Creative, Targeting and Fulfillment all report the same number.

Two further defects in the same file:

• Lines 206–208 — WHEN project_type ILIKE '%Email%' … WHEN ILIKE '%Push%' … WHEN ILIKE '%SMS/Push%'. 'SMS/Push Fulfillment' contains Push, so arm 2 always wins and the SMS/Push channel never appears.
• The final SELECT joins a campaign-grain row to analytical_model.tactic on id_campaign, so each project duration is averaged once per tactic in its campaign — weighting every project by how many tactics its campaign happens to hold.

grep -o "'%[^']*%'::text" database/views/public.signals_no_darf.sql | sort -u | wc -l

→ 124

SELECT 'tactic_signals' t, max(created_dt)::date mx, count(*) n FROM analytical_model.tactic_signals
UNION ALL SELECT 'campaign_signals', max(created_dt)::date, count(*) FROM analytical_model.campaign_signals
UNION ALL SELECT 'signals_workfront_tasks', max(entry_date)::date, count(*) FROM public.signals_workfront_tasks
UNION ALL SELECT 'spsu (live)', max(entry_date)::date, count(*) FROM public.signals_placement_status_updates
UNION ALL SELECT 'spsu_04062026 (used)', max(entry_date)::date, count(*) FROM public.signals_placement_status_updates_04062026
UNION ALL SELECT 'v8_darf_files (live)', max(file_name_date)::date, count(*) FROM public.v8_darf_files
ORDER BY 1;

campaign_signals        | 2026-08-25 |   4493
spsu (live)             | 2026-08-26 | 118175
spsu_04062026 (used)    | 2026-04-06 |  85657
signals_workfront_tasks | 2026-08-25 | 343527
tactic_signals          | 2026-05-19 |   7231
v8_darf_files (live)    | 2026-08-25 |   3586

SELECT max(file_name_date) FROM public.darf_tracking;   -- → 2026-05-16 23:22:33

Why nothing self-corrects: heavy_processes contains zero triggers. Every load is driven from outside — a Databricks job, the manual upload, or a hand-typed REFRESH MATERIALIZED VIEW. If a job stops, no alert fires.

SELECT count(*) AS rows_after_cutoff,
       count(DISTINCT tactic_id) AS tactics_after_cutoff,
       count(DISTINCT tactic_id) FILTER (WHERE status IN ('LRY','LCD')) AS tactics_launched_after_cutoff
FROM public.signals_placement_status_updates
WHERE entry_date > DATE '2026-04-06';

→ 36896 | 668 | 467

(LRY / LCD are the live table’s status codes for DME Launch Ready / DME Launched — the dated snapshots spell them out as names in a task_status column instead. The two families are not interchangeable; see database/BOARD_VS_LIVE.md §1.)

SELECT count(*) FROM analytical_model.campaign_signals WHERE created_dt > DATE '2026-05-19';

→ 149

SELECT c.relname, s.n_live_tup AS rows
FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace
LEFT JOIN pg_stat_user_tables s ON s.relid = c.oid
WHERE n.nspname = 'public' AND c.relname LIKE 'signals_all_data%'
ORDER BY c.relname;

Populations range 3,385–4,245 and are not nested — each contains tactics the others lack.

..._04162026 and ..._0416026_2 carry later dates but older SQL bodies (they lack the TLP and fallback arms and use the superseded platform test) — someone re-ran an earlier board panel on a later day. Sorting by name gives the wrong table.

Two more traps worth knowing before anyone writes a filter:

• ..._04162026 has no quarter / month / year columns at all — a report using them errors rather than returning a wrong number.
• signals_all_data_v2 computes identically-named quarter/month/year from fulfillment_end_date instead of planned_start_dt. Same names, opposite meaning.

And the key structural fact: the only revision reading the live DARF path (signals_all_data_automated_refresh) has none of the imputation arms, none of the campaign-name exclusions, and a different DME status vocabulary. There is no revision that is both most-evolved and current.

Both charts are pasted images on board 02, transcribed in diagrams/extraction/00_image_only_components.md (items B8 and B9) — “ACTIVATION DURATION (in Days, by Tactic In-Market Date)”:

Three compounding causes, all documented:

1. Different objects. database/board_sql/activation_avg_tactic_start_old_data.sql reads public.signals_all_data (3,385 rows); activation_avg_fulfillment_end_new_data.sql reads public.signals_all_data_qmy_03032026 (3,724 rows).
2. Different filters. The “new data” query excludes the fallback rows (AND fulfillment_flow <> 'Tactic Start Date (Fallback)'); the “old data” query has no such filter. Note that predicate is also NULL-rejecting, so it silently drops every NULL-flow row too — more than the analyst intended.
3. Different metric definition. Michael Alton’s own conclusion on the board:

   “The drastic change in 2024 numbers is almost entirely due to the switch from tactic start date to fulfillment end date.”
   “I believe someone deleted their placement tasks since those tactics still show up but not in our placement status reports anymore.”
   “Hence, the activation duration is ‘short’ for DME in 2024 since the cutoff has this inherent bias.”

Related, in database/board_sql/duration_fulfillment_average_280day_cut.sql: a WHERE "Campaign Days to Complete Project" < 280 cut applied to Fulfillment only, per the board rule “fulfillments taking more than 280 days are treated as human error.” Removing the upper tail from one stage and not the others biases every comparison downward.

The two arms sit in different CASE ladders in the same view and are gated on different columns:

-- fulfillment_end_date, arm 5   (the VALUE)
WHEN ts_1.planned_end_dt::date   < now()::date THEN ts_1.planned_end_dt::date

-- fulfillment_flow, arm 5       (the LABEL)
WHEN ts_1.planned_start_dt::date < now()::date
     AND ts_1.planned_start_dt::date IS NOT NULL THEN 'Tactic Start Date (Fallback)'

SELECT count(*) AS labelled_fallback,
  count(*) FILTER (WHERE to_date(nullif(r.fulfillment_end_date,''),'MM/DD/YYYY') = ts.planned_end_dt::date)   AS end_eq_planned_end,
  count(*) FILTER (WHERE to_date(nullif(r.fulfillment_end_date,''),'MM/DD/YYYY') = ts.planned_start_dt::date) AS end_eq_planned_start,
  count(*) FILTER (WHERE r.fulfillment_end_date IS NULL) AS label_but_no_date
FROM public.signals_all_data_qmy_04092026 r
JOIN analytical_model.tactic_signals ts ON ts.id = r.tactic_id
WHERE r.fulfillment_flow = 'Tactic Start Date (Fallback)';

→ 1245 | 1172 | 383 | 72

The 72 are rows where planned start is past but planned end is still future: the label arm fires, the value arm doesn’t. Consequence: never count launches with fulfillment_flow IS NOT NULL — it over-counts by exactly 72. Use tactic_launched.

This swap appears in no board panel — the direct ancestor ..._qmy_04062026 uses planned_start_dt in both places. It was made straight against the database.

SELECT count(*) FILTER (WHERE is_bad_fulfillment_duration = false) AS flagged_good,
       count(*) FILTER (WHERE is_bad_fulfillment_duration = false
                          AND fulfillment_duration IS NULL)        AS good_but_unmeasurable
FROM public.signals_all_data_qmy_04092026;

→ 3667 | 2071

The flag is CASE WHEN (end - start) < 0 THEN true ELSE false END. NULL < 0 is NULL, so every unmeasurable row falls to ELSE → false. WHERE NOT is_bad_fulfillment_duration returns 3,667 rows of which 2,071 (56%) have nothing to measure.

SELECT count(*) total,
       count(*) FILTER (WHERE task_type IS NULL) null_task_type,
       round(100.0*count(*) FILTER (WHERE task_type IS NULL)/count(*),1) pct_task_type,
       count(*) FILTER (WHERE tactic_id IS NULL) null_tactic_id,
       round(100.0*count(*) FILTER (WHERE tactic_id IS NULL)/count(*),1) pct_tactic_id
FROM public.signals_workfront_tasks;

→ 343527 | 269998 | 78.6 | 269365 | 78.4

Every stage signal in the report keys on task_type IN ('Creative Intake','Content','Targeting Intake','Targeting Production File'), so it only ever sees the classified 21%. Team’s note: “Not Automated: Any null values likely imply tactic is new and has not been mapped yet” — i.e. the newest work is the most likely to be unclassified, and therefore the most likely to be imputed.

WITH r AS (
  SELECT tactic_id FROM public.signals_all_data_qmy_04092026
  WHERE fulfillment_flow IN ('TLP Metadata','Tactic Start Date (Fallback)')
     OR fulfillment_flow IS NULL),
w AS (SELECT tactic_id FROM public.signals_workfront_tasks GROUP BY tactic_id),
live AS (SELECT DISTINCT tactic_id::int tid FROM public.signals_placement_status_updates
         WHERE status IN ('LRY','LCD') AND tactic_id IS NOT NULL),
p AS (SELECT DISTINCT tactic_id tid FROM public.v8_darf_tracking_v2 WHERE status = 'P')
SELECT count(*) AS guessed_or_blank,
  count(*) FILTER (WHERE live.tid IS NOT NULL OR p.tid IS NOT NULL)            AS recoverable_from_live_feeds,
  count(*) FILTER (WHERE live.tid IS NULL AND p.tid IS NULL AND w.tactic_id IS NOT NULL) AS partial_wf_trace_only,
  count(*) FILTER (WHERE live.tid IS NULL AND p.tid IS NULL AND w.tactic_id IS NULL)     AS no_trace_anywhere
FROM r LEFT JOIN w ON w.tactic_id = r.tactic_id
       LEFT JOIN live ON live.tid = r.tactic_id
       LEFT JOIN p ON p.tid = r.tactic_id;

→ 2102 | 216 | 1181 | 705

This is the single most important query in the appendix. It is the evidence for the claim that this is not purely a SQL problem: 705 rows (19% of the whole report) have no launch evidence in any table — no placement record, no DARF file, no Workfront task. Re-pointing, re-joining and re-writing the SQL cannot produce a date for them.

The middle bucket (1,181) is the one worth funding: the trace exists in signals_workfront_tasks, but no rule maps its task types to “finished.”

WITH r AS (
  SELECT tactic_id, quarter, year,
    to_date(nullif(tactic_creation_date,''),'MM/DD/YYYY') AS created,
    to_date(nullif(intake_end_date,''),'MM/DD/YYYY')      AS a,
    to_date(nullif(creative_end_date,''),'MM/DD/YYYY')    AS b,
    to_date(nullif(targeting_end_date,''),'MM/DD/YYYY')   AS c,
    to_date(nullif(fulfillment_end_date,''),'MM/DD/YYYY') AS d
  FROM public.signals_all_data_qmy_04092026)
SELECT count(*) FILTER (WHERE quarter = 1 AND year = 2026)                                   AS planned_q1,
       count(*) FILTER (WHERE created >= DATE '2026-01-01' AND created < DATE '2026-04-01')  AS created_q1,
       count(*) FILTER (WHERE a >= DATE '2026-01-01' AND a < DATE '2026-04-01'
                           OR b >= DATE '2026-01-01' AND b < DATE '2026-04-01'
                           OR c >= DATE '2026-01-01' AND c < DATE '2026-04-01'
                           OR d >= DATE '2026-01-01' AND d < DATE '2026-04-01')               AS worked_q1,
       count(*) FILTER (WHERE quarter = 1 AND year = 2026
                          AND created >= DATE '2026-01-01' AND created < DATE '2026-04-01')   AS planned_and_created
FROM r;

→ 480 | 540 | 565 | 240

quarter/month/year derive from ts.planned_start_dt — when the tactic is planned to go to market. A campaign planned for March is often created the previous October. So the quarter column is a forecast, and a report filtered on it answers a planning question, not a delivery one.

Two edges: EXTRACT returns numeric, so year = 2026 works and year = '2026' does not; and the text-date columns sort lexically, so WHERE fulfillment_end_date >= '2026-01-01' compares '01/22/2026' >= '2026-01-01' → false for every row, silently.

File: database/board_sql/placement_status_etl.py (transcribed from board 02).

Line 54–55 — the comment and the regex disagree:

# Extract first 4-digit number at the start
match = re.search(r"\b(\d{4})\b", parent)

re.search with no anchor takes the first 4-digit run anywhere in the parent task name. A parent named "Q1 2026 Destination Tiles" yields tactic_id = 2026, and 2026 is a real tactic:

SELECT id, name, tactic_type FROM analytical_model.tactic_signals WHERE id IN (2024,2025,2026);

→ 2026 | PREARRIVAL_RENAISSANCE_HOTELS-COPY | email

So placement events can be silently attributed to the wrong tactic.

Line 96 — if_exists="replace" drops and rebuilds the whole table each run, which is why a placement task deleted in Workfront disappears from reporting with no trace.

Two more in the same file: pd.to_datetime(..., errors="coerce") turns an unparseable date into NULL — “no signal” rather than an error; and float(...) on the id is why the view joins spsu.tactic_id = ts_1.id::double precision, i.e. identifier equality through floating point.

Every name in the Option 2 table is drawn from the team’s own board notes, not inferred: