MI Signals: lineage and analysis

01Where the 7,231 → 3,594 drop goes

Question 1

Which numbers these are

These figures are not from the stored report table. They come from the board’s V11 SQL run by hand on 21 September 2026 against the tables as they stand today.

The report itself is the materialised view public.signals_all_data_qmy_04092026, last refreshed around 15 April 2026 and holding 3,703 rows. Re-running the same logic today gives 3,594. Both are “the report”; they are five months apart.

The step-by-step breakdown below adds up exactly to the manual run: 7,231 in, 3,594 out. Each tactic is counted once, under the first rule that removes it.

3,594 kept 2,606 519 209 303

In the report: 3,594
Removed, clearly valid: 2,606
Valid rule, 302 need checking: 519
Not reliable: 209
No reason on record: 303

The waterfall: 7,231 down to 3,594, step by step

Step	Reason	Change	Running total	Valid?	Why I think so
Start	Every tactic in the system		7,231
1	Channel is not email or display media (sms 312, push 16, paid search 6, social 4)	− 338	6,893	Valid scope choice	Board: “V1 Scope: SMS and Push can be ignored.” Deliberate. Confirm it still stands.
2	Tactic status is `cancelled`	− 1,402	5,491	Valid	Cancelled work never went to market. No board note gives the reason, but it makes sense.
3	Tactic flagged `is_test`	− 666	4,825	Valid	This is the official test flag.
4	Campaign flagged `is_test`	− 519	4,306	Mostly valid 302 need checking	Right rule, but the flag changed over the summer on in-market campaigns. 302 tactics that were in the April report are gone today for this reason alone.
5	Tactic or campaign name contains “delete”	− 155	4,151	Valid	The team’s naming convention for records that are no longer needed.
6	Tactic name contains “test”, but the flag says it is not a test	− 209	3,942	Not reliable review	Catches junk (`test`, `GMTest 101`) and real A/B creative variants like `ACQ_Q2_US_0513 Boundless_Chase_TEST_Arrow_125K + 1FN_Non-Res_FAIC_DME`. At least 58 follow production naming.
7	Campaign name contains “test”, but the flag says not	− 45	3,897	Probably valid	Names like `Jenn Test`, `BETA Testing JKH`. The flag was just never set. This is better fixed in the source system.
8	Campaign name contains `RETARGETING_MIGRATION`	− 140	3,757	To confirm with Marcus/Amanda	Board says only “Exclude campaign name RETARGETING_MIGRATION (103)”. No reason given. It is probably a one-off data migration rather than marketing work.
9	Campaign name contains `LPA`	− 55	3,702	To confirm with Marcus/Amanda	No reason on the board. Names look like system records (`PRD_LPA_LINKIDS`, `STG_PREARRIVAL_AKA_LPA`).
10	Campaign name contains “decision” and “engine”	− 33	3,669	To confirm with Marcus/Amanda	No reason on the board. Looks like a programme that runs all the time (`Decision Engine 2.0 - Ongoing`).
11	Campaign name contains `global module`	− 4	3,665	To confirm with Marcus/Amanda	No reason on the board. One campaign: `Global Module Syndication`.
12	Campaign name contains `100 days`	− 71	3,594	To confirm with Marcus/Amanda	No reason on the board. Mostly `100 Days Content - Ongoing`; one looks like a normal tactic (`Q2_2025_F100 Days_DME_App`).
End	What the logic returns today		3,594

measured. One aggregate query over analytical_model.tactic_signals left-joined to analytical_model.campaign_signals, each tactic assigned to the first failing rule.

Totals by verdict

Verdict	Tactics	Share of the 3,637 removed
Valid steps 1, 2, 3, 5, 7	2,606	72%
Valid rule but 302 of the 519 need checking (step 4)	519	14%
Not reliable step 6	209	6%
To confirm with Marcus/Amanda steps 8–12	303	8%

The only guidance the board gives for steps 8–12 as a group is a sticky about marking tactics “with custom workflow so we exclude them”. For step 6 the board itself asked for a change: “Add this to be the test check mark instead of just the name.”

So, is the drop legitimate? For about 85% of it, yes: 3,080 rows are removed in steps 1–5 for clear reasons we can defend. The other 557 rows are removed in steps 6–12 only because of words in their names.

02Stage definitions: agreed vs what the query does

Question 2

Every tactic is supposed to pass through four stages: Intake → Creative → Targeting → Fulfillment, each with a start and an end date. For every one of those columns the tables below give the source, what the team agreed, what the query actually does, and whether they match.

Conditions that apply to every column

These are not repeated in each row, but they affect every date:

1. The row must survive the exclusion filters in section 1.
2. Only labelled Workfront tasks count. About 78% of the 361,190 rows in signals_workfront_tasks have no task_type and are invisible to the report. Caveat: Workfront carries all of Marriott’s project work, so much of that 78% is probably unrelated to these campaigns. Treat it as the most that could be missing, not the amount that is. We don’t yet know how much of the unlabelled work is actually tactic work.
3. The platform lookup routes the tactic. A WF tactic can never use DARF dates; a CP tactic can never use Workfront deployment tasks.
4. Some sources are frozen copies. Display placements come from a snapshot taken 6 April 2026; DARF files stop 16 May 2026. Anything after those dates cannot produce a real date.
5. A duration can only be worked out when both its start and end dates exist. If either date is missing, the duration is blank.

Words used below

Word	Meaning
Campaign	A marketing programme, e.g. `Boutiques_Shops`. Contains many tactics.
Tactic	One deliverable a customer sees: one email or one display banner. One row in the report.
Workfront (WF)	The project-management tool. Work is tracked as tasks; a task has a date it was entered and a date it was completed.
Content Pantry (CP)	Marriott’s campaign-building tool. Holds the official list of campaigns and tactics.
DARF file	A delivery file showing an audience was sent. `T` = audience ready (targeting done). `P` = processed for sending (fulfillment done). Only for emails built in Content Pantry.
Display media (DME)	Banner/tile placements on Marriott’s site and app, tracked as placement tasks ending at “DME Launched”.
Platform	A lookup (`signals_tactic_cp_wf.platform`) labelling each tactic `CP` or `WF`. It decides which rule applies. Display is always `WF`.

schema.table_name database table
column_name column in that table
Value the value it is filtered to
1 tried in this order until one returns a date

