ceo-orchestration 1.0.0

package/.claude/skills/domains/paid-media/skills/tracking-specialist/SKILL.md

@@ -0,0 +1,457 @@
+---
+name: tracking-specialist
+description: >
+  Ad-tracking and measurement engineering discipline covering pixel
+  deployment, GA4 / Meta CAPI / TikTok Events API server-side tracking,
+  consent-mode v2, cross-domain identity stitching, conversion-value
+  modeling, and data-quality assurance. Produces tracking architectures
+  grounded in event taxonomy, PII-safe signal collection, and dual-deploy
+  redundancy rather than platform self-reporting assumptions. Use when:
+  designing or auditing a pixel deployment plan, diagnosing conversion-count
+  discrepancies between ad platforms and analytics, implementing server-side
+  tagging on GA4 Measurement Protocol, Meta CAPI, or TikTok Events API,
+  configuring consent-mode v2 with per-region defaults, building cross-domain
+  linker or identity-graph stitching, modeling conversion value with LTV or
+  margin weighting, or establishing event-volume alarms and dedup-audit cadences.
+owner: Marlena Voss (Tracking Specialist, domain persona)
+tier: domain:paid-media
+scope_tags: [tracking, server-side-tagging, ga4, meta-capi, consent-mode, conversion-modeling, data-quality]
+inspired_by:
+  - source: msitarzewski/agency-agents/paid-media/paid-media-tracking-specialist.md@783f6a72bfd7f3135700ac273c619d92821b419a
+    license: MIT
+    relationship: structural_inspiration
+    authored_by: ceo-orchestration framework
+    authored_at: 2026-05-07
+# --- smart-loading fields (PLAN-083 Wave 0b sub-agent 0.7c) ---
+domain: paid-media
+priority: 8
+risk_class: low
+stack: []
+context_budget_tokens: 500
+inactive_but_retained: true
+repo_profile_binding:
+  frontend: {active: false, priority: 10}
+  engine: {active: false, priority: 10}
+  fintech: {active: false, priority: 10}
+  trading-readonly: {active: false, priority: 10}
+  generic: {active: false, priority: 10}
+activation_triggers: []
+# --- K1 paths: native file-touch activation (PLAN-135 W3 unit k1a) ---
+paths:
+  - "**/tracking/**"
+  - "**/pixels/**"
+  - "**/gtm/**"
+  - "**/capi/**"
+---
+
+# Tracking Specialist
+
+## Cardinal Rule
+
+An untested pixel is a guess; an unmonitored pixel is a guess that
+decays into broken without notice. Every conversion signal feeding a
+bidding algorithm MUST be verified at the event level — not at the
+campaign summary level — before it is treated as authoritative. A 5%
+mismatch between platform-reported conversions and CRM ground truth
+does not round to acceptable; it compounds into miscalibrated bids,
+distorted attribution models, and budget misallocation that accumulates
+silently. Measurement is not a launch task; it is an ongoing operational
+discipline with defined alarm thresholds, scheduled dedup audits, and a
+documented escalation path when signal quality degrades.
+
+---
+
+## Fail-Fast Rule
+
+A pixel deployment MUST NOT proceed to production if the following gates
+have not passed: (1) the event taxonomy is fully specified before any
+tag fires — parameter schema, dedup key assignment, and value-currency
+pairs documented for every tracked event; (2) PII redaction has been
+confirmed at the source — no hashed or unhashed personally identifiable
+data may travel in URL parameters, `document.referrer`, or custom
+dimensions without explicit redaction review; (3) a QA protocol has been
+executed in a staging environment using the platform's native debug tool
+(GA4 DebugView, Meta Events Manager test mode, TikTok Event Tester) AND
+an independent network-request inspection; (4) deduplication logic via
+`event_id` has been implemented and verified when both browser-side and
+server-side paths fire the same event. If any gate fails, deployment is
+blocked until the condition is remediated.
+
+---
+
+## When to Apply
+
+Activate this skill when the work involves any of the following:
+
+- Designing a pixel deployment plan for a new site launch, redesign, or
+  major campaign infrastructure build.
+- Diagnosing conversion-count discrepancies between ad platforms (GA4,
+  Google Ads, Meta Ads Manager, TikTok Ads) and CRM or backend records.
+- Implementing or migrating to server-side tracking via GA4 Measurement
+  Protocol, Meta Conversions API, or TikTok Events API.
+- Configuring consent-mode v2 signals — `ad_user_data`,
+  `ad_personalization` — with per-region defaults for LGPD, GDPR, CCPA,
+  and DMA jurisdictions.
+- Auditing an existing tag container for PII leakage, consent gaps,
+  duplicate event fires, or missing dedup keys.
+- Building cross-domain tracking via linker parameters or first-party
+  cookie domain configuration.
+- Modeling conversion value with revenue, margin, LTV-weighted, or
+  offline-upload enrichment.
+- Establishing event-volume monitoring, trend-anomaly alarms, and browser-
+  versus-server comparison baselines.
+
+---
+
+## Pixel Deployment Discipline
+
+Pixel deployment without a preceding taxonomy document produces
+unmeasurable technical debt. The taxonomy MUST be established before
+any tag fires.
+
+**Event taxonomy before deployment:**
+
+For every tracked event, the taxonomy document MUST specify: event name
+(snake_case, platform-canonical where applicable); required and optional
+parameters with data types; the dedup key field (`event_id` or platform
+equivalent) and its generation method; currency and value fields with
+units; the trigger condition and data layer source; and the responsible
+tag-management container workspace.
+
+Events not present in the taxonomy document MUST NOT be deployed.
+Taxonomy additions require a documented change record referencing the
+campaign or product requirement that motivated the addition.
+
+**PII redaction at source:**
+
+PII — email addresses, phone numbers, full names, government identifiers
+— MUST NOT appear in plaintext in tag payloads, URL parameters,
+`document.referrer`, or GTM variables. When enhanced-conversion or CAPI
+matching requires hashed PII, hashing MUST occur server-side or in a
+trusted container execution environment, never in client-side JavaScript
+that exposes the pre-hash value to the network layer. SHA-256 with
+normalization (lowercase, trimmed) is the platform-standard hash
+function; do not substitute MD5 or SHA-1.
+
+**Deduplication via event_id:**
+
+When both browser-side and server-side paths fire the same event, the
+same `event_id` value MUST be present in both payloads. The `event_id`
+MUST be generated once — in the data layer push or server-side event
+constructor — and passed through to both paths. Generating independent
+random IDs per path produces double-counting that platform dedup logic
+cannot resolve.
+
+**No deployment without QA:**
+
+QA is a blocking gate, not a post-deployment check. QA MUST cover:
+(a) native platform debug tool confirmation of event receipt with correct
+parameters; (b) network-request inspection to confirm no PII in
+plaintext; (c) consent-off state test — with consent denied, no tracking
+tags MUST fire; (d) cross-browser smoke test for at minimum Chrome and
+Safari (ITP behavior diverges).
+
+---
+
+## Server-Side Tracking
+
+Server-side tracking is mandatory — not advisory — in three conditions:
+(1) the conversion event involves sensitive transaction data (financial,
+health, regulated); (2) client-side signal loss due to browser
+restrictions (Safari ITP, Firefox ETP) exceeds 15% of measured events
+in a 30-day baseline; (3) a compliance review has flagged client-side
+third-party cookies as non-compliant with the applicable privacy regime.
+
+**GA4 Measurement Protocol:**
+
+The Measurement Protocol sends events directly from a trusted server to
+the GA4 collection endpoint using the API secret and measurement ID.
+Use cases: purchase confirmation events where the authoritative source
+is the backend transaction record; offline conversion imports; server-
+to-server enrichment with CRM data unavailable client-side. Limitations:
+Measurement Protocol events do not participate in session stitching
+unless `client_id` and `session_id` are forwarded from the client-side
+cookie; always forward both. Measurement Protocol events are not
+real-time in DebugView; use the `debug_mode: true` parameter for QA.
+
+**Meta Conversions API (CAPI):**
+
+Meta CAPI sends events from server or cloud to the Meta Graph API
+endpoint. CAPI is mandatory when: campaign objectives include
+purchase or lead events and iOS 14.5+ signal loss has been confirmed
+above 20% in Event Match Quality diagnostics; or when the account
+operates under LGPD or GDPR and requires server-side consent signal
+propagation. Event Match Quality (EMQ) score below 6.0 MUST trigger
+a remediation review — common causes are missing `fbp`/`fbc` cookie
+passthrough, missing hashed email, and incorrect event dedup timing.
+Dual-deploy (browser Pixel + CAPI for the same event) is the
+recommended redundancy model; dedup via matching `event_id` values
+is required, not optional.
+
+**TikTok Events API:**
+
+TikTok Events API (server-side) is the mirror of the browser Pixel for
+environments where ITP/ETP signal loss is material or where transaction
+events require server authoritative data. The API requires: `pixel_code`,
+`event_name` (TikTok canonical names), `timestamp` (ISO 8601 UTC),
+`context.user` hashed identifiers (`sha256_email`, `sha256_phone`),
+and `event_id` for dedup. Dual-deploy with browser Pixel and Events API
+requires matching `event_id`; TikTok dedup is event-name scoped, not
+account-scoped, so `event_id` uniqueness within event-name namespace is
+sufficient. EMQ equivalent is TikTok's "Match Rate" in Events Manager.
+
+**First-party versus third-party cookie context:**
+
+Server-side tagging using a first-party subdomain (e.g.,
+`collect.example.com`) sets cookies in a first-party context, bypassing
+ITP lifetime caps on third-party cookies. This is the primary mechanism
+for extending `_fbp`, `_ga`, and `ttclid` cookie persistence. The
+server-side container must NOT set cookies for domains other than the
+publisher's own registered domain; doing so reverts to third-party
+context and negates the ITP mitigation.
+
+**Signal redundancy via dual-deploy:**
+
+Dual-deploy — parallel browser-side and server-side event firing —
+provides redundancy against client-side signal loss without requiring
+full migration. The browser path fires immediately on user action
+(lower latency, participates in session stitching); the server path
+fires on backend confirmation (authoritative value, unaffected by
+ad-blockers). Both paths MUST carry the same `event_id`. Volume
+reconciliation between browser and server counts must be part of the
+weekly data-quality review.
+
+---
+
+## Consent Mode
+
+Consent mode is the mechanism by which measurement and personalization
+tags respect user consent decisions without requiring tag blocking.
+Consent mode v2 introduced two additional signals that MUST be
+implemented for compliance with DMA (Digital Markets Act) requirements
+and are recommended for LGPD and GDPR.
+
+**v2 schema:**
+
+| Signal                 | Scope                                                      |
+|------------------------|------------------------------------------------------------|
+| `ad_storage`           | Cookie-based ad targeting and remarketing storage          |
+| `analytics_storage`    | Cookie-based analytics measurement storage                 |
+| `ad_user_data`         | Sending user data to Google for ad purposes                |
+| `ad_personalization`   | Personalised advertising (remarketing audiences)           |
+| `functionality_storage`| Cookies required for site functionality                    |
+| `security_storage`     | Cookies required for security and fraud detection          |
+
+**Granularity and v2 minimum requirements:**
+
+`ad_user_data` and `ad_personalization` are the v2-new signals.
+Implementations that set only `ad_storage` and `analytics_storage`
+without propagating `ad_user_data` and `ad_personalization` are
+non-compliant with DMA obligations for Google's designated services.
+All four ad-related signals MUST be updated simultaneously when consent
+state changes; partial updates produce undefined platform behavior.
+
+**Consent flag propagation server-side:**
+
+Server-side containers MUST receive and forward consent signals from
+the client. The consent payload from the browser (typically from the
+CMP dataLayer push) MUST be serialized and passed as a query parameter
+or request header to the server container on each event call.
+Server-side tags MUST NOT fire if the forwarded consent state denies
+`ad_storage` for ad tags or `analytics_storage` for analytics tags.
+
+**Per-region defaults:**
+
+| Region             | Default state (pre-consent) | Notes                                            |
+|--------------------|------------------------------|--------------------------------------------------|
+| EEA / UK (GDPR)    | `denied` for all ad signals  | Explicit opt-in required before any signal fires |
+| Brazil (LGPD)      | `denied` for ad signals      | Legitimate interest basis does not apply to behavioral targeting |
+| United States      | `granted` default permitted  | CCPA opt-out model; flip to `denied` on GPC signal |
+| DMA designated     | `denied`; v2 signals mandatory | `ad_user_data` + `ad_personalization` required  |
+| Other jurisdictions| Consult legal; default `denied` is safest posture | —                        |
+
+Default state must be set in the tag container initialization before
+any user interaction; do not rely on CMP latency to block tags.
+
+---
+
+## Cross-Domain Stitching
+
+Cross-domain tracking preserves session continuity and attribution when
+a user journey spans two or more distinct registered domains (e.g.,
+a marketing site and a checkout domain).
+
+**Linker parameter handoff:**
+
+GA4 cross-domain tracking appends a `_gl` parameter to outbound links
+and form actions. The receiving domain extracts `client_id` and
+`session_id` from the linker parameter, overriding any existing cookie
+values to maintain session continuity. Configuration requires: listing
+all destination domains in the GA4 tag's cross-domain settings; enabling
+auto-linking for outbound links; verifying that the receiving page does
+not strip query parameters before GA4 fires.
+
+**Cookie-domain configuration:**
+
+The `_ga` cookie MUST be scoped to the top-level registered domain
+(`.example.com`), not to the hostname (`www.example.com`), to be
+readable across subdomains. Misconfigured cookie domain produces
+phantom new sessions for users navigating between subdomains on the
+same property. Audit cookie-domain scope with browser DevTools before
+any cross-domain or cross-subdomain measurement claim is accepted.
+
+**Identity graph for logged-in users:**
+
+For authenticated user journeys, the server-side identity graph provides
+deterministic cross-domain stitching without reliance on linker
+parameters or third-party cookies. Map the authenticated `user_id`
+(a non-PII stable internal identifier) to `client_id` at login time;
+propagate `user_id` in all server-side event payloads. This provides
+consistent attribution across device switches and browser cookie resets.
+
+**Never use email-as-key in URL:**
+
+Email addresses MUST NOT appear in URL parameters used for cross-domain
+identity handoff, even in hashed form. URL parameters are logged in
+server access logs, browser history, and referrer headers propagated
+to third-party resources. If deterministic cross-domain identity is
+required before authentication, use a short-lived, server-issued opaque
+token with a TTL of ≤10 minutes, invalidated after first use.
+
+---
+
+## Conversion Value Modeling
+
+Conversion value modeling replaces nominal event counts with
+economically meaningful signals that better calibrate automated bidding
+toward business outcomes.
+
+**Revenue, margin, and LTV-weighted value:**
+
+Revenue-based value (transaction amount) is the baseline. Margin-based
+value adjusts revenue by product-category gross margin to prevent
+bidding algorithms from optimizing toward high-revenue but low-margin
+SKUs. LTV-modeled value multiplies the transaction by a cohort-level
+predicted lifetime value multiplier, directing spend toward customer
+segments with demonstrated retention. All three value models MUST
+be documented with their derivation formula and refresh cadence; stale
+LTV multipliers (older than 90 days without recalibration) MUST be
+flagged in the data-quality review.
+
+**Offline conversion uploads:**
+
+Offline conversions (CRM close-won, phone sale, in-store transaction)
+MUST be uploaded via platform APIs — Google Ads Enhanced Conversions for
+Leads API, Meta Offline Conversions API — with the original click
+identifier (`gclid`, `fbclid`) preserved in the CRM record at lead-
+capture time. Upload cadence MUST be within 24 hours of conversion event
+to remain within the attribution window for the bidding algorithm.
+GCLID matching rate below 80% requires investigation; common causes are
+CRM identifier field truncation, URL-parameter stripping by landing page
+redirects, and delayed first-page-load tag fire.
+
+**SKAdNetwork conversion-value schema for iOS:**
+
+For iOS app campaigns, SKAdNetwork limits post-install measurement to a
+6-bit conversion value (0–63). The conversion-value schema MUST map
+the 64 possible values to distinct user actions or revenue bands,
+prioritizing the highest-value signals in the upper range. Schema design
+MUST account for: first meaningful action within the measurement window
+(typically 24–72 hours); revenue tiering aligned to LTV segments;
+and fine/coarse value hierarchy introduced in SKAdNetwork 4.0 for
+larger install cohorts. Schema changes require a full regression test
+against historical install cohorts before deployment.
+
+---
+
+## Data Quality Assurance
+
+Data quality is not a one-time launch check; it is a recurring
+operational discipline with defined thresholds, alarm mechanisms,
+and audit cadences.
+
+**Event-volume alarms:**
+
+For each tracked conversion event, establish a rolling 7-day baseline
+volume. Alarm thresholds: WARNING at ±20% deviation from baseline;
+CRITICAL at ±40% deviation or total event count of zero for any 4-hour
+window during campaign-active hours. Alarms MUST route to a named
+owner, not a shared inbox; unacknowledged CRITICAL alarms escalate to
+campaign pause within 2 hours.
+
+**Trend-anomaly detection:**
+
+Week-over-week trend deviation above 30% in event volume or conversion
+rate MUST trigger a root-cause investigation before the signal is used
+in optimization decisions. Seasonal patterns MUST be documented and
+annotated in the analytics view so that expected seasonal variation is
+not misclassified as a tracking failure.
+
+**Browser-versus-server comparison:**
+
+For dual-deploy deployments, the ratio of browser-path events to
+server-path events MUST be monitored continuously. The expected ratio
+depends on the estimated client-side signal-loss rate; deviations of
+more than 15 percentage points from baseline MUST be investigated.
+A browser count significantly exceeding the server count suggests
+server-path failures; a server count significantly exceeding the browser
+count suggests dedup-logic failures producing double-count on the server.
+
+**Dedup audit cadence:**
+
+Deduplication effectiveness MUST be audited monthly. Audit method:
+pull event-level logs for a 7-day window; count events with duplicate
+`event_id` values across browser and server paths; dedup failure rate
+above 2% requires immediate fix. For Meta CAPI, review the "Deduplicated
+Events" metric in Events Manager diagnostics; a deduplicated rate above
+5% indicates `event_id` generation or transmission failures.
+
+**Success thresholds:**
+
+| Metric                                  | Minimum acceptable | Strong signal |
+|-----------------------------------------|--------------------|---------------|
+| Platform-vs-analytics discrepancy       | <5%                | <3%           |
+| Enhanced-conversion / CAPI match rate   | ≥65%               | ≥75%          |
+| CAPI dedup failure rate                 | <5%                | <2%           |
+| GCLID offline-upload match rate         | ≥80%               | ≥90%          |
+| Consent-mode tag compliance             | 100%               | 100%          |
+| Event-volume alarm acknowledgment       | ≤2 h for CRITICAL  | ≤30 min       |
+
+---
+
+## Anti-patterns
+
+| Anti-pattern                          | Failure mode                                                                    | Correct behaviour                                                               |
+|---------------------------------------|---------------------------------------------------------------------------------|---------------------------------------------------------------------------------|
+| PII in pixel payload                  | Email, phone, or name in plaintext in tag parameters or URL; regulatory exposure | Hash server-side (SHA-256 normalized); never expose pre-hash value client-side  |
+| No consent gating                     | Tags fire before consent decision; GDPR/LGPD/DMA violation                     | Default all ad signals to `denied`; fire only on explicit opt-in CMP signal    |
+| Single-source measurement             | Platform self-reporting trusted without independent verification                | Cross-reference ad platform, analytics, and CRM on a defined weekly cadence    |
+| No QA cadence                         | Tracking regression accumulates silently; discovered weeks later via budget waste | Monthly dedup audit + event-volume alarms + post-deploy regression checklist   |
+| Duplicate `event_id` per path         | Dedup fails; double-counting corrupts conversion totals and bid calibration     | Generate `event_id` once in data layer; forward same value to all downstream paths |
+| URL-parameter email for cross-domain  | PII exposed in server logs, referrer headers, and browser history               | Use short-lived server-issued opaque token; TTL ≤10 min, single-use            |
+| Stale LTV multipliers                 | Bidding algorithm optimizes toward historical cohort value, not current         | Recalibrate LTV multipliers on a maximum 90-day cadence; flag stale values in QA |
+| Missing `client_id` in Measurement Protocol | Server events create phantom new users; session metrics destroyed          | Forward `client_id` and `session_id` from client cookie on every MP event     |
+
+---
+
+## Cross-References
+
+- `domains/paid-media/skills/ppc-strategist` — Google Ads conversion
+  action hierarchy, enhanced conversions configuration, GCLID lifecycle
+  management, and offline conversion import integration with paid search
+  campaigns.
+- `domains/paid-media/skills/paid-social-strategist` — Meta Pixel and
+  CAPI event strategy, TikTok Events API for paid social campaigns,
+  attribution-window policy for social conversion events.
+- `core/compliance-lgpd` — LGPD Article 7 lawful bases for tracking,
+  consent collection requirements, data-subject rights obligations
+  relevant to pixel and identity-graph data, and DPA notification
+  procedures for measurement incidents involving personal data.
+
+---
+
+## ADR Anchors
+
+- **ADR-058** — Creative authorship and structural-inspiration licensing
+  policy; governs `inspired_by` attribution requirements for domain skill
+  files derived from upstream open-source agent corpora.

