# Lane 5 — Outside-the-box business and operating-model challenge Fusion Tables PPC system audit, 2026-08-30. Read-only. Spend USD 0. No live mutation, no sends, no commits, no restart of the stopped build run. Ground truth taken as given from `GROUND-TRUTH.md`; not re-derived. Orchestrator corrections ORCH-CORR-1 and ORCH-CORR-2 were independently re-verified against the artifacts before use (`git ls-tree HEAD ads-control` returns empty; `report_data.json` re-read directly). Evidence labels used throughout: `observed` / `configured state` / `verified business outcome` / `defect` / `hypothesis` / `recommendation` / `future idea`. `UNAVAILABLE` is never rendered as zero. --- ## Verdict in one paragraph The system is epistemically honest and operationally misaimed. Its evidence discipline is genuinely good — grains are labelled, `UNAVAILABLE` is distinguished from zero, windows are kept separate, and the client report refuses to call a platform event a lead. But the money is being steered by a conversion signal that counts people who *began typing in a form* (46 of 49 Google conversions and 100% of Meta's Results are the same `VHK_form_start` event), the client's enquiry register has no source column so those 13 real enquiries cannot be attributed to anything, four of the five enquiry forms recorded zero rows for thirty days without any view raising an alarm, and the account contains exactly one enabled Google campaign and one Meta campaign — so the creative / placement / demographic comparison Matt asked for has no population to compare and no schema dimension to compare it on. Meanwhile the apparatus built to answer that question spent 555,380 tokens producing an index of evidence that already existed as real data files one branch over, and then stopped while reporting `Status: ACTIVE`. **The binding constraint is not the dashboard and not the delegation architecture. It is the conversion-signal definition, the missing CRM source column, and the account structure.** --- ## 0. Corrections folded in ### ORCH-CORR-1 — children launched from a branch missing their inputs Independently confirmed on the reviewed branch `round-13-takeover` @ `8351b59`: ``` $ git ls-tree -d HEAD ads-control -> (empty) $ git ls-tree -d HEAD deliverables/fusion-meta-ads-review-2026-08-24 -> (empty) $ git ls-tree HEAD outputs/loop-runs/2026-08-28-fusiontables-report/ 100644 blob 4a9f1496... outputs/loop-runs/2026-08-28-fusiontables-report/ledger.json ``` Every child worktree was created from this branch. The KPC keyword-control system, the Meta creative dashboard and the entire 2026-08-28 report package (`report_data.json`, 535,340 bytes) are absent from it. `ledger.json` alone survives. **Business consequence.** T1 was commissioned to "build an authoritative PPC evidence corpus". It did so by reconstructing evidence from Codex transcripts, Notion pages and 131 Git blobs — an archaeology job — because the real data files were not on its branch. It burned 555,380 tokens (`children/t1-evidence-corpus/artifacts/return-receipt.md`, and the dependency ledger's "final usage 555,380 tokens") to produce 716 lines of Markdown index. `report_data.json` on the orchestrator branch contains, in machine-readable form, most of what the evidence matrix asserts in prose — and it contains more, including the conversion-action breakdown that the corpus never surfaces. **Is this an argument about this run or about the delegation model?** Both, and the split matters. - *About this run:* one missing check. A single-worker session on the wrong branch would have failed identically. Delegation did not cause it. - *About the model as configured:* structural, and this is the serious half. The apparatus contains 61 files and 564 KB under `/home/matt/mirror/Fusion/outputs/loop-runs/20260830-fusion-ppc-architecture-orchestration/`. It verified model pins via Codex SQLite (`ARCH-02 PASS`), goal SHA-256 hashes per child (`ARCH-03 PASS`), tmux session liveness, 131 Git blobs, 17 secret redactions, `git diff --check`, 19 local links and commit-scope hygiene. **None of the ten ARCH acceptance rows, and none of the ten access-ledger rows, asks whether the child's input data exists on the child's branch.** The control surface grew around *process provenance* — who ran, at what model, with which hash — and not around *input availability*. Every added child multiplies the process surface; none of it touches the actual risk. The defect is that acceptance criteria were written about the delegation rather than about the deliverable, and delegation is what made that mistake expensive. ### ORCH-CORR-2 — verified against `report_data.json` directly | Claim | Re-verified value | Path | | --- | --- | --- | | One enabled Google campaign | `2605-Fusion-Tables_Pmax` PERFORMANCE_MAX/ENABLED, 4,410 clicks, 92,095.56 Ft, 49 conv. `2605-Fusion-Tables_Search`, `Keresési - KMO`, `Display - KMO`, `Remarketing` all PAUSED, 0 clicks, 0 Ft | `ppc.campaigns` (5 rows) | | One Meta campaign | `2505-fusion_tables_biliard_1_Lead`, 89,778 Ft | `meta_ads.campaigns` (1 row) | | No search terms | `ppc.search_terms` = `[]` | `ppc.search_terms` | | No creative/placement/demographic dimension | absent from the schema entirely; `cro.landing_pages` = `[]`, `cro.interaction_events.allowlist` = `[]` | `cro` | | Optimisation target is a form-start | `vhk_form_start` = 46.0, `VHK_lead` = 3.0, all 18 other actions 0.0 | `ppc.conversion_actions` | | Meta uses the same event | `result_indicator: "conversions:offsite_conversion.fb_pixel_custom.VHK_form_start"`, `result_interpretation: "form-start signal, not verified enquiry"` | `meta_browser_receipt.json` | | Attribution blocked at the CRM | `crm.source_column` = `null`; note: "this spreadsheet has no source or campaign column, so enquiries cannot be attributed to a traffic source" | `crm.no_source_column_note` | | Refresh not automatable | 190/467 Meta session invalid, manual Ads Manager export; `source_health`: google_ads `degraded`, meta_ads `degraded`, crm_sheet `degraded`, work_evidence `degraded`, search_console `absent`, ga4 `absent`, bigquery `disabled` | `source_health`, `limitations[0]` | All four hold. They change my recommendation's *reasoning*, not its direction — see §6. --- ## 1. How much of "all the steps till purchase" is actually measurable Matt's requirement, verbatim (`019ff730...`, T0001 line 10): *"the goal is to make all the steps till purchase fully transparently measurable."* Funnel for a premium game-table retailer, scored against the 2026-07-25..2026-08-23 window, the most complete window the system has ever produced: | # | Funnel step | Measured value | Source | Attributable to a channel? | | --- | --- | --- | --- | --- | | 1 | Impression | Google 105,555 · Meta 63,461 | platform | **yes** | | 2 | Click | Google 4,410 · Meta 825 | platform | **yes** | | 3 | Landing-page view | Meta 626 · Google `UNAVAILABLE` (no GA4) | Meta pixel | Meta only | | 4 | On-page engagement (gallery, 1 min, 2 pages, designer click) | all six actions read 0.0; GA4 `absent` | — | no | | 5 | Form start | Google 46 · Meta 14 — **the same `VHK_form_start` event under two attribution models** | GA4 import + Meta pixel | double-counted | | 6 | Form submit | `Submit lead form (Page load https://fusiontables.hu/biliard/biliard)` = **0.0** | Google Ads | no | | 7 | Recorded enquiry | **13** (prior 7) | client Sheet `1L9YZG54...` | **no** — `source_column: null` | | 8 | Contact made / reached | `UNAVAILABLE` | — | no | | 9 | Qualified | `UNAVAILABLE` | — | no | | 10 | Showroom / consultation | `UNAVAILABLE` | — | no | | 11 | Quote sent | `UNAVAILABLE` this window (6 free-text records exist only for 2026-07-16..07-28) | — | no | | 12 | Quote accepted | `UNAVAILABLE` | — | no | | 13 | Purchase | `Purchase (Page load .../billiardasztal/billiardasztal)` = **0.0**; real purchases `UNAVAILABLE` | — | no | | 14 | Revenue / margin | `UNAVAILABLE`; `conversion_value` is a 1 Ft placeholder (49 conv = 49.0 HUF) | — | no | **Score.** Fourteen steps. Measured *and* channel-attributable: **2.5 of 14 (18%)** — impressions, clicks, and landing-page views on Meta only. Measured at any grain: 5 of 14 (36%). Measured with business meaning after the click: **0 of 9**. Money-side steps (quote, acceptance, purchase, revenue) measurable: **0 of 4**. **The blunt version.** 5,235 paid clicks entered the window. The measurement chain survives to 13 enquiries that cannot be assigned to a channel, and then stops. **99.75% of paid click volume disappears into an unmeasured region**, and the last event the system can actually see is somebody beginning to type in a form. **The chart Matt asked for, honestly drawn**, is three bars per channel (impressions, clicks, form-starts), one shared bar that cannot be split by channel (enquiries), and then a wall labelled `UNAVAILABLE`. It fits on one screen. It needs no dashboard framework, no eight children, and no delegation architecture. That the honest version of the deliverable is this small is the single most important operating-model fact in this audit. --- ## 2. What each existing view actually enables — decision inventory | View | Path | Budget decision it actually enables | Decision it *appears* to enable but does not | | --- | --- | --- | --- | | 30-day report `report.md` | `outputs/loop-runs/2026-08-28-fusiontables-report/report.md` (orchestrator branch) | "Spend rose, traffic rose, enquiries rose. Audit the conversion actions before acting." Genuinely useful, and it says so itself in R-2026-07-01. | Channel reallocation. It puts Google 49 conv and Meta results side by side in adjacent tables; a reader divides and gets 1,880 Ft vs 6,413 Ft. Both numbers count the same event. | | KPC stage-3 dashboard | `ads-control/template/stage-3-ai-advice-review.html` (rendered report **not in git on any branch**) | **None.** `kpc_snapshot.advice_summary`: `approve_for_planning: 0`, `investigate_next: 0`, `wait_for_evidence: 61`. Zero actionable rows from 61. | Keyword optimisation. All 61 keywords sit in paused campaigns; 17 carry `needs_attention: true` for a condition that is one campaign-level fact. | | Meta Creative Control | `deliverables/fusion-meta-ads-review-2026-08-24/index.html` (orchestrator branch; **not on the reviewed branch**) | Historical creative triage on a frozen 2026-07-11..08-09 snapshot, with the right caveats printed on the page. | Current creative decisions. Fresh access fails 190/467. Its two source JSONs (`.tmp/overnight-2026-08-10/data/meta_ads.json`, `meta_ad_insights.json`) **do not exist anywhere on this host** — `find /` returns nothing. | | `internal-audit.html` | `/home/matt/mirror/Fusion/deliverables/fusion-ppc-2026-07-30/internal-audit.html` | Access and governance decisions: what is proven, what is not, which approval gate applies. Its heading "A jelentett eredmény űrlapkezdés" (the reported result is a form start) was correct on 2026-07-30 and is still unfixed on 2026-08-30. | Media decisions. It is an audit, not a performance view. | | `deck.html` | `/home/matt/mirror/Fusion/deliverables/fusion-ppc-2026-07-30/public/deck.html` | Call preparation. Each slide carries "Mit mondjon Matyi" / "Mit ne állítson" (what to say / what not to claim) — the best anti-overclaim device in the repo. | Nothing about budget. | | `executive-brief.html` | same folder | A 72-hour action list and one named human decision. | Ongoing management. It is a point-in-time brief. | | Orchestration ledgers | `outputs/loop-runs/20260830-.../*.md` | Nothing about the business. They govern the run, and the run stopped. | That the system is running. `run-state.md` reads `Status: ACTIVE`. | **Nothing in this inventory enables the decision Matt actually asked for** — where to move budget for better-quality leads. Not one view carries a qualified-lead, quote, purchase or revenue number, because none exists. --- ## 3. Five personas, one sharpest question each **The skeptical agency operator paying for this.** *"What did the 555,380 tokens buy me?"* T1's entire output is 716 lines of Markdown that index evidence which already existed as `report_data.json` one branch over. It added zero measurable funnel steps. The month's media budget across both channels is 181,874 Ft. The evidence-index child alone is a material fraction of that, and it is 1 of 8 children. `ledger.json` for the report run records `paid_spend_usd: null`, `provider_cost_status: "not_surfaced"` — **the reporting automation cannot tell you what it costs to run**, so its ROI is formally unjudgeable. The one run that did surface its cost is the one that produced no dashboard. **The analytics engineer.** *"Which event is Primary?"* `ppc.conversion_actions` has twenty rows. Eighteen read 0.0. `vhk_form_start` reads 46.0 and `VHK_lead` reads 3.0. Meta's Results column is the same `VHK_form_start` pixel event. Two of the twenty actions are configured on malformed page-load URLs with doubled path segments — `Submit lead form (Page load https://fusiontables.hu/biliard/biliard)` and `Purchase (Page load https://fusiontables.hu/billiardasztal/billiardasztal)` — and both read 0.0 while the client's own sheet recorded 13 enquiries. `conversion_value` equals the conversion count (49 conv = 49.0 HUF), i.e. every conversion is worth 1 Ft, and `roas` is computed anyway at `0.000532`. **The PPC strategist spending the budget.** *"What am I comparing?"* One enabled Google campaign and one Meta campaign. `ppc.search_terms` is empty. There is no ad-group, ad, creative, asset-group, placement, device, audience or demographic key anywhere in the schema. Average Google CPC fell from 64 Ft to 21 Ft while spend tripled. That is not efficiency; that is Smart Bidding finding the cheapest inventory that produces the cheap event it was told to buy. A 21 Ft click for a premium Hungarian furniture retailer is a warning, not a win. **The client (Fusion Tables).** *"Did the new website bring me anything?"* The enquiry sheet has five worksheets. `Régi Billiárd Ajánlatkérések` (the *legacy* billiard form) recorded 13 and 7. `Főoldal Hero`, `Főoldal Ajánlatkérés`, `Kapcsolat Oldal` and `Termékoldal Ajánlatkérés` each recorded **0 current and 0 previous** — and the only rows ever seen on the product-page sheet were 7 QA test submissions. Thirty days, 5,235 paid clicks, four new forms, zero enquiries. The client-facing report prints only the one non-zero row. **The most alarming fact in the dataset is omitted from the report because it is a zero.** **The first-time operator with zero context.** *"Is it running?"* `run-state.md` says `Status: ACTIVE` and `T2 is active`. `tmux ls` shows nothing. Six of eight children produced no artifacts. To learn the true state you must count commits against a fixed point on eight branches. Separately: `report_manifest.json` ships `"complete": false` in the same directory as `run_receipt.json` with `"complete": true`. Nothing tells the operator which one to believe. --- ## 4. Can the comparison Matt asked for reach significance at this budget? No. Matt asked for *"the demographic distribution and also how different ad copies / ad creatives / different placements / different targeting settings performed"* so he can *"allocate more of the budget."* Two independent reasons it cannot be delivered. ### 4a. There is no population to compare (`observed`) | Dimension Matt named | What exists | | --- | --- | | ad copies / creatives | **no ad or creative key in the schema.** One historical Meta snapshot had 20 creative rows against a 39-ad inventory (51% coverage), of which **2 ads produced all 12 lead actions**; that snapshot is frozen at 2026-07-11..08-09 and its source files are gone | | placements | Google: PMax withholds placement by design. Meta historical: "Instagram carried 94% of spend" — Facebook and Threads samples were explicitly described as "too small to justify reallocating spend" | | targeting settings | Meta historical: "Twenty interests were bundled in one ad set with Advantage audience expansion. Individual interest performance is unavailable" | | demographics | Google: none. Meta: historical only, and the 55+ cell is 7,032 Ft with **zero** form events | A comparison dashboard built on this account today renders a page of one-row tables. ### 4b. Even with the population, the budget cannot power the test (`observed`, arithmetic) Baselines from the window: Meta click→form-start 14/825 = 1.70%; Google click→conversion 49/4,410 = 1.11%. Two-proportion test, α = 0.05 two-sided, 80% power: | Test | Clicks needed per arm | Total | Months at current volume | | --- | --- | --- | --- | | Meta, detect **+30%** relative lift | 11,586 | 23,171 | **28.1 months** (825 clicks/mo) | | Meta, detect **+50%** | 4,523 | 9,046 | **11.0 months** | | Meta, detect **+100%** (a doubling) | 1,348 | 2,697 | **3.3 months** | | Google, detect **+30%** | 17,818 | 35,636 | **8.1 months** (4,410 clicks/mo) | | Google, detect **+100%** | 2,080 | 4,160 | 0.9 months — *but PMax offers no clean two-arm creative split; asset reporting gives "Low/Good/Best" labels with no denominators* | And the cross-tab: Meta produced **14** form-start events in the month. Age (6 buckets) × gender (3) × platform (3) = 54 cells. 0.26 events per cell. Add 20 creatives and it is 1,080 cells for 14 events. That is not underpowered. **It is empty.** The business outcome is worse: 13 enquiries. 95% Poisson band on 13 is ±7.1. The headline **"+85,7%" (13 vs 7) is not statistically distinguishable from noise: two-sided p = 0.263.** Meta's 14 vs 8 form-starts: p = 0.286. The one comparison in the corpus that *is* significant — 12 vs 1 in the earlier report, p = 0.003 — is the one the evidence itself explains away: *"New-site worksheets contained only May test rows"* (`evidence-matrix.md`). The only statistically significant movement in the dataset is a form-migration artefact. ### 4c. The honest alternative (`recommendation`) 1. Stop promising cell-level comparison. State the MDE the budget can actually reach and publish it next to every comparison the dashboard draws. 2. Test one variable at a time at the **channel or concept** level with a pre-registered decision window, not at the cell level. The Meta page's own experiment rule already says this: *"Creative test keeps audience constant. Audience test keeps creative constant."* 3. At 181,874 Ft/month, use **geo or time-based holdouts for incrementality**, not significance testing on segment cells. This is the standard method for budgets that cannot power a split test, and it directly serves Matt's own rule: *"Do not claim Google Ads attribution until the conversion increment is visible."* 4. Move the measurement investment to where each record is worth the most. Thirteen enquiries is a tiny n, but for a premium game-table retailer each one is worth six figures in Ft. **One source column on that sheet is worth more than any amount of platform-side segmentation.** --- ## 5. Ranked challenge register Ranked by business impact and decision risk. Cosmetic issues are excluded entirely. ### CRITICAL **C1 — Both platforms, including PMax Smart Bidding, are optimising toward a form START.** `measurement risk` + `defect` Evidence: `report_data.json` → `ppc.conversion_actions`: `vhk_form_start` = 46.0, `VHK_lead` = 3.0, eighteen other actions 0.0, against 49 total reported conversions. `meta_browser_receipt.json` → `result_indicator: "conversions:offsite_conversion.fb_pixel_custom.VHK_form_start"`, `result_interpretation: "form-start signal, not verified enquiry"`. PMax is `ENABLED` and holds 100% of Google delivery. Why it is critical: this is not a reporting cosmetic. Smart Bidding buys whatever the Primary conversion action counts. Average CPC fell 64 Ft → 21 Ft (−67.6%) while spend tripled — the signature of an algorithm successfully finding cheap traffic that starts forms. **The measurement defect is actively steering the money.** No dashboard fixes this. Smallest safe fix: audit the twenty conversion actions, demote `vhk_form_start` to Secondary, promote a verified submitted-lead action to Primary. This is R-2026-07-01 in the report already, at P1, unexecuted. Requires Matt's explicit approval — it is a live Ads change. Decisive retest: read back `conversion_action.primary_for_goal` for the account; confirm exactly one Primary action and that it maps to a submitted enquiry; then confirm 30 days later that reported conversions land within the same order of magnitude as recorded enquiries. **C2 — The two conversion actions that would measure a lead and a purchase are configured on malformed page-load URLs and read zero while 13 real enquiries arrived.** `defect` Evidence: `ppc.conversion_actions` contains `Submit lead form (Page load https://fusiontables.hu/biliard/biliard)` = 0.0 and `Purchase (Page load https://fusiontables.hu/billiardasztal/billiardasztal)` = 0.0. Both URLs carry a **doubled final path segment**. `crm_connector_receipt.json` records 13 dated enquiry rows in the overlapping window. Why it is critical: it is the cheapest possible explanation for the whole measurement gap, and it is sitting in plain sight in a file that was generated on 2026-08-28 and never read by any of the eight children. A `Purchase` action that fires on a *page load* is also a latent fabrication risk: it reads 0 today, but if that trigger ever matches, the account reports purchases that did not happen. Smallest safe fix: correct the two trigger conditions. Approval-gated (live Ads change). Decisive retest: submit one real enquiry through the live form; confirm `Submit lead form` increments by exactly 1 within the reporting lag, and `Purchase` does not increment at all. **C3 — Attribution is blocked at the spreadsheet, not at the dashboard.** `defect` + `measurement risk` Evidence: `report_data.json` → `crm.source_column` = `null`; `crm.no_source_column_note`: *"this spreadsheet has no source or campaign column, so enquiries cannot be attributed to a traffic source. The breakdown is by the form that recorded the enquiry."* Confirmed in the client config: `client.crm_sheet.source_column = None`. Why it is critical: every downstream question — which channel, which creative, which landing page produced a lead — terminates here. Eight children, a dashboard, two strategies and a targeting pack were commissioned downstream of a null column. Smallest safe fix: add hidden `utm_source` / `utm_campaign` / `gclid` / `fbclid` fields to the forms and matching columns to the sheet. Roughly thirty minutes of work. **It unlocks more of Matt's stated goal than the entire eight-child architecture was scoped to deliver.** Requires client site access, so approval-gated, but reversible and zero-spend. Decisive retest: submit one test enquiry from a tagged paid URL; confirm the row lands with a non-empty source column; then confirm a 30-day report can split 13 enquiries by channel. **C4 — Four of five enquiry forms recorded zero rows for thirty days, and the client report omits them.** `defect` + `UX problem` Evidence: `crm_connector_receipt.json` worksheets — `Régi Billiárd Ajánlatkérések` 13/7; `Főoldal Hero` 0/0; `Főoldal Ajánlatkérés` 0/0; `Kapcsolat Oldal` 0/0; `Termékoldal Ajánlatkérés` 0/0 (and its only rows ever were 7 QA tests). `report.md` prints a single form-breakdown row for the legacy form and no others. Why it is critical: 5,235 paid clicks in the window, four new-site forms, zero enquiries. Either the new forms do not write to the sheet, or paid traffic never reaches them. Both are urgent. The one view that could have surfaced it suppressed it, because the alarm *is* a zero and the report's zero-hiding rule is otherwise a good rule. Smallest safe fix: render zero-row worksheets explicitly in the enquiry table with an `0 — investigate` flag rather than omitting them. One line of report logic. Decisive retest: submit one test enquiry through each of the four new forms; confirm each lands in its worksheet; if any does not, that is a broken form, not a demand problem. **C5 — There is no population to compare, so the requested comparison view cannot be built.** `measurement risk` Evidence: `ppc.campaigns` — one `ENABLED` campaign (`2605-Fusion-Tables_Pmax`), four `PAUSED` with 0 clicks and 0 Ft. `meta_ads.campaigns` — one campaign. `ppc.search_terms` = `[]`. No ad, creative, asset-group, placement, device, audience or demographic key in the schema. See §4. Why it is critical: T3 (dashboard), T4A/T4B (two strategies) and T7 (targeting pack) were all commissioned to answer a question the data cannot support. Had the run completed, it would have produced four polished artifacts arguing over one-row tables. Smallest safe fix: change the deliverable. Build the funnel view (§1) that the data *does* support, and publish the "what must be true before a comparison view is worth building" sequence in §6. Decisive retest: count distinct comparable units in `ppc.campaigns` + `meta_ads.campaigns` where clicks > 0. Today the answer is 2. A comparison view is worth building when that number exceeds ~6 with at least 30 conversions per unit. **C6 — Conversion value is a 1 Ft placeholder and `roas` is computed on it anyway.** `defect` Evidence: `ppc.totals` → `conversions: 49.0`, `conversion_value: 49.0` (HUF), `cpa: 1879.50`, **`roas: 0.000532056053043431`**. Value equals count, i.e. every conversion is worth exactly 1 Ft. Why it is critical: `report.md` does not print ROAS, which is why nobody has noticed. But the field is carried in the data structure that T3's dashboard and T5's report were specified to consume. Any view that iterates `ppc.totals` renders a 0.05% ROAS to a client. This is a live landmine for a deliverable that has not been built yet. Smallest safe fix: set `roas` and `conversion_value` to `null` with `na: "conversion values are placeholders; revenue is UNAVAILABLE"` whenever value == count. Decisive retest: assert in the report generator that `roas` is null while `conversion_value == conversions`; render "N/A — revenue unavailable" and confirm no numeric ROAS reaches any output. ### HIGH **H1 — Period-over-period percentages printed client-facing off degenerate and partial bases.** `measurement risk` Evidence: `report.md` Google table prints **"Konverziók 49 / 1 / +4800,0%"** and "Megjelenések +670,6%", "Kattintások +875,7%". Separately, `meta_browser_receipt.json` records `previous.delivery_days: 11` against `current.delivery_days: 30` — **the Meta baseline contains 11 delivery days, not 30** — and `report.md` states only *"A tárgyidőszak és az összehasonlítási időszak megegyezik a Google Ads dátumaival"* (the periods match Google's dates) without disclosing it. Why: a +4800% and a +190.9% next to each other read as spectacular performance. The first is division by 1; the second is 30 days against 11. A client reads the number, not the footnote. This is precisely the overclaim Matt's own rule forbids. Smallest safe fix: suppress the percentage column when the base is under 10 events or the comparison period has fewer delivery days than the current one; print absolute values plus a delivery-days note. Decisive retest: regenerate the same window and confirm the conversions row shows "1 → 49 (base too small for a percentage)" and the Meta table carries "előző időszak: 11 kiszállítási nap". **H2 — No view anywhere states confidence, sample size, lag or attribution uncertainty as a number.** `measurement risk` Evidence: the corpus states uncertainty *qualitatively* and does it well — `date-account-caveats.md` separates grains, `source_health` carries `freshness: "lag_days=1"` and a `change_event` history gap, the Meta page prints "Insufficient sample" as a triage badge with a 1,000 Ft floor. But no artifact contains a confidence interval, a p-value, an MDE, or a minimum sample. Measured absence: `grep -ci "confiden\|p-value\|significan\|interval"` across the T1 corpus and `report.md` returns nothing relevant. Why: the "+85,7%" enquiry headline fails a two-sided test at p = 0.263 (§4b). Presenting it without a band invites a budget increase on noise. Smallest safe fix: attach a Poisson 95% band to every count under 100 in every view — "13 érdeklődő (95% sáv: 6–20)". Decisive retest: confirm the enquiry headline renders its band, and that a reviewer shown 13 vs 7 with the band does not describe it as a proven improvement. **H3 — The two channel result numbers are the same event under two attribution models, and every view invites the reader to divide them.** `measurement risk` Evidence: Google 46 of 49 conversions are `vhk_form_start`; Meta's 14 Results are `VHK_form_start`. Cost per result: Google 92,096 / 49 = **1,880 Ft**; Meta 89,778 / 14 = **6,413 Ft**. A 3.4× gap that is entirely definitional — GA4-imported web conversions under Google's attribution versus a Meta pixel event under Meta's click/view window, on the same underlying user action. Why: this is the single most likely mechanical cause of a wrong reallocation. The naive read is "move budget to Google, it is 3.4× cheaper." The honest read: **total spend rose 59,966 → 181,874 Ft (+121,908 Ft) while recorded enquiries rose 7 → 13 (+6), i.e. roughly 20,300 Ft of incremental spend per incremental recorded enquiry, and blended 13,990 Ft per recorded enquiry** — an order of magnitude away from 1,880 Ft. Label: `hypothesis` / order-of-magnitude sanity check only, because enquiries are not attributable to a channel and the enquiry window is offset by one day at each edge. It is not an attribution claim. It is the number that should frame the conversation, and it appears nowhere. Smallest safe fix: in every view, label both platform numbers `form-start (platform signal)`, show a single blended `cost per recorded enquiry` beneath them marked "not channel-attributable", and never place two per-result costs adjacent without their event names. Decisive retest: show the view to someone with no context and ask which channel is more efficient. The correct response is "you cannot tell from this." **H4 — The comparison Matt asked for cannot reach significance at this budget.** `measurement risk` Evidence and arithmetic: §4b. 28.1 months for a +30% Meta creative test; 1,080 cells for 14 events on the demographic cross-tab. Smallest safe fix: say it to Matt in one sentence before any dashboard work starts, with the months table, and offer the geo/time holdout alternative. Decisive retest: none needed — this is arithmetic. Recompute from `meta_ads.actions` and `ppc.totals` whenever volume changes. **H5 — Eight children were launched from a branch missing 41 files including every one of their inputs, and nothing detected it.** `defect` Evidence: ORCH-CORR-1, re-verified above. `access-ledger.md` records this as a **PASS**: *"private origin fetched; isolated worktree and child branch created from parent commit `ede99a5`"*. Ten ARCH acceptance rows, ten access rows, five handoff transitions — none about input availability. Why: it converted a delegation architecture into an archaeology exercise (see H-cost M3) and would have produced six confidently-wrong artifacts had the run continued. Smallest safe fix: one preflight assertion per child — "every path named in this child's goal exists on this child's branch" — before the goal is frozen. Decisive retest: run that assertion against the eight frozen goals as they stand; it must fail for at least T2 and T3. **H6 — A source can fail and still produce a polished, wrong-looking-correct surface. This already happened, twice, in two different layers.** `defect` Evidence: (a) *Orchestration layer, confirmed:* `run-state.md` reads `Status: ACTIVE` and `T2 is active` while no session runs and six children produced nothing. The status is written by the producer and never invalidated by an observer. (b) *Reporting layer, same pattern:* `report_manifest.json` ships `"complete": false` beside `run_receipt.json` `"complete": true` in the same directory. (c) *Dashboard layer:* `deliverables/fusion-meta-ads-review-2026-08-24/index.html` fetches two JSONs that **do not exist anywhere on this machine**. Its `catch` block writes the error into `#creative-table-body` only. The four headline KPI tiles — `#total-spend`, `#top-share`, `#lead-total`, `#coverage` — are hard-coded to the literal string `Loading` in markup and are never touched on the failure path. A screenshot or PDF of the failed page shows four headline metrics that look like they are about to arrive. (d) *Its test cannot catch this:* `test_dashboard.py` asserts `self.assertIn("meta_ad_insights.json", page)` — that the page **mentions the filename**. It passes on a completely dataless dashboard. Smallest safe fix: in the `catch`, set all four KPI tiles to `"UNAVAILABLE — source failed"`; add one test that serves the page with the sources absent and asserts no tile reads "Loading". Decisive retest: serve the page from a directory without the JSONs and confirm zero tiles read "Loading". **H7 — The monthly refresh is manual and Mac-bound; it cannot run where it is orchestrated.** `defect` + `inefficiency` Evidence: `limitations[0]` — Meta API session invalid `190/467`, figures recovered from a manual authenticated Ads Manager export. `source_health`: four sources `degraded`, two `absent`, one `disabled` — **seven of seven non-green**. Every path in `run_receipt.json` and `ledger.json` points at `/Users/agency/...`. `ads-control/config.yaml` → `credential_source: /Users/agency/.config/riport-30d/clients/fusiontables-ads-client.json`. This is why `ads-control/reports/stage-3-...html`, the report the mission calls "latest evidence-accounted", is `UNAVAILABLE` on devbox. Why: an automation that requires one specific laptop and one human browser session is not an automation, it is a checklist with extra steps. Smallest safe fix: refresh the Meta system-user token and move `credential_source` to an environment-resolved path. Approval-gated (touches credentials), zero spend. Decisive retest: run the report collector on devbox and confirm `meta_api` reads `ok` rather than `blocked_190_467`, with no manual export step. **H8 — The system declared itself not production-ready and shipped a client report anyway.** `defect` / governance Evidence: `client.report_readiness = "gated"`; `readiness_note`: *"Google Ads is verified. GA4, Search Console, exact CRM page, and GA4 allowlists are not verified, so this config is inventory/ API-ready but **not production-report-ready**."* The run then completed all six stages, published to Notion and native Google Slides, and recorded `run_receipt.complete: true`. Why: the gate exists, is correct, and is not enforced. A gate that never blocks is documentation. Smallest safe fix: make `report_readiness != "ready"` add a visible readiness banner to the first page of the report and the deck, naming the unverified sources. Do not block publication — the report is still worth having — but do not let it look complete. Decisive retest: regenerate and confirm the banner appears in `report.md`, the PPTX and the Notion page. ### MEDIUM **M1 — The KPC advice automation adds supervision and removes none.** `inefficiency` Evidence: `kpc_snapshot.advice_summary` = `approve_for_planning: 0`, `investigate_next: 0`, `wait_for_evidence: 61`, `executed: false`. `advice_output-20260824T111713-2aa95a23.json`: 61 rows, `promotion_candidate: None` × 61, `exclusion_candidate: None` × 61, **2 unique `ai_note` values**, 17 rows flagged `needs_attention: true` for `CAMPAIGN_PAUSED`. The pipeline is config → snapshot → bundle export → Sol xhigh advice pass → schema validation → import → regenerate dashboard. Why: an operator must read 61 near-identical rows to learn one fact — Search is paused — that the Google Ads UI shows in one glance on the campaign list. Seventeen `needs_attention` flags for one campaign-level condition is manufactured supervision. Smallest safe fix: collapse to one row when every criterion shares one serving cause: "61 keywords, 0 delivery, cause: CAMPAIGN_PAUSED. No keyword decision available." Decisive retest: rerun the advice import on the same snapshot and confirm the dashboard renders one summary row, not 61. **M2 — The field that would say whether the conversion count is trustworthy is a literal TODO.** `defect` Evidence: `ads-control/config.yaml` → `call_tracking_live_from: 'TODO: ISO date call-conversion tracking went live, e.g. 2026-07-11'`, `reliability: 'TODO: full | partial | none'`, `note: 'TODO: one paragraph on what the conversion count does and does not capture'`. Consequence, in every bundle: `tracking_context.call_tracking: "unknown"`. Smallest safe fix: fill the three fields from the evidence that already exists — `Call (+36309149330)` = 0.0, `Google Forwarding Number` = 0.0, so `reliability: none` for calls today. Decisive retest: regenerate a bundle and confirm `call_tracking` is no longer `"unknown"`. **M3 — T1's cost against its business value.** `inefficiency` Evidence: 555,380 tokens (`dependency-handoff-ledger.md`, `run-state.md`) → 716 lines of Markdown (`find children/t1-evidence-corpus/artifacts -name '*.md' | xargs wc -l` = 716). That is ~776 tokens per delivered line. Net new measurement capability added: **zero**. It reconstructed from transcripts, Notion and 131 Git blobs an index of evidence that existed as `report_data.json` (535,340 bytes) one branch over — because of H5. Fair credit where due: the corpus is *good*. `evidence-matrix.md` is the best single artifact in the repo for preventing overclaim, and its `UNAVAILABLE`-never-zero discipline is what makes the rest of this audit possible. The objection is to its cost and its redundancy, not its quality. Smallest safe fix: none needed retroactively. Forward: never commission an evidence corpus before checking whether the evidence is already a file. Decisive retest: the preflight from H5. **M4 — Control surface and output-format sprawl.** `inefficiency` / `simplification opportunity` Evidence: 61 files and 564 KB under the orchestration directory, of which 53 are child control files across eight five-file packages, to produce 716 lines of output from one of eight children. Separately, the 2026-08-28 run emitted the same six numbers in **eight formats**: `report.md`, `narration.md`/`.txt`, `audio.mp3`, `Fusion-Tables-30d-report-2026-08-23.pptx`, native Google Slides, a private Notion page, `report_data.json`, and a closeout HTML — plus a `.pptx.inspect.ndjson` (37 KB) whose only job is to verify the PPTX. Smallest safe fix: one HTML page plus the Notion page. Drop the PPTX, the native Slides import, the inspect NDJSON and the closeout HTML unless a client actually opens them. Decisive retest: ask which of the eight artifacts anyone opened in the last month. **M5 — The reporting automation cannot state its own cost.** `measurement risk` (on the operating model) Evidence: `ledger.json` → `paid_spend_usd: null`, `provider_cost_status: "not_surfaced"`, `devbox_paid_spend_usd: 0`, `tts_renders: 1`, against a `paid_spend_cap_usd: 12`. Why: you cannot decide whether a monthly automation is worth keeping if it does not record what it costs. The one child that *did* report its usage (T1, 555,380 tokens) is the one whose value is most questionable — and that is not a coincidence, it is the only one you can evaluate. Smallest safe fix: write the run's token and provider cost into `ledger.json` at finalize. Decisive retest: next run's `provider_cost_status` reads a number. **M6 — The requested last-30-vs-prior-30 chart cannot be built from the 60-day snapshot.** `defect` Evidence: KPC window is 2026-06-25..2026-08-23 (60 days) while the reports use 30-day windows and the CRM window is offset by one day at each edge (`windows` in `report_data.json`; `date-account-caveats.md`). The KPC query receipt for `keyword_daily` returns `row_count: 0`, so **the 60-day window cannot be split into two 30-day halves**. `date-account-caveats.md` states it directly: *"No subtraction, trend join, or denominator mixing is valid across them."* Smallest safe fix: drop the 60-day KPC window from any period-over-period view; build the funnel chart solely from `report_data.json`, which already carries matched current/previous 30-day windows for Google, Meta and the CRM. Decisive retest: confirm every bar in the funnel view cites one window from `windows` and no bar mixes two. **M7 — Adding a product or landing page means copying a stack, and the evidence shows it already scaled badly.** `UX problem` / `simplification opportunity` Evidence: adding one product today requires a new prototype page (the `deliverables/fusion-ppc-2026-07-30/public/prototype/{index,rs2,hinomi-x2}.html` pattern — one hand-authored HTML per product), a new sheet worksheet, a new form, a new conversion action, and a new dated deliverable folder (`fusion-ppc-2026-07-30/`, `fusion-ppc-council-2026-07-31/`, `fusion-meta-ads-review-2026-08-24/`, `fusion-static-comment-review-2026-07-30/` — each with its own HTML, scripts and QA; the last carries 16 scripts of its own). The four zero-row worksheets in C4 are what that pattern produced last time: someone added four forms and none of them recorded anything. Smallest safe fix: one page rendering from `report_data.json`, adding a row per campaign/form automatically. No per-product authoring. Decisive retest: add a fictional sixth worksheet to a copy of the CRM fixture and confirm the funnel view gains a row with no code change. **M8 — Which manual approvals earn their friction.** `inefficiency` (mixed verdict) *Keep — genuinely valuable:* - The no-live-mutation gate (`019ff730...`: *"Do not send the email, activate campaigns, increase spend, or make live budget and targeting changes without Matt's explicit approval"*). This is a client's money and PMax will spend more the moment it is allowed to. Non-negotiable. - The T6 publisher blocking on 284 missing mirrored pages (`access-ledger.md`, `PARTIAL`). A publisher that refuses to ship a broken client-facing page is exactly right, and it worked. - The report's "Az ügynök-utasítások másolható tervek. Egyiket sem hajtottuk végre." (the agent instructions are copyable plans; none were executed) — six ready-to-run prompts that deliberately did not run. *Drop — needless friction:* - The T1→T2 handoff ceremony for **read-only** children: parent revalidates 11 frozen rows, 159 derived rows, 153 inventory entries, 131 Git blobs, 11 artifact hashes, six JSONLs, 19 local links, privacy, secret shapes, commit scope and diff hygiene; cherry-picks; closes the runtime goal; queues a release message (`dependency-handoff-ledger.md`). Nothing T2–T7 could produce is irreversible. This gate bought no safety, converted a parallelisable job into a five-transition serial chain, and is precisely where the run died. - `ARCH-02` "Correct child model and reasoning pins", verified by Codex SQLite readback. Process theatre with no business outcome. ### LOW / future ideas **L1 — Offline conversion import is the highest-leverage move in the whole system.** `future idea` With 100% of Google spend in PMax and the only signal a 1 Ft form-start, the bidder is being trained on the wrong outcome (C1, C6). Adding `quote sent` / `quote accepted` / `order value` columns to the same sheet that already needs a source column (C3), and uploading them as offline conversions to Google and Meta, would let Smart Bidding optimise toward revenue. This is what a strong competitor does and it is entirely absent here. It is out of scope for this audit and requires client cooperation, but it is the correct destination. **L2 — Geo or time-based holdout for incrementality.** `future idea` At 181,874 Ft/month, cell-level significance is unreachable (§4b) but a two-cell geo holdout over a quarter is not. It also satisfies Matt's own attribution rule directly. **L3 — Consolidate the eight output formats.** `simplification opportunity` See M4. --- ## 6. The question nobody asked: relaunch, rebuild smaller, or build directly? **Recommendation: build directly — and change what gets built.** Not "relaunch": the eight-child run would resume from branches that still do not contain its inputs (H5), toward artifacts (T3 dashboard, T4A/T4B strategies, T7 targeting pack) that C5 shows the data cannot support. Relaunching buys six confidently-wrong deliverables. Not "rebuild smaller" as a first move either, and this is where ORCH-CORR-2 changed my answer. Rebuilding the delegation smaller still points the work at a dashboard, and **the dashboard is not the binding constraint.** Three things are, in this order: 1. **The conversion signal** (C1, C2). Both platforms optimise toward a form-start. Until a submitted lead is the Primary action, better reporting only describes a misdirected budget more precisely. 2. **The CRM source column** (C3). `source_column: null`. Until it exists, no view can attribute a single enquiry to a single channel, so no dashboard can answer "where should the budget go." 3. **The account structure** (C5). One enabled Google campaign and one Meta campaign is not a portfolio, and PMax withholds most dimensions Matt named. Until there is something to compare, a comparison view renders one-row tables. **Weighed against Matt's verbatim** *"give me a more consice prompt. i need the 80/20. dont overengineer"* (`01a04df6...`, T0006 line 107): what was built was 61 control files, 564 KB of orchestration, eight Codex tasks, five ledgers, a `launch_child.py`, a five-transition serial dependency chain and 555,380 tokens — producing zero dashboards and zero new measurement. The 80/20 he asked for is three small things: fix the conversion action, add the source column, and draw one honest funnel page from a JSON file that already exists. **What to build directly, now (hours, not children):** one static HTML page reading `report_data.json`. Everything it needs is already in that file — `windows` (matched current/previous 30-day windows for Google, Meta and CRM), `ppc.totals`, `meta_ads.actions`, `crm.sources`, `source_health`, `limitations`. It draws: - one funnel per channel, current 30 vs prior 30: impressions → clicks → landing-page views (Meta only) → form-starts, every bar labelled with its event name; - one shared, explicitly non-attributable enquiry bar (13 vs 7) with its 95% Poisson band; - a visible `UNAVAILABLE` wall for qualified leads, quotes, purchases and revenue, listing what would make each one appear; - all five enquiry worksheets including the four zeros (C4); - no ROAS (C6), no percentage off a base under 10 (H1), no adjacent per-result costs without event names (H3). This is Matt's requested chart, honestly. It also happens to be the artifact that makes constraints 1–3 undeniable to both Matt and the client, which is why it should be built *before* they are fixed, not after. **Explicit sequencing — what must be true before a comparison dashboard is worth building:** | Gate | Condition | Verified by | | --- | --- | --- | | G1 | Exactly one Primary conversion action, mapping to a submitted enquiry, not a form-start | `conversion_action.primary_for_goal` readback | | G2 | `crm.source_column` is non-null and populated for ≥90% of new rows | one 30-day report showing enquiries split by channel | | G3 | `Submit lead form` conversion count is within an order of magnitude of recorded enquiries | 30 days after G1 | | G4 | Meta API session valid (not 190/467) and the collector runs unattended on devbox | `source_health.meta_ads` reads `ok` | | G5 | ≥6 comparable units (campaigns / ad sets / creatives) with clicks > 0, and ≥30 conversions per unit | count from `ppc.campaigns` + `meta_ads.campaigns` | | G6 | Declared MDE the budget can reach, published next to every comparison | §4b table regenerated at current volume | **Until G5 and G6, building the creative/placement/demographic comparison Matt asked for is not under-delivery — it is the responsible answer.** Say so plainly and show him the months table. **Keep exactly one thing from the delegation apparatus:** the evidence-labelling discipline — `UNAVAILABLE` never rendered as zero, grains labelled, windows never joined, platform events never called leads. `evidence-matrix.md` and `date-account-caveats.md` are the best artifacts in this repo and they are why this audit could reach firm conclusions. Port those rules into the page. Discard the machinery around them. --- ## 7. Is the monthly workflow simpler than opening Google Ads and Meta Ads Manager directly? **Honestly: no. Not today.** - Google side: one enabled PMax campaign. Its spend, clicks, conversions and asset labels are three clicks away in the Ads UI, live. The KPC pipeline instead runs config → snapshot → bundle → Sol xhigh advice → validation → import → dashboard regeneration to produce 61 rows that all say "no keyword decision available" about paused campaigns (M1). The Ads UI shows `PAUSED` on the campaign list instantly. - Meta side: the API session is dead (190/467) and the figures came from a **manual** authenticated Ads Manager export (`limitations[0]`). If a human is opening Ads Manager anyway, the custom layer adds steps rather than removing them. - Everything is bound to one Mac (H7). **What the native UIs genuinely cannot do — and where the custom layer could earn its place:** 1. **Join platform events to the client's enquiry register, quotes and revenue.** Ads Manager will never see the Google Sheet. This is the whole justification for a custom layer — and it is exactly what the system does not do, because `source_column` is null (C3). 2. **Enforce the epistemic discipline.** No native UI will tell you the Results column is a form-start and not a lead, or that your prior period had 11 delivery days. The report already does both, in `meta_browser_receipt.json` and `source_health`. That is real value the platforms do not provide. **What would have to be true for the answer to become yes:** G1–G4 above, plus the layer must own the join in (1) and cost less than fifteen minutes in two browser tabs. Today it owns neither, and it costs an unmeasured amount (M5). --- ## 8. What a strong competitor's system would do better 1. **Stamp the source at submit.** `gclid`/`fbclid`/`utm_*` into the enquiry row. Roughly thirty minutes. Unlocks funnel steps 7–14 (§1). This system has a `source_column: null` and eight children commissioned downstream of it. 2. **Feed outcomes back to the bidder.** Offline conversion import of quote-sent / quote-accepted / order-value so PMax bids toward revenue instead of form-starts (L1). This is the structural gap: the measurement defect is not only describing the wrong thing, it is *buying* the wrong thing. 3. **Refuse the segmentation the budget cannot support**, and say why with the months table (§4b), rather than shipping cells with single-digit or zero events. 4. **Report period-over-period only against a full comparable base**, with confidence bands on every count under 100 (H1, H2). 5. **Use holdouts for incrementality** at this spend level (L2). 6. **One live view, refreshed unattended**, instead of eight artifacts of the same six numbers produced by hand on one laptop (M4, H7). Where this system is already ahead of a typical competitor, and should not lose it: the grain discipline, the `UNAVAILABLE`-never-zero rule, the "Mit ne állítson" (what not to claim) slides in `deck.html`, and the report's explicit refusal to call 49 platform conversions 49 leads. --- ## 9. Can a client understand performance without the agency overclaiming? Partly, and the parts that work are worth keeping. **Working:** `report.md` states *"A 49 konverzió platformon rögzített jelzés, nem igazolt érdeklődő és nem árbevétel"* (the 49 conversions are a platform signal, not a verified enquiry and not revenue) and *"A Meta eredményoszlopa formindítási eseményt használ, amely nem bizonyítja a sikeres beküldést"* (Meta's results column uses a form-start event, which does not prove a successful submission). The "Mérési korlátok" section lists five limitations plainly. `deck.html` gives Matt a "Mit ne állítson" block per slide. This is better than most agency reporting. **Not working:** the numbers a client's eye lands on contradict the caveats beneath them. `+4800,0%` conversions. `+85,7%` enquiries at p = 0.263. `+190,9%` Meta spend against an 11-delivery-day base. And the most important fact — four new forms, thirty days, zero enquiries — is absent because it is a zero (C4). A client reading this report would come away believing paid media is working well and the new site is contributing. Neither is established. Against Matt's own rule — *"Do not claim Google Ads attribution until the conversion increment is visible"* — the report complies in prose and violates it in the tables. --- ## 10. What can be removed while improving the experience | Remove | Replace with | Evidence it is safe to remove | | --- | --- | --- | | The 61-row keyword advice surface | One line: "Search and Display are paused; 100% of Google spend is one PMax campaign" | `advice_summary`: 0 approve, 0 investigate, 61 wait | | The eight-child orchestration apparatus | One page built directly from `report_data.json` | 61 control files, 564 KB, 7 of 8 deliverables never produced | | The T1→T2..T7 dependency gates for read-only children | Parallel launch with an input-existence preflight | Nothing downstream was irreversible; the gate is where the run died | | The 60-day KPC window in any trend view | The matched 30-day windows already in `report_data.json` | `keyword_daily` `row_count: 0`; the 60-day window cannot be split | | PPTX + native Slides + inspect NDJSON + closeout HTML | The HTML page and the Notion page | Eight formats of six numbers (M4) | | Percentage columns off bases under 10 or partial periods | Absolute counts with Poisson bands | `+4800,0%`; Meta prior = 11 delivery days | | `roas` and placeholder `conversion_value` | `N/A — revenue unavailable` | `roas: 0.000532`, value == count | --- ## 11. Limitations of this review - Read-only. No live Ads, Meta, GA4, CRM, WordPress or staging state was queried; every figure comes from artifacts already on disk. Current account state may differ from the 2026-08-23 window. - `ads-control/reports/stage-3-20260824T111713-2aa95a23.html`, the *rendered* KPC dashboard, is `UNAVAILABLE` on this host. I judged the template (`ads-control/template/stage-3-ai-advice-review.html`), its config and its data bundles, not the rendered page. Its five section headings are known; its rendered behaviour is not. - The Meta creative dashboard could not be executed with data, because its two source JSONs do not exist on this host. Its failure behaviour was read from source, not observed in a browser. - The 20,318 Ft "per incremental recorded enquiry" and 13,990 Ft "blended per recorded enquiry" figures in H3 are `hypothesis` / order-of-magnitude sanity checks, **not** attribution claims: enquiries carry no source column and the enquiry window is offset by one day at each edge from the ads window. - Statistical figures in §4b are standard two-proportion power calculations at α = 0.05 two-sided, 80% power, using this window's observed rates. They are planning estimates, not claims about any test that was run. - Twelve Mac-local handoff files, the audio render, and older Mac-local report sources remain `UNAVAILABLE` and were not assumed to contain anything. - Personas are an analytical device. Every challenge above is anchored to a path, a field or a measured absence; nothing rests on the persona framing.