Freshness marks below: fresh · stale or frozen · cannot tell. Numbers in the last column are for the downloaded April table (3,703 rows); the pattern is the same in the manual run and both were checked. Tables scroll sideways; the column name stays pinned.

Stage 1: Intake the request for the work comes in and is accepted

Column	Source table	How fresh	In plain words	What the team agreed	What the report actually does	Exact conditions	Do they match?
intake_start_date	analytical_model.campaign_signals created_dt	Fresh. Newest campaign created 16 Sep 2026; last edit 18 Sep 2026.	The day the campaign was first set up.	“Campaign Creation”	Uses the day the campaign record was created.	Rule: `cs.created_dt::date` Indirect: joined by `cs.id = ts.campaign_id`. It is a campaign date, so every tactic in the campaign gets the same one, even tactics added a year later.	Matches the board But misleading per tactic see next row.
intake_end_date	public.signals_workfront_tasks actual_completion_date rows where task_type = Creative Intake	Table loads daily (latest task entered 20 Sep 2026). Only 244 rows carry this label: newest completed 10 Sep 2026.	The day the creative request for the campaign was signed off.	“Creative Intake Task Complete”	Takes the most recent sign-off of any “Creative Intake” task anywhere in the campaign.	Rule: `max(actual_completion_date) WHERE task_type = 'Creative Intake' GROUP BY campaign_id` Indirect: matched on `campaign_id`, not `tactic_id`. Rule 2 applies. The date moves later whenever a new intake task completes in that campaign.	Same signal, wrong level Evidence: every tactic in a campaign shares one intake end (0 of 618 campaigns differ). *876 of 1,232 tactics were created after* their own intake “ended”.**
intake_duration	analytical_model.campaign_signals and public.signals_workfront_tasks	Both fresh (see the two rows above).	How many days intake took.	End minus start.	End minus start.	`intake_end_date − intake_start_date`	Campaign number on a tactic row Correct arithmetic on a campaign-level span.

Stage 2: Creative the content is written and designed

Column	Source table	How fresh	In plain words	What the team agreed	What the report actually does	Exact conditions	Do they match?
creative_start_date	Workfront emailspublic.signals_workfront_tasks rows where task_type = Creative Intake Everything elsepublic.signals_workfront_tasks entry_date rows where task_type = Content Routingpublic.signals_tactic_cp_wf	Fresh. Newest `Content` task created 18 Sep 2026. Routing: no date column. Holds tactic IDs up to 10,485 while the tactic list stops at 8,669, so it is still being loaded.	The day work on the content began.	In general: “Content Task Entered”. For Workfront emails: “creative starts at the creative intake task being completed”	For Workfront emails: shows the intake end date. For everything else: the day the first “Content” task was created.	Rule (WF email): `WHEN tactic_type = 'email' AND platform = 'WF' THEN` intake end date Rule (others): `min(entry_date) WHERE task_type = 'Content' GROUP BY tactic_id` Indirect: rules 2 and 3.	Displayed date follows the board, but see `creative_duration`.
creative_end_date	public.signals_workfront_tasks actual_completion_date rows where task_type = Content	Fresh. Newest `Content` task completed 18 Sep 2026.	The day the last piece of content was finished.	“Content Task Completed” / “last content submissino task”	The latest completion date of any “Content” task for the tactic.	Rule: `max(actual_completion_date) WHERE task_type = 'Content' GROUP BY tactic_id` Indirect: rule 2.	Matches
creative_duration	public.signals_workfront_tasks entry_date and actual_completion_date rows where task_type = Content only	Fresh (18 Sep 2026).	How many days creative took.	End minus start.	End minus the first Content task date, for every tactic, including Workfront emails.	`creative_end_date − min(entry_date of Content tasks)` Indirect: ignores the special Workfront-email start shown in `creative_start_date`.	No For Workfront emails the duration is not the gap between the two dates shown on the row. Evidence: 214 of 220 Workfront-email rows with a creative duration. 0 of 589 other rows.

Stage 3: Targeting the audience who will receive it is chosen and delivered

Column	Source table	How fresh	In plain words	What the team agreed	What the report actually does	Exact conditions	Do they match?
targeting_start_date	Content Pantry tacticsanalytical_model.tactic_signals created_dt Everything elsepublic.signals_workfront_tasks entry_date rows where task_type = Targeting Intake Routingpublic.signals_tactic_cp_wf	Frozen. No new or edited row since 19 May 2026. Labelling stopped: last `Targeting Intake` task created 10 Mar 2026 (678 rows). Routing: no date column.	The day work on choosing the audience began.	Workfront: “beginning of targeting is essentially tactic creation.” Content Pantry: “For CP, start of targetting for now.” (tactic creation) Display: “Do we have this?” Other email: “will be hard.”	Content Pantry tactics: the day the tactic was created. All others: the day the first “Targeting Intake” task was created.	Source (CP): `tactic_signals` → `min(created_dt)` when `platform = 'CP'` Source (others): `signals_workfront_tasks` → `min(entry_date) WHERE task_type = 'Targeting Intake'` Indirect: rules 2 and 3.	In practice, yes The task is created the same day as the tactic: 551 of 570 Workfront rows equal the tactic creation date; 186 of 186 CP rows do. But a stand-in the board says there is no real “targeting began” signal.
targeting_end_date	1public.darf_tracking where status = T 2analytical_model.tactic_signals current_status update_dt 3public.signals_workfront_tasks entry_date rows where task_type = Targeting Production File 4Routingpublic.signals_tactic_cp_wf	1. Stale. Latest file 16 May 2026. 2. Frozen since 19 May 2026. 3. Labelling stopped: last `Targeting Production File` task created 6 Jun 2025 (396 rows). Routing: no date column.	The day the audience was ready.	Content Pantry with DARF: first file marked `T`. Content Pantry without DARF: “In market status is end of targetting.” Wanted, not built: “ACC should send us an audience count after it is processed . This is the end of Targeting”	Tried in this order: 1. If a `T` file exists → earliest DARF file date. 2. Else, if CP and “in market” → the day the tactic record was last edited. 3. Else → the day the first “Targeting Production File” task was created.	1. `darf_tracking`: `WHEN count() FILTER (WHERE status = 'T') > 0 THEN min(file_name_date)`. Note that the date picked is not limited to `T` files 2. `tactic_signals`: `WHEN platform = 'CP' AND current_status = 'in_market' THEN min(update_dt)` 3. `signals_workfront_tasks`: `min(entry_date) WHERE task_type = 'Targeting Production File'` Indirect:* rules 2, 3, 4.	No *Option 3 measures when the task was created, not when it was finished.* Both targeting tasks are usually created the same day, so the stage looks instant. Evidence: targeting lasts 0 days on 362 of 454 rows (80%). Option 2 almost never applies: only 3 of 1,027 CP tactics are “in market”.
targeting_flow	Same four tables as the two rows above.	Every targeting source is stale.	A label saying which of the rules above was used.	not defined	`CP DARF Enabled`, `CP Non-DARF Enabled`, or `WF Email`. Blank if no complete pair of dates.	Same conditions as above; the label only appears when both a start and an end exist.	Thin 756 rows have a start, 488 have an end, only 454 have both (12% of the report). `CP Non-DARF Enabled` never appears.

