ADR 0004: Product Scope Boundaries — S4–S9 (Accepted)

Status

Accepted — 12 Jun 2026. Decision owned by the founder.

Pending external confirmation:

Context

After locking S1–S3 (Meta 2-Tier, GA4 soft gate, all-TypeScript stack), remaining scope items S4–S9 needed founder decisions before Phase 1 build. Several touch parent/VC teams (finance, legal, CRM) but the module boundary can be locked now.

Decisions

S4 — Per-tenant credit / spend limit (partial lock)

Locked (engineering):

• Every tenant gets a per-tenant spend limit enforced via existing controls (credit_sub_limit, Meta spend_cap, internal qc.spend guardrails — see provisioning spec §2).
• Limit is the hard ceiling for platform spend automation regardless of payment model.

If clients prepay media:

• Set credit_sub_limit (and related caps) to the prepaid balance exposed by the parent billing module internal API (amount + currency + tenant id).
• Reconcile nightly; block or pause when balance exhausted.

If payment model differs (e.g. pure monthly invoice, credit line, hybrid):

• Not decided in this module — escalate to finance / parent billing team before wiring limit source-of-truth.
• Engineering keeps the limit field; only the upstream balance provider changes.

S5 — Closed-loop CRM timing (deferred)

Deferred. Full closed-loop ROI remains Phase 4; interim offline import remains a Phase 1.5 option — no change to Phase 1 build scope now.

S6 — DV360 in early SKU (deferred)

Deferred. DV360 stays out of early SKU; add-on after sales contract lands (PRE-6).

S7 — Social posting scope (locked)

No organic feed publishing in Phase 1 or near-term product scope.

OAuth scopes stay without pages_manage_posts. Engagement objectives are met through paid ads only.

S8 — Data boundary & compliance (locked with legal confirm)

Locked (module scope):

• This module does not store PII or client financial data in its pipeline.
• CRM records, billing, invoicing, and payment instruments are other teams' systems — not persisted in the ads module datastore except transient pass-through for platform APIs where required.
• CAPI, offline conversion import, and enhanced conversions — deferred to a later phase; when built, follow hash-only / platform-boundary rules in data & tracking.

Working assumption (founder): Because the module avoids PII/financial retention, KVKK/GDPR obligations may be limited for this module's datastore — but legal must confirm (sub-processor role, consent copy, entity jurisdiction, regional deployment).

Action: Open legal review before production region lock and before updating client-facing consent text. Entity jurisdiction (TR vs EU) follows legal answer — not decided unilaterally here.

S9 — Special Ad Category at onboarding (locked)

Locked:

• Default special_ad_categories: NONE on all campaigns unless content requires otherwise.
• During onboarding, collect business type / vertical from the client (portal intake).
• Map intake → Special Ad Category eligibility flag in tenant_registry (e.g. housing offer, employment offer, financial product) — not auto-applied from vertical name alone.
• Campaign creation applies category only when the ad creative/offer matches a regulated topic (Meta compliance notes).

Consequences

Related documents

• Onboarding
• Provisioning spec §2, §6.7
• Meta ads
• Cost model §7
• Gameplan §5