package/.claude/skills/domains/paid-media/task-chains.yaml

@@ -0,0 +1,121 @@
+# Task chains — Paid Media Squad
+# Domain-specific workflows that extend the universal .claude/task-chains.yaml.
+
+task_chains:
+  - id: paid-media-launch-new-channel
+    title: "Launch a new paid channel or platform (full pre-flight)"
+    whenToUse: |
+      A new paid advertising channel is being added to the media mix for the
+      first time — examples: first TikTok Ads campaign, first LinkedIn Ads
+      campaign, first programmatic DSP activation. Also applies when a
+      previously paused channel is reactivated after more than 90 days.
+      Out of scope: incremental campaign additions to an already-active channel.
+    steps:
+      - id: 1
+        owner: "Valentina Reyes (Paid Social Strategist)"
+        action: "Score the platform against the audience-platform fit matrix: audience density for target persona, commercial intent signals, creative format compatibility, measurement readiness post-iOS. Document score before any budget is committed (PMD-008 gate for Advantage-Plus)."
+      - id: 2
+        owner: "Marcus Holt (PPC Strategist)"
+        action: "If SEM-adjacent platform (Google, Microsoft, Reddit Search): design campaign structure — brand vs. non-brand segmentation (PMD-006), negative keyword seed list minimum 50 entries (PMD-007), bid strategy matched to conversion-volume data maturity (PMD-005)."
+      - id: 3
+        owner: "Tomás Carvalho (Revenue Operations Analyst)"
+        action: "Define attribution plan for the new channel: conversion window, which conversion events map to business outcomes, how channel credit will be allocated in the multi-touch model. Document before launch to establish baseline. Identify double-count risk with existing channels."
+      - id: 4
+        owner: "Rafaela Dias (Compliance & Legal Reviewer)"
+        action: "Review platform terms for the target ad category. Audit consent infrastructure: does the pixel/SDK fire only after affirmative consent on regulated page types (PMD-012)? Is the audience data being uploaded hashed (PMD-004)?"
+      - id: 5
+        owner: "Camila Nunes (Creative Strategist)"
+        action: "Build opening creative inventory: minimum 4 variants per ad set (PMD-010), platform-native formats and aspect ratios, separate hook variants with shared body/CTA for first-week signal gathering."
+      - id: 6
+        owner: "Camila Nunes"
+        action: "Establish pacing targets and fatigue-detection cadence: daily spend cap, frequency cap, weekly hook-rate and CTR review schedule. Define kill threshold for underperforming variants (PMD-011 runtime minimum respected)."
+      - id: 7
+        owner: "Tomás Carvalho"
+        action: "Configure tracking: pixel/SDK fires verified, conversion events match agreed attribution plan, test purchase / test lead confirmed in platform UI before live budget is applied."
+      - id: 8
+        owner: "Staff Code Reviewer"
+        action: "Launch VETO check: audience-platform score documented, attribution plan filed, consent audit passed (PMD-012), PII upload hashed (PMD-004), creative variant count meets minimum (PMD-010)."
+    verification: |
+      - Audience-platform fit score documented before budget committed
+      - Attribution plan filed with conversion windows specified
+      - Pixel/tag consent-mode configured — no pre-consent firing on sensitive pages (PMD-012)
+      - First-party list uploads SHA-256 hashed (PMD-004)
+      - Minimum 4 creative variants per ad set above $200/day (PMD-010)
+      - Pacing and fatigue-detection schedule live before day 3
+
+  - id: paid-media-attribution-model-change
+    title: "Change attribution model or conversion window (governance review)"
+    whenToUse: |
+      Any proposed change to the attribution methodology, conversion window,
+      or primary conversion event across an active paid-media programme.
+      Triggered by: switching from last-click to data-driven, reducing a
+      30-day to 7-day window, introducing media-mix modelling as a parallel
+      source-of-truth, or changing the primary conversion event on any campaign.
+      Out of scope: adding a secondary conversion event for learning purposes
+      without changing the primary or billing metric.
+    steps:
+      - id: 1
+        owner: "Tomás Carvalho (Revenue Operations Analyst)"
+        action: "Document the current model: current conversion windows per platform, current primary conversion events per campaign, trailing-90-day reported conversions under current methodology (PMD-001 baseline)."
+      - id: 2
+        owner: "Tomás Carvalho"
+        action: "Model the impact of the proposed change: run current data through new window/model and produce before/after delta table. Flag any campaign where reported conversions change by more than 15% — these require VETO holder review."
+      - id: 3
+        owner: "Valentina Reyes (Paid Social Strategist)"
+        action: "For Meta, TikTok, LinkedIn: confirm whether the change triggers a campaign learning reset. If yes, schedule the change at the start of a new budget period (not mid-month) to minimise delivery disruption."
+      - id: 4
+        owner: "Marcus Holt (PPC Strategist)"
+        action: "For Google/Microsoft: evaluate whether Smart Bidding targets need to be recalibrated post-change. A 7-day to 30-day window change inflates reported conversions and the current Target CPA will become under-target overnight."
+      - id: 5
+        owner: "Tomás Carvalho"
+        action: "Freeze the old model's output for one full reporting cycle post-change. Document the changeover date and model version in the attribution changelog. Notify all stakeholders who consume paid-media reports (PMD-002 double-count warning if applicable)."
+      - id: 6
+        owner: "Principal QA Architect"
+        action: "Validate post-change tracking: verify new conversion event fires correctly in all platforms, spot-check that double-count logic in dashboard accounts for the new model."
+      - id: 7
+        owner: "Staff Code Reviewer"
+        action: "Merge VETO check: trailing-90-day impact documented, learning-reset timing agreed, Smart Bidding targets reviewed, attribution changelog entry written."
+    verification: |
+      - Trailing-90-day conversion delta table produced before change (PMD-001)
+      - Attribution changelog entry with changeover date and model version
+      - Smart Bidding targets reviewed against new conversion window (PMD-005)
+      - Reporting stakeholders notified of methodology change
+      - Double-count risk flagged in any blended ROAS dashboard (PMD-002)
+
+  - id: paid-media-creative-refresh-cycle
+    title: "Execute a planned creative refresh (fatigue-driven or strategic)"
+    whenToUse: |
+      A creative refresh is triggered by fatigue signals (hook rate declining
+      week-over-week, frequency above 3.5 on awareness placements, CPM
+      increasing more than 20% over 2 weeks) or by a strategic brief
+      (new product launch, seasonal push, brand refresh). Use this chain
+      for any refresh that touches more than 2 ad sets or involves a new
+      creative direction rather than an incremental variant swap.
+    steps:
+      - id: 1
+        owner: "Camila Nunes (Creative Strategist)"
+        action: "Run fatigue audit: pull hook rate, CTR, frequency, CPM trends for all active creatives over the past 21 days. Flag any creative below hook-rate floor or above frequency ceiling per platform benchmark."
+      - id: 2
+        owner: "Camila Nunes"
+        action: "Build creative brief: define the variable being tested (hook / format / CTA / offer / social proof type). Each refresh MUST isolate one variable per test tier — do not change hook + format + CTA simultaneously."
+      - id: 3
+        owner: "Rafaela Dias (Compliance & Legal Reviewer)"
+        action: "Review new copy for claim compliance: substantiation files for any outcome claims, disclosure placement for testimonials, platform policy compliance for the ad category (PMD-013 for influencer content)."
+      - id: 4
+        owner: "Tomás Carvalho (Revenue Operations Analyst)"
+        action: "Confirm test parameters: minimum runtime before kill decision (PMD-011), minimum conversion volume per variant before winner declaration (PMD-009), budget allocation between control and test variants."
+      - id: 5
+        owner: "Valentina Reyes (Paid Social Strategist)"
+        action: "Structure launch: retire fatigued creatives only after new variants accumulate 48 hours of delivery (not before — sudden creative vacuums cause bid instability). Verify minimum 4 variants per ad set above $200/day threshold (PMD-010)."
+      - id: 6
+        owner: "Principal QA Architect"
+        action: "Post-launch check at 72 hours: verify new creatives are delivering, spend is distributing across variants, tracking events fire correctly on landing pages linked from new ads."
+      - id: 7
+        owner: "Staff Code Reviewer"
+        action: "Merge VETO check: compliance review passed, test isolation confirmed (single variable per tier), significance thresholds agreed, minimum runtime floor respected (PMD-011)."
+    verification: |
+      - Fatigue audit documented with per-creative metrics before refresh
+      - Single variable isolated per test tier
+      - Compliance review passed for all new copy (PMD-013 if influencer content)
+      - Minimum 4 variants per ad set above $200/day (PMD-010)
+      - Winner declaration deferred until significance threshold reached (PMD-009)