Stage 4: Fulfillment the tactic is built, scheduled and goes live

Column	Source table	How fresh	In plain words	What the team agreed	What the report actually does	Exact conditions	Do they match?
fulfillment_start_date	Displaypublic.signals_placement_status_updates_04062026 entry_date Workfront emailpublic.signals_workfront_tasks entry_date rows where task_type = Content Content Pantry emailpublic.darf_tracking file_name_date Routingpublic.signals_tactic_cp_wf	Display: Frozen snapshot, loaded by hand. Ends 6 Apr 2026. WF email: Fresh (18 Sep 2026). CP email: Stale. Latest file 16 May 2026.	The day building/scheduling the tactic began.	Display: “first status change of placement task per tactic” Workfront email: “Fulfillment start for WF email is first content task completed.” CP email: first DARF file for the tactic	Display: first placement status change. Workfront email: the day the first Content task was created. CP email: first DARF file of any kind.	Display: `min(entry_date) WHERE tactic_type = 'display media'` WF email: `min(entry_date) WHERE task_type = 'Content'` when `platform = 'WF'` CP email: `min(file_name_date)` when `platform <> 'WF'` Indirect: rules 2, 3, 4. Display join is `spsu.tactic_id = ts.id` through a decimal number.	Display matches Workfront email does not it uses task created where the board says task completed, so fulfillment “starts” when creative starts, and the stages overlap. Evidence: fulfillment starts before creative ends on 201 of 533 rows with real dates.
fulfillment_end_date	1public.signals_placement_status_updates_04062026 entry_date task_status 2public.darf_tracking where status = P 3public.signals_wf_email_fulfillment_tasks_2 (stored) public.signals_wf_email_fulfillment_tasks (board SQL) 4analytical_model.campaign_tactic_metadata Tactic_Start_Date 5analytical_model.tactic_signals planned_start_dt planned_end_dt	1. Frozen snapshot, by hand. Ends 6 Apr 2026. 2. Stale. Latest file 16 May 2026. 3. `_2`: one-off export, latest completion 14 Apr 2026; original: 21 Oct 2025. 4. No load date. 5. Frozen since 19 May 2026.	The launch date: the day the tactic went live. The most important date in the report.	Display: “Fulfillment End (DME) will be at DME Launched per tactic” Workfront email: “last completion of a schedule for deployment task.” CP email: last DARF file marked `P`	Tried in this order. First three are real evidence. Last two are planned dates. 1. Display: last time a placement hit “DME Launch Ready” or “DME Launched”. 2. CP email: last `P` file. 3. WF email: last “Schedule for Deployment” task completed. 4. Email only: the planned start date from a Content Pantry planning table. 5. Anything left: the tactic’s own planned date, if it is in the past.	1. `max(entry_date) WHERE task_status IN ('DME Launch Ready','DME Launched')` 2. `max(file_name_date) WHERE status = 'P' AND platform <> 'WF'` 3. `max("Actual Completion Date") WHERE platform = 'WF'` 4. `max("Tactic_Start_Date")` 5. `planned_end_dt` if `< now()` (stored table) or `planned_start_dt` if `< now()` (board SQL) Indirect: rules 2, 3, 4. Option 5 depends on the date the report is refreshed, so it fills more rows at every refresh without any new evidence.	Options 1–3 match the board Accepting “Launch Ready” changes nothing: all 589 launched display tactics reached “DME Launched”. Real launch dates can be overwritten by a planned date The report takes the latest date across all five options, not the first that applies. Evidence: for Content Pantry emails the reported launch date is later than the last `P` file on 14 of 35 rows (by 1–7 days). Display (546 of 547) and WF email (689 of 689) are unaffected. Options 4–5 are plans, not launches this is the borrowed 51% (April table) / 64% (manual run). The board itself asks: “Is this the correct fulfillment end? A lot of tactic skip over RDP and LRY it seems.”
fulfillment_flow	Same tables as fulfillment_end_date.	Every real-evidence source is stale.	A label saying which of the five options gave the launch date.	not defined	`DME`, `CP Email DARF Enabled`, `WF Email` = real. `TLP Metadata`, `Tactic Start Date (Fallback)` = planned.	Same conditions as above. In the stored table the label for option 5 checks `planned_start_dt` while the date uses `planned_end_dt`.	The label is the only way to tell real from planned In the stored table 72 rows carry the fallback label with no date, and only 384 of 1,245 fallback dates are actually the planned start.
fulfillment_duration	Same tables as the two rows above.	Same as those two rows.	How many days fulfillment took.	End minus start.	End minus start.	`fulfillment_end_date − fulfillment_start_date`	Only meaningful when the end is real (options 1–3).

Columns built on top of the stages

Column	Source table	How fresh	In plain words	What the team agreed	What the report actually does	Exact conditions	Do they match?
tactic_launched	Same tables as fulfillment_end_date.	Every real-evidence source is stale.	Did this tactic go live? Yes/no.	Nothing. The boards’ fifth stage (Deployment / In-Market) is an empty box.	“Yes” whenever a launch date exists, including planned dates.	`fulfillment_end_date IS NOT NULL`	Not a launch status It reads “launched” on 92% of rows in the April table and 99.8% in the manual run, including tactics planned for the future.
tactic_creation_to_fulfillment_duration	analytical_model.tactic_signals created_dt plus the tables behind fulfillment_end_date.	Frozen since 19 May 2026; launch-date sources stale.	Days from creating the tactic to going live, the headline “time to market”.	not defined	Launch date minus tactic creation date.	`fulfillment_end_date − ts.created_dt::date`	Inherits the launch-date problem over half are “days until the planned date”.
quarter, month, year	analytical_model.tactic_signals planned_start_dt	Frozen since 19 May 2026.	Which period the tactic belongs to.	Not defined.	The quarter/month/year of the planned start date.	`EXTRACT(… FROM ts.planned_start_dt)`	A forecast, not an outcome Confirmed on 3,703 of 3,703 rows. It says when a tactic was scheduled, not when anything happened.
is_bad_fulfillment_duration	Same tables as fulfillment_start_date and fulfillment_end_date.	Same as those two rows.	A warning flag for impossible numbers.	“If the sequence doesn’t make sense it is bad data and needs to be filtered out”	Flags a row only when the duration is negative. A blank duration is marked “fine”.	`CASE WHEN (end − start) < 0 THEN true ELSE false END`	Misses the common failure 3,667 rows are marked “fine”; 2,071 of them have no duration at all.

Stage by stage, in one line each

Stage	Verdict
Intake	Right signal, wrong level. It is a campaign measurement copied onto every tactic.
Creative	Closest to agreed. One real defect: the Workfront-email duration does not match the dates shown.
Targeting	No agreed definition, and the numbers are not meaningful: 80% of measured rows show 0 days, because the report compares two task-creation dates. Filled on only 12% of rows.
Fulfillment	The three real launch signals match what was agreed. The two planned-date fallbacks do not, and they supply more than half the launch dates. Start dates overlap with Creative.

inferred from the evidence above. What the board admits is not defined at all: targeting start for display and for non-Content-Pantry email, targeting end in general (“we don’t have them all yet”), fulfillment for Content Pantry tactics without DARF, and any deployment / in-market stage.

03Source tables and how fresh they are

Nine source tables feed the report. Row counts and latest dates were measured 2026-09-21 against the live database.

fresh · stale or frozen · cannot tell, meaning the table has no date to check.

Used by every stage

Table	What it provides	Freshness
analytical_model.tactic_signals	The master list of tactics, one row each: name, type, status, test flag, created date, planned start and end. The report starts from this table: a tactic missing here cannot appear at all.	Frozen. 7,231 rows. No new or edited row since 19 May 2026, four months stale.
analytical_model.campaign_signals	The campaign list: name, test flag, created date.	Fresh. 4,525 rows, last updated 18 Sep 2026.

By stage

Stage	Table	What it provides	Freshness
Intake	analytical_model.campaign_signals	Intake start: the campaign creation date.	Fresh (18 Sep 2026).
Intake	public.signals_workfront_tasks rows where task_type = Creative Intake	Intake end: the latest intake task completed in the campaign.	The table loads daily: 361,190 rows, latest task entered 20 Sep 2026. Only 244 rows carry this label; the newest completed 10 Sep 2026.
Creative	public.signals_workfront_tasks rows where task_type = Content	Creative start (first Content task created) and end (last Content task completed).	Fresh. 9,392 rows with this label; the newest completed 18 Sep 2026.
Targeting	public.signals_tactic_cp_wf	Labels each tactic Content Pantry or Workfront. This decides which targeting and fulfillment rule the tactic follows.	Unknown. 8,912 rows, no date column.
Targeting	analytical_model.tactic_signals	Content Pantry tactics: targeting start (tactic created date) and the “in market” targeting end.	Frozen (19 May 2026).
Targeting	public.signals_workfront_tasks rows where task_type = Targeting Intake Targeting Production File	Workfront tactics: targeting start and end.	The labelling has stopped. Last `Targeting Intake` task entered 10 Mar 2026 (678 rows). Last `Targeting Production File` task entered 6 Jun 2025 (396 rows).
Targeting	public.darf_tracking where status = T	Content Pantry email: targeting end: the audience is ready.	Stale. About 206 million rows; latest file 16 May 2026.
Fulfillment	public.signals_placement_status_updates_04062026	Display media: fulfillment start (first status change) and launch date (status reaches DME Launched).	A frozen snapshot loaded by hand. 85,657 rows, ending 6 Apr 2026.
Fulfillment	public.darf_tracking where status = P	Content Pantry email: fulfillment start (first file) and launch date (last `P` file).	Stale (16 May 2026).
Fulfillment	public.signals_wf_email_fulfillment_tasks_2	Workfront email: launch date: the last “Schedule for Deployment” task completed.	A one-off April export. 1,482 rows, latest completion 14 Apr 2026. Dates stored as text; 401 rows have no tactic ID.
Fulfillment	public.signals_workfront_tasks rows where task_type = Content	Workfront email: fulfillment start, reused from the first Content task.	Fresh.
Fulfillment	analytical_model.campaign_tactic_metadata	The planned start date, used as a fallback launch date and labelled `TLP Metadata`.	Unknown. 4,652 rows, no load date. Planned dates run to 30 Sep 2026, so it is being updated.
Fulfillment	analytical_model.tactic_signals	The tactic’s planned start or end, used as the last-resort fallback launch date.	Frozen (19 May 2026).

What to take from this

Every table that records a real launch is stale (they stop on 6 April, 14 April and 16 May), and so is the tactic list itself. A recent tactic has nothing to match against, so it gets a planned date instead. Staleness is a direct cause of the borrowed dates.
The manual run reads an even older table. The board SQL uses signals_wf_email_fulfillment_tasks (1,105 rows, latest completion 21 Oct 2025) instead of the _2 export.
Two up-to-date tables exist that the report does not read: public.signals_placement_status_updates (live display status log, 128,585 rows, updated 21 Sep 2026) and public.v8_darf_files (live DARF file list, 4,038 rows, through 19 Sep 2026). They can’t simply be swapped in, though: the live display table uses status codes (LRY, LCD) in a column called status, while the snapshot uses status names in task_status.
Workfront targeting labels stopped at the source. Even a perfect rebuild would show no Workfront targeting for anything in the last six months until that labelling is restarted.
Intake and Creative are the only stages fed entirely by fresh data.

How measured: one aggregate query per table (count(*), max of the date column). darf_tracking was read only through its index, never scanned.

04What this means for the proposed design

The row count is a symptom. The real problem is that nobody can check the answer. Gaps in the underlying data get filled in without saying so, the rules that removed or kept a row leave no record, and a wrong value can’t be corrected. That makes the numbers hard to trust, and the problem builds up from three places.

