Proposed -- needs human approval

This tower does not push to git. To approve, a human makes this exact edit and commits it:

1. Open docs/marketing/journal/007-seesight-ads-actuator-warehouse.md in the docs repo.
2. Change the line "- **Status:** proposed" to "- **Status:** active".
3. Commit and push. The journal's git history is the audit trail; this tower does not commit on your behalf.

007: seesight-ads adopted as the engine's actuator and warehouse layer; identity graph deployed on exact keys, no fingerprinting

Date: 2026-08-31
Decider: engine proposal (Claude), pending Daud approval
Status: proposed
Review by: 2026-11-30

Decision

The daudgrewal/seesight-ads repo (cloned to ~/GIthub Repo/seesight-ads) becomes the engine's Google actuator and BigQuery warehouse layer, per the component map in docs/marketing/specs/ads-engine-integration.md. The growth module stays the server spine. The identity-linking goal ("unique print" joining analytics to bookings) is delivered by that repo's own identity-graph design running on the NEW deterministic keys the engine shipped (GA4 purchase.transaction_id = PaymentIntent id = growth.conversion_log), explicitly NOT by probabilistic fingerprinting. The spouse-forward dark-social case is addressed by porting the signed share-token flow into the production site; the post-purchase survey supplies the measured dark-social share; geo-holdouts remain the leakage-proof reward signal.

Evidence

4-lane recon of seesight-ads (2026-08-31): complete Data Manager API client with ADC auth and dry-run gates (platform/google/data_manager.py); live BigQuery project seesight-marketing-data with GA4 export, Ads transfer (stale since 2026-04-26), and Stripe charges; dry-run-validated identity.person SQL keyed on hashed email with deterministic stitch precedence and a recovered_dark_attribution measure; HMAC share-token design in lib/share-link.ts; propose-only skills with the same hard rules as this engine's.
That repo's CTO brief (2026-05-31) specced the exact capture-to-Stripe-to-offline-upload pipeline the engine built independently this week; convergent designs, one system.
Account truth (verified there 2026-05-31): Basic-access developer token works; the Ads account is dark (4 of 120 Search campaigns enabled, $0 spend trailing 30 days), so the brand-defense launch is the relight, and non-brand waits for the live spine.
Governance lesson kept: April "live mutation" reports were banner-marked unverified and one change-pack quarantined as fabricated. Fresh API reads before trusting any account claim.

Predicted effect

Within 3 weeks of the asks landing (token rotation, transfer re-auth, dataset deploys, schema bridge): identity.person runs on live data and the first recovered_dark_attribution measurement quantifies the dark-social share of bookings; Google offline conversion uploads leave dry-run using the Data Manager client's payload shapes in growth. Measured by the identity view returning rows for 95 percent+ of post-launch Stripe charges and the first tracked-vs-survey source comparison appearing in a digest.

Measured effect

(pending)