## EVIDENCE STATE Mode: EVIDENCE. I can inspect the supplied head markup and buyer-declared loading rules. I did not run DevTools, capture network requests, measure performance, inspect vendor dashboards, or verify runtime consent behavior. ## SCRIPT PROVENANCE LEDGER | Integration | Evidence | Load form | Trigger finding | Status | |---|---|---|---|---| | Chat widget | external head script | parser-blocking by markup | page-load eligible despite rule requiring Help interaction | CONFIRMED | | Analytics | external script with `defer` plus inline queue write | deferred library + immediate queue mutation | no supplied consent gate | VERIFY | | Experiment SDK | external `async` script | async | page-load eligible; relative execution order is not guaranteed | CONFIRMED | | Marketing pixel | external script plus immediate `pixel.track('PageView')` | blocking + immediate call | appears before any supplied marketing-consent gate | MISMATCH | | Captcha | external script with `defer` | deferred | globally loaded although buyer states it is used only on `/signup` | MISMATCH | Vendor purpose is taken only from the supplied rules and identifiers; no legal or consent-category determination is being inferred independently. ## EXECUTION ORDER GRAPH From the supplied markup: HTML parse → chat script encountered and eligible to download/execute → analytics script scheduled with `defer` → experiment SDK scheduled with `async` → analytics queue initialized and receives `pageview` → pixel library encountered and eligible to execute → `pixel.track('PageView')` → captcha script scheduled with `defer` Important uncertainty: markup shows eligibility and ordering structure, not proof of actual downstream requests or measured blocking time. ## POLICY FENCE **Chat after Help:** MISMATCH The chat loader is present in the initial head path rather than behind the declared Help interaction. **Marketing after matching consent:** MISMATCH The pixel loader and immediate PageView call appear without a supplied marketing-consent guard. **Analytics after matching consent:** VERIFY The analytics library is deferred, but the supplied evidence contains no consent gate. The queue write alone does not prove when data is transmitted. **Captcha only where needed:** MISMATCH The captcha loader appears on the homepage although the buyer states it is needed only on `/signup`. **Checkout/navigation independent of third parties:** VERIFY No supplied code shows those flows depending on these integrations, but runtime independence has not been tested. ## BLAST-RADIUS MAP **Chat widget — DEGRADED / possible blocking exposure** Because it is a normal head script, vendor delay could affect parsing at that point. Actual delay is unknown. **Analytics — UNKNOWN** The supplied evidence does not establish whether analytics initialization affects first-party behavior. **Experiment SDK — DEGRADED risk** `async` prevents parser blocking, but any first-party code that assumes the SDK exists could still create order-dependent failure. No such dependency is supplied. **Marketing pixel — policy-control failure** The strongest evidenced issue is premature initialization relative to the buyer's rule. **Captcha — unnecessary global dependency** Its stated functional scope is `/signup`, yet its loader is present on the homepage. ## CONTROL PLAN ### 1. Create one first-party loader boundary per integration Replace direct global loading with small first-party loader functions so trigger logic, failure handling, and kill switches have a single ownership point. Preserve each vendor's required initialization parameters. ### 2. Gate the marketing pixel Do not load the pixel or call `PageView` until the buyer's marketing-consent signal is true. Kill switch: `marketingPixelEnabled = false` When disabled, the first-party page must continue functioning normally. ### 3. Lazy-load chat after Help interaction Move chat loading behind the Help action. Failure fallback: keep a first-party support link or equivalent buyer-approved Help path available when the vendor cannot initialize. Kill switch: `chatEnabled = false` ### 4. Scope captcha to `/signup` Remove homepage eligibility and load captcha only when the signup surface that needs it becomes active. Kill switch: `captchaEnabled = false` Do not disable captcha in production flows where it is actually required without confirming the product/security requirement. ### 5. Hold analytics for verification Do not assume `defer` satisfies the consent rule. First identify: - what buyer consent signal controls analytics; - whether the queue may exist before consent; - when the first vendor request actually occurs. Only then choose the loading gate. ### 6. Keep experimentation isolated No supplied evidence proves the experiment SDK should be removed or deferred further. Preserve it provisionally while checking whether any first-party startup path assumes that global exists. ## ROLLBACK Implement each integration change independently. Keep the previous loading path recoverable in version control or behind a temporary migration flag so one vendor can be reverted without restoring every global script. Do not combine chat, captcha, analytics, pixel, and experiment changes into one irreversible migration. ## VERIFICATION PROBES ### Initial load before consent Verify: - no marketing-pixel request; - no chat request; - no captcha request on the homepage; - whether analytics sends any request before its allowed consent signal. ### After marketing consent Verify: - the pixel loads once; - one intended PageView path occurs; - repeated consent-state updates do not duplicate initialization. ### Help interaction Verify: - chat is absent before Help; - Help triggers one initialization; - repeated Help actions do not inject duplicate loaders. ### `/signup` Verify: - captcha is absent from unrelated routes; - captcha loads where required; - signup retains its expected behavior. ### Vendor failure Block each non-critical vendor origin independently and verify first-party navigation and checkout remain usable. ### Kill switches Disable each integration independently and verify the corresponding vendor request disappears without breaking core UI. These probes are required verification steps; they have not been run. ## CLAUDE HANDOFF Refactor third-party loading only. Centralize loader ownership. Gate the marketing pixel behind the buyer-declared marketing-consent signal. Load chat only after Help interaction. Scope captcha to `/signup`. Keep analytics provisional until its real pre/post-consent request behavior is known. Preserve required initialization parameters and existing first-party behavior. Add independent reversible kill switches for non-critical integrations. Do not redesign the UI, invent consent categories, remove experimentation without evidence, or claim performance improvements before browser/network verification. ## RECOVERY PATH Highest-information next evidence: a request-domain or Network capture covering: 1. initial page load before consent; 2. each relevant consent transition; 3. Help interaction; 4. `/signup`. That will resolve the largest remaining uncertainty: which supplied loaders actually create downstream requests and when.