Where it starts	What actually happens
People cannot log everything the human gap	About 78% of Workfront tasks carry no task_type, so the report never sees them. Workfront holds all of Marriott’s project work, though, so many of those tasks probably have nothing to do with these campaigns. The 78% is the most that could be missing, not a count of missing tactic work. What is certain: Targeting Intake labelling stopped in March 2026 and Targeting Production File in June 2025, and the display placement table is a snapshot someone loaded by hand on 6 April. None of this is anyone’s fault: it is what happens when logging is a side task.
The automated logic fills the gaps instead of reporting them the system gap	Where there is no launch evidence, the query substitutes a planned date and still marks the tactic launched: 99.8% of rows read “launched” when the logic is run today. It takes `max()` across five sources, so a planned date that happens to be later overwrites a real one (14 of 35 Content Pantry email rows). Every refresh fills more rows without a single new piece of evidence.
Together they remove visibility and recourse the trust gap	Exclusions, the choice of source and the gap-filling all happen inside one calculation in one stored table (a materialised view). You cannot see which rule applied to a tactic, cannot reliably tell a measured date from a borrowed one, and cannot correct a value you know is wrong, because the view is rebuilt from scratch at every refresh. So the numbers get argued about instead of used.

The proposal below is about making each of these three problems visible and fixable, rather than keeping more rows. It uses dimension tables that record why a row is out, one fact table per phase where every date says where it came from, and a validation table where a person’s correction can be stored.

Terms used in this section

Dimension table (dim_): a master list of things, such as every campaign or every tactic, with their descriptive details.

Fact table (fct_): a table of events or measurements, here the start and end date of each phase for each tactic.

Materialised view: a query whose results are saved as a table and rebuilt from scratch each time it is refreshed.

dbt: an open-source tool for writing, testing and version-controlling the SQL that builds these tables.

COALESCE(a, b): SQL for “use a if it exists, otherwise use b”.

Today: one query, one table

The output is public.signals_all_data_qmy_04092026, a materialised view (a saved table), not a query someone runs by hand. The exclusions, the choice of date source and the gap-filling all happen inside one calculation, and none of them leaves a trace in the result.

The proposed design, wherever it ends up running

The design has three parts. Dimension tables keep every tactic and record why one is left out of the report. One fact table per phase stores each date along with where it came from. And a {table_name}_manual_validation table sits beside every dimension and fact table, so a person’s correction has a place to be stored. The three options that follow differ only in which database this runs in.

Every dimension and fact table gets a matching {table_name}_manual_validation, so a correction to a tactic’s exclusion reason is stored the same way as a correction to its launch date. The measured row is never overwritten. The view picks which value the report shows and says which one it used.

What an edit looks like

Amanda knows tactic 88412 went live on 12 June, and the report shows 18 June because it borrowed a planned date.

She edits in Retool/Other Web Apps

A row is written to fct_tactic_fulfillment_manual_validation: ref_key 88412, end_date 2026-06-12, edited_by Amanda, edited_at now.
The fact table is untouched

fct_tactic_fulfillment still holds 2026-06-18, end_source 'TLP Metadata', is_measured false. The original value is kept, even after the correction.
The view resolves the two

COALESCE(m.end_date, f.end_date) returns 12 June (Amanda’s value, because it exists). The source column says 'confirmed by Amanda', so nobody mistakes it for a measured date.
The report keeps both dates

It shows 12 June, labelled as confirmed by a person. The borrowed 18 June stays on record underneath, so the change can be checked and undone.

inferred: a worked example of the proposal, not something the current report can do.

Three ways to get there

The design above is the same in all three. What changes is which database it runs in, which in turn decides how fast it moves and who can change the logic.

lives in Marriott’s Postgres
lives in a Block & Tackle Postgres, which B&T builds and runs

OPTION 1

Build at B&T, hand the automation back

Build and validate the pipelines on a B&T Postgres first, purely for development speed. Then split the work. Everything that follows a fixed rule is handed to Marriott’s existing pipeline build, and only the tables that actually need people to edit them are handled separately. Everything ends up inside Marriott’s system.

The finished system lives entirely inside Marriott’s system. The handover is the slowest part. Overall this takes a moderate amount of time, with a fair amount of complexity from working across two systems.

OPTION 2

dim / fct tables at B&T, sources stay with Marriott

Most strategic and easiest to complete

The core source tables stay in Marriott’s system and are read from there. B&T owns the dimension and fact tables, which keeps the transformations clean and lets us change the logic ourselves, using dbt or a similar open-source tool that is version-controlled and testable. Retool/Other Web Apps sit on top, giving the team an easy-to-use screen, full customisation and a complete record of original values versus manual changes. The final report tables can be copied back to Marriott’s Postgres whenever Marriott wants them there.

This is the most strategic option and the easiest to complete, because every transformation sits in one system we control, so the logic stays clean, tested and easy to change as the definitions settle. The trade-off is that Marriott depends on a database B&T owns. The optional copy back to Marriott reduces that dependency.

OPTION 3

Everything stays inside Marriott’s system

Work with Marriott’s engineers to automate what can be automated, and add corrections by hand where it can’t. Retool/Other Web Apps connect to Marriott’s Postgres with access limited to a few purpose-built tables. That allows some customisation without opening up the rest of the database.

Least disruption to how Marriott works today. Timeline and speed are the open question: both depend on Marriott’s engineering capacity, and neither is ours to commit to.

The three side by side

	Option 1: build at B&T, hand back	Option 2: dim / fct at B&T	Option 3: Marriott only
Source tables	Marriott	Marriott, read-only	Marriott
dim / fct tables	Marriott, after the handover	B&T	Marriott
Who can change the logic	Marriott’s pipeline, once handed over	B&T: dbt, version-controlled and tested	Marriott’s engineers
Manual edits	{table_name}_manual_validation in Marriott’s Postgres, Retool/Other Web Apps on top	Same tables at B&T, Retool/Other Web Apps on top, full record of original vs edited	A few purpose-built tables, Retool/Other Web Apps with restricted access
Overall fit	Moderate: the handover adds time and complexity	Most strategic and easiest to complete	Unknown: depends on Marriott’s engineering capacity
Complexity we carry	Decent amount: two systems during the build	Contained: one system, end to end	Needs a lot of coordination
Reporting inside Marriott	Native	Write the report tables back when they want them	Native
Main trade-off	Ends up in Marriott’s system, but the handover is the slowest part	Depends on a B&T-owned database	Least disruption, least control over the timeline

inferred: options for discussion, not a decision. All three produce the same tables and the same record of changes. They differ in where it runs and how quickly it gets there.

Five questions, today and under the proposal

Can you…	Today	Proposed
tell a measured date from a borrowed one?	Only the flow label hints at it, and it disagrees with the date: 72 rows carry the fallback label with no date, and only 384 of 1,245 fallback dates are actually the planned start.	is_measured and end_source sit on the same row as end_date. Planned dates keep their own named columns and never enter end_date.
see how a rule applied to a given tactic?	No. The twelve rules run inside one `WHERE` and the row is simply gone. There is nothing left to ask about.	in_report and exclusion_reason on dim_tactic. One `GROUP BY` reproduces the waterfall in section 1, on demand.
correct a value you know is wrong?	No. The materialised view is rebuilt from scratch at every refresh, so any edit is erased.	{table_name}_manual_validation beside every dimension and fact table, coalesced in a view, with the person’s name carried through into the source column.
say “we do not measure this yet”?	No. A blank is filled with a plan. tactic_launched reads “launched” on 99.8% of rows when the logic runs today, including tactics planned for the future.	Yes. is_measured false with an empty end_date is a valid answer, and it is the accurate one for Targeting today.
explain what changed since the last refresh?	No. 302 tactics left the report over the summer because a campaign flag flipped, and nothing surfaced it.	When in_report changes, it shows up as a count moving on a dashboard instead of rows disappearing without notice.

inferred from the measured evidence in sections 1–3. The 302 figure is measured: tactics present in the April table and absent today solely because their campaign’s is_test flag is now true, mostly Boutiques_Shops and Boutiques_Global, both in_market.

How this moves forward

Step by step, and nothing gets built until the step before it is settled. The first three are decisions, not engineering: they need one working session with the tables in sections 1 to 3 on screen.

Stage definitions

Sign off what each stage date means, column by column, against section 2. Targeting is the one to settle first, because the right answer there may be “not measured yet” rather than a definition.
Exclusions

A yes or no on the ~560 rows removed by name-matching in steps 6 to 12, and on the Boutiques test flag. This is a decision for Marcus and Amanda, not more SQL.
Data freshness

Agree what gets fixed at source: why tactic_signals stopped on 19 May, why targeting labelling stopped, and whether the live placement and DARF tables replace the frozen snapshots.
Workflow decisioning

Pick one of the three options above. It sets who owns the tables, who can change the logic, and how fast the rest of this moves.

What happens after step 4

Once a workflow is agreed, we come back with the next part of the proposal: the table specifications column by column, the validation rules, what sits in Retool/Other Web Apps and who can use it, and the order of work, in enough detail to estimate.

Build mode starts after that, not before. Every problem in sections 1 to 3 is a definition or a data-ownership question first, and building on top of definitions nobody has agreed would just give the same wrong answers in new tables.

If you ask…	You mean	Tactics in Q1 2026
STARTED	work we began in the quarter	540
WORKED	work we touched in the quarter, whenever it began	565
planned	what was scheduled to start in the quarter (a forecast)	480

	Question it answers	Tactics	Campaigns
STARTED	tactics we began in Q1 2026	540	103
WORKED	tactics we did work on during Q1 2026	565	113

Phase	Measured, STARTED	Measured, WORKED
intake	181 of 540 (34%)	197 of 565 (35%)
creative	117 (22%)	234 (41%)
targeting	12 (2%)	25 (4%)
fulfillment	280 (52%)	422 (75%)

Phase	Typical (median)	Based on
intake	36 days	181 / 197 tactics
creative	9 days (STARTED) · 39 days (WORKED)	122 / 275 tactics
targeting	14 days (STARTED) · 18 days (WORKED)	12 / 25 tactics (thin)
fulfillment	40 days	280 / 422 tactics

Definition	Rule applied	Tactics
STARTED	tactic_creation_date falls in Jan–Mar 2026	540
WORKED	any phase _end_date falls in Jan–Mar 2026	565
planned	quarter = 1 AND year = 2026 (the view’s own columns)	480

Cohort	Question	Tactics	Campaigns	Creation dates span
STARTED	began in Q1 2026	540	103	2026-01-02 → 2026-03-31
WORKED	worked on in Q1 2026	565	113	2024-06-03 → 2026-03-30

Phase	S n	S mean	S median	S range	W n	W mean	W median	W range
intake	181	129.3	36.0	0 … 431	197	125.4	36.0	0 … 431
creative	122	18.6	8.5	0 … 70	275	55.4	39.0	0 … 603
targeting	12	22.2	13.5	5 … 77	25	60.8	18.0	0 … 463
fulfillment	280	57.1	40.0	-60 … 310	422	56.4	41.5	-447 … 313

tactic_id	Type	fulfillment_flow	Start	End	Days
2972	email	TLP Metadata	02/20/2026	11/30/2024	-447
2973	email	TLP Metadata	02/09/2026	12/01/2024	-435
7203	email	TLP Metadata	03/23/2026	01/22/2026	-60
7476	email	TLP Metadata	01/29/2026	12/11/2025	-49
7175	email	TLP Metadata	02/23/2026	01/15/2026	-39
7902	email	TLP Metadata	03/12/2026	03/04/2026	-8

Phase	S comparable	S agree	S %	W comparable	W agree	W %
intake	181	181	100%	197	197	100%
creative	117	115	98%	234	215	92%
targeting	12	12	100%	25	25	100%
fulfillment	280	280	100%	422	422	100%

Route	STARTED	WORKED
TLP Metadata	250	215
(none)	108	14
Tactic Start Date (Fallback)	99	95
DME	66	166
CP Email DARF Enabled	17	27
WF Email	0	48

tactic_name	ACQ_LTO_BR_MTL_Bradesco_Q1_Email
campaign_name	2026_ACQ_BR_Bradesco
tactic_type / platform	email / WF
fulfillment_flow	TLP Metadata
created	01/14/2026
creative	None → 03/19/2026 (64 d)
targeting	None → None
fulfillment	01/14/2026 → 04/17/2026 (93 d)
creation → fulfillment	93 days

task_type	Tasks	First completed	Last completed
Tactic	3	2026-04-20	2026-04-20
Content	2	2026-03-19	2026-03-19
Language	2
Audience	1	2026-03-19	2026-03-19
NULL	1

tactic_name	3828_ Q1_2025_ACB_Default_Email
campaign_name	ACB_Default
tactic_type / platform	email / WF
fulfillment_flow	WF Email
created	01/17/2025
creative	None → 01/22/2026 (370 d)
targeting	01/17/2025 → 01/17/2025
fulfillment	01/17/2025 → 03/31/2025 (73 d)
creation → fulfillment	73 days

task_type	Tasks	First completed	Last completed
Content	8	2026-01-22	2026-01-22
NULL	6	2025-02-10	2025-03-31
Tactic	3	2025-03-31	2026-01-22
Audience	1	2026-01-22	2026-01-22
Targeting Intake	1	2025-03-07	2025-03-07
Targeting Production File	1

Source	What it is	What it knows
Workfront (WF)	Project-management SaaS	Who did what, and when each task was actually completed
Content Pantry (CP)	The in-house authoring app	What the campaign and tactic are: names, types, content
Blob Storage (Miacc SFTP)	A file drop	DARF files: which audience/treatment rows were sent, and their status

Automated? (quoted verbatim from the board)
Table	Automated?
signals_workfront_tasks	yes “Yes. Databricks Signals get data. Daily update.”
tactic_signals, campaign_signals	yes “Yes. Databricks Data_refresh_signals. Daily Update.”
darf_tracking	yes “Yes. Databricks DARF Tracking Refresh. Daily Update.”
signals_tactic_cp_wf	yes “Yes. Pulls from tables that are automated.”
signals_placement_status_updates_2	no “No. Pulls from a workfront report on DME that needs to be refreshed and reuploaded to SQL.”

Each signal as the boards specify it
#	Phase	Start / end signal	Where it comes from
1	Intake	cs.created_dt (campaign), ts.created_dt (tactic)	campaign_signals, tactic_signals
2	Creative	MAX(actual_completion_date) WHERE task_type = 'Creative Intake'	signals_workfront_tasks
3	Targeting	MIN(entry_date) WHERE task_type = 'Audience' → DARF T flag	signals_workfront_tasks, darf_tracking
4	Fulfillment	DARF P flag: MAX(file_name_date) WHERE status = 'P'	darf_tracking
5	In-Market	MAX(entry_date) WHERE task_status = 'DME Launched'	signals_placement_status_updates

Object	Rows	What it is
signals_all_data + 11 dated siblings	3,385–4,245	One row per tactic with every milestone date. The reporting table.
signals_no_darf	15,989	Same idea for tactics with no DARF involvement.
signals_debug, signals_debug_2	small	Working views used while investigating.
analytical_model.CP_EXPORT_*	1–360	A separate small export path, unrelated to durations.

Table	Last activity	Age
signals_placement_status_updates	2026-08-26	current
signals_workfront_tasks	2026-08-25	current
campaign_signals	2026-08-25	current
signals_tactic_cp_wf	2026-08-25	current
v8_darf_files	2026-08-25	current
tactic_signals	2026-05-19	99 days
darf_tracking	2026-05-16	102 days
signals_placement_status_updates_2	2026-01-06	232 days

Table	Rows	What it holds
public.signals_workfront_tasks	343,527	Every Workfront task with planned vs actual dates. The most important table here, because nearly all timing comes from it.
analytical_model.campaign_signals	4,493	One row per campaign: name, type, owner, dates, status.
analytical_model.tactic_signals	7,231	One row per tactic: its campaign, type, dates, status, and the `created_by` that decides CP vs WF.
public.darf_tracking	206,215,733	The audience-delivery log, with one row per attribute per treatment per file. The team warns: “Big table, queries will take around 2 minutes to load.”
public.v8_darf_files + v8_darf_tracking_v2	3,586 + 15,680,664	The same DARF data restructured, with file details factored out so they aren’t repeated on every row. 206M becomes 15.7M.
public.signals_placement_status_updates	116,534	When a DME placement changed status. The manual one.
public.signals_tactic_cp_wf	8,626	Tiny lookup: for each tactic, CP or WF.
public.signals_wf_email_fulfillment(_tasks)	2,120 / 1,105	Email delivery tasks. Being retired (see below).

View	What it does
workfront_tasks_clean	Trims the raw Workfront list to the tasks that matter
signals_tactic_cp_wf_2	The CP/WF lookup, derived live rather than stored
signals_darf_status	Reduces the 206M-row DARF log to a status per tactic

I want to…	Go to
See the tables and how they connect, interactively	the Master view tab
Read a full worked analysis of one quarter	the Q1 2026 story tab
See what is wrong and what the options are	the Fix options tab
Look up exact columns and types	database/ddl/
See what the diagrams claimed, for comparison	database/from_diagrams/erd_as_drawn.sql
Trace what feeds what, programmatically	lineage/lineage.json
Get the full validated reference	lineage/SOURCE_OF_TRUTH.md
Read what each original diagram said	diagrams/extraction/NN_*_extracted.md
Find the exact formula for one signal	diagrams/extraction/02_data_sot_current_day_extracted.md §2.2
See SQL and screenshots that exist only as images	diagrams/extraction/00_image_only_components.md

	Rows	Share
Have all four stages measured	17	0.5%
Have no stage measured at all	1,249	34%
Launch date came from real evidence	1,601	43%
Launch date was substituted from a plan	1,895	51%
Nothing found, nothing substituted	207	6%

The view joins	Frozen at	Live alternative	Last activity
signals_placement_status_updates_04062026	2026-04-06	signals_placement_status_updates	2026-08-26
darf_tracking	2026-05-16	v8_darf_files / v8_darf_tracking_v2	2026-08-25
analytical_model.tactic_signals (the spine)	2026-05-19	n/a	n/a
analytical_model.campaign_signals	2026-08-25	n/a	n/a
signals_workfront_tasks	2026-08-25	n/a	n/a

Missing fact	Who already knows
Which display placements actually launched	Shelby (status list), Dalitso (the load)
Content Pantry process and edge cases	Ash, Natalie, Katie
Whether a tactic is DCA / MBOP-enabled	CJ
Audience revision history	Michele Grant, Marcus
Placement source of truth	Tytianna, Jared

	Option 1: Automated	Option 2: Human in the loop
Ongoing effort	none	~1 hour/week, one owner
Report becomes	smaller, honest	fuller, honest, improving
Guessed numbers	removed	replaced with confirmed answers
Time to first version	weeks	weeks, then improves continuously
Fails how?	goes blank	degrades to Option 1
Biggest risk	headline numbers visibly drop	nobody answers the queue

fulfillment_flow	Rows	Meaning
Tactic Start Date (Fallback)	1,245	substituted: planned date copied in
WF Email	917	measured: a deployment task completed
TLP Metadata	650	substituted: planned start from a metadata table
DME	568	measured: placement reached DME Launch Ready/Launched
NULL	207	nothing found, nothing substituted
CP Email DARF Enabled	116	measured: a DARF file with `status = 'P'`

Object	Rows	Note
signals_all_data	3385
signals_all_data_automated_refresh	4245	the only revision reading the live DARF path
signals_all_data_qmy	3490
signals_all_data_qmy_02112026	3593
signals_all_data_qmy_03032026	3724
signals_all_data_qmy_04062026	3634
signals_all_data_qmy_04062026_v2	3634
signals_all_data_qmy_04092026	3703	board says “most up to date”
signals_all_data_qmy_0416026_2	4245	note the misspelt name (7 digits)
signals_all_data_qmy_04162026	4031	later date, older SQL body
signals_all_data_v2	4245

Quote	File
“These are the Signals confirming completion — we don’t have them all yet.”	diagrams/extraction/02_data_sot_current_day_extracted.md (board header)
“We lose a lot of data with the given time constraints. In fact it keeps us from having anything at all on Targeting.”	diagrams/extraction/07_average_durations_extracted.md
“audience_tactic_attribute does not track time it was added.”	diagrams/extraction/03_signal_sources_wip_extracted.md @176365,19541
“ACC should send us an audience count after it is processed. This is the end of Targeting.”	diagrams/extraction/02_data_sot_current_day_extracted.md
“Needs to be ran each refresh, this is the step holding us back from automation.”	lineage/notes.json → signals_placement_status_updates_2
“…if someone deletes a placement task for some reason in WF it is in the void as far as our reporting is concerned.”	lineage/notes.json → same entry
audience-immutability exchange (Michele Grant / Marcus)	diagrams/extraction/00_image_only_components.md §D (Otter.ai transcript pasted on board 03 @26262,6847)
“The drastic change in 2024 numbers is almost entirely due to the switch…”	diagrams/extraction/02_data_sot_current_day_extracted.md (stakeholder review thread)

01Where the 7,231 → 3,594 drop goes

The waterfall: 7,231 down to 3,594, step by step

Totals by verdict

02Stage definitions: agreed vs what the query does

Words used below

Stage 1: Intake the request for the work comes in and is accepted

Stage 2: Creative the content is written and designed

Stage 3: Targeting the audience who will receive it is chosen and delivered

Stage 4: Fulfillment the tactic is built, scheduled and goes live

Columns built on top of the stages

Stage by stage, in one line each

03Source tables and how fresh they are

Used by every stage

By stage

What to take from this

04What this means for the proposed design

Today: one query, one table

The proposed design, wherever it ends up running

What an edit looks like

She edits in Retool/Other Web Apps

The fact table is untouched

The view resolves the two

The report keeps both dates

Three ways to get there

Build at B&T, hand the automation back

dim / fct tables at B&T, sources stay with Marriott

Everything stays inside Marriott’s system

The three side by side

Five questions, today and under the proposal

How this moves forward

Stage definitions

Exclusions

Data freshness

Workflow decisioning

How long does it take to get a piece of marketing out the door?

1 Five words, and then we can begin

2 The awkward part comes first: “Q1 2026” means three different things

3 The two groups of tactics

4 How far does a tactic actually get?

Phases with both a start and an end date

5 Where the time actually goes

Typical (median) days per phase, on a scale of 0–60 days

6 Four things wrong with the data, and what each means for you

Defect 1 · Appendix D

Every date is stored as text, not as a date

Defect 2 · Appendix E

Some tactics finish before they start

Defect 3 · Appendix F

Some “creative” durations disagree with their own dates

Defect 4 · Appendix G

One common fulfillment “route” is the query giving up

7 Two real tactics, followed all the way down

8 If you take four things away

9 What this does not tell you

Appendices the detail, for whoever needs it

fulfillment_flow in the STARTED cohort (540 tactics)

STARTED: tactic_id = 7302

WORKED: tactic_id = 3828

MI Signals: the whole thing, explained simply

1 What this system is for

2 Where the data comes from

Database

staging-new

Database

heavy_processes

3 The journey, start to end

4 The five phases as designed, and the four the query actually builds

5 The vocabulary you need

CP vs WF: who built this tactic?

Measured split across 8,626 tactic rows

Tactic types

Measured across Workfront task rows

Task types

DARF status flags

6 What’s in each table

Landing tables: raw copies, one per source

Joining views: small, and they do the tidying

Output: what people actually read

7 The six things that will confuse you

1 · There are twelve copies of the reporting view, not one

STARTED: `tactic_id = 7302`

WORKED: `tactic_id = 3828`

`staging-new`

`heavy_processes`

3 · `signals_wf_email_fulfillment_tasks` is being retired on purpose

4 · `tactic_id` is not the same type everywhere

Name	The note
Shelby	“Get list of statuses for DME from Shelby.”
Dalitso (Moyo)	“I am putting in the fixes to our two tables (Dalitso feel free to add any other changes made…)”
Ash, Natalie, Katie	“Reach out to Ash, Natalie, and Katie” / “CP = Ash, Natalie, Katie”
CJ	“CJ is the man. Let’s us identify which placement has what attributes to be DCA enabled or not.”
Michele Grant, Marcus	speakers in the audience-immutability transcript, `diagrams/extraction/00_image_only_components.md` §D
Tytianna, Jared (Brookins)	named as contacts for “Placement Source of Truth”
Katie R.	“Interim status check, Katie R doing this manually today, how can we automate this?”

What you want	Where
The deployed report’s SQL, reformatted and annotated	database/views/public.signals_all_data_qmy_04092026.sql
Line-by-line teaching walkthrough of that SQL	guides/2_REPORT_LOGIC_ONBOARDING.md
Revision inventory and which one to trust	guides/3_SIGNALS_ALL_DATA_EXPLAINED.md
Where the boards and the live database disagree	database/BOARD_VS_LIVE.md
Verified lineage: what feeds what	lineage/SOURCE_OF_TRUTH.md, lineage/lineage.json
Exact columns, types, keys, row counts	database/schema_snapshot.md
The team’s raw board content	diagrams/extraction/*_extracted.md
Content that exists only as pixels (charts, screenshots, transcript)	diagrams/extraction/00_image_only_components.md
How the boards were decoded, and every correction made	_archive/PIPELINE_LOG.md