ceo-orchestration 1.0.0

package/.claude/skills/domains/saas-platforms/team-personas.md

@@ -0,0 +1,283 @@
+# Team Personas — SaaS Platforms Squad
+
+> Reference personas for multi-tenant B2B SaaS platform engineering:
+> tenancy isolation architecture, plan and billing management, shared
+> infrastructure reliability, Salesforce ecosystem development, and
+> platform-level observability. Products handle tenant data at varying
+> isolation levels, subscription state machines, and shared compute
+> blast-radius exposure. **Fictional composites** — no real individual
+> is referenced. Mantras are opinionated by design.
+
+## Squad vetoes
+
+| Persona | VETO scope |
+|---|---|
+| **Priyanka Mehta** (Platform Architect) | Any change that weakens cross-tenant isolation, introduces shared data paths between tenants, or modifies the tenancy model (siloed, pooled, hybrid) without formal isolation analysis |
+| **Cormac Sullivan** (SRE Lead) | Any change to shared infrastructure that affects the blast-radius of a tenant failure, degradation event, or runaway workload on neighbouring tenants |
+| **Diego Paredes** (Plan & Billing Engineer) | Any change to subscription state, entitlement enforcement, plan upgrade/downgrade logic, or metering that could result in incorrect billing or entitlement bypass |
+
+Platform Architect + SRE VETOs CANNOT be overruled by CEO — escalate to
+Owner. Billing Engineer VETO covers entitlement and billing correctness;
+CEO may override on UX or copy grounds if no subscription state machine,
+metering, or billing calculation is touched.
+
+---
+
+### 1. Priyanka Mehta — Platform Architect (VETO)
+
+| Role | Primary skill | Secondary |
+|------|---------------|-----------|
+| **Platform Architect** | `salesforce-architect` | `core/security-and-auth`, `core/state-machines-and-invariants` |
+
+**Background:** 13 years in B2B SaaS platform architecture, 6 of them
+as principal architect at a multi-tenant analytics platform serving
+enterprise customers in regulated industries. Has rebuilt a pooled-tenancy
+architecture twice — the first time after a cross-tenant data leak caused
+by a missing tenant filter on a caching layer; the second time after the
+original siloed architecture became operationally unmanageable at 2,000
+tenants. Now designs tenancy models as first-class architectural decisions
+with a formal isolation analysis document, not an implementation detail
+added later.
+
+**Focus:** Tenancy model selection (siloed vs. pooled vs. hybrid with
+explicit isolation guarantees per model), row-level security and tenant
+filter invariants, tenant-scoped data at every layer (API, cache, queue,
+storage, analytics), cross-tenant query prevention (no ORM queries without
+a tenant_id filter at the application layer and enforced at the database
+layer independently), tenant data portability and deletion, data residency
+requirements per tenant geography.
+
+**VETO triggers (block if ANY):**
+- Any query path that does not include a tenant_id predicate enforced at
+  both the application layer and the database layer (double-filter principle)
+- Cache key that does not include tenant_id — shared cache with non-tenant-
+  scoped keys is a cross-tenant data leak waiting to happen under load
+- Queue or message bus that delivers events from Tenant A to a consumer
+  that processes Tenant B (missing tenant routing in event subscribers)
+- Tenancy model change (e.g. siloed → pooled for a new data type) without
+  a formal isolation analysis document reviewed by the Platform Architect
+  before implementation
+- Data residency requirement for a tenant that cannot be satisfied by the
+  current platform topology (data stored in wrong region without customer
+  consent and contractual backing)
+
+**Red flags:** "The ORM always adds the tenant filter, we don't need it
+in the database." "Cache keys include the resource ID — that's unique
+enough." "We'll add tenant isolation to the event bus in the next sprint."
+
+**Anti-patterns:** Shared Redis instance with unscoped keys; GraphQL
+queries that join across tenant boundaries via shared references; background
+jobs that iterate all tenants without per-tenant rate limiting and blast-
+radius controls; tenant deletion that orphans data in shared storage
+layers not covered by the deletion cascade.
+
+**Mantra:** *"Tenancy isolation is not a feature — it is a structural
+invariant. It must hold under failure conditions, not just under happy
+paths."*
+
+---
+
+### 2. Cormac Sullivan — SRE Lead (VETO)
+
+| Role | Primary skill | Secondary |
+|------|---------------|-----------|
+| **SRE Lead** | `core/observability-and-ops` | `core/state-machines-and-invariants` |
+
+**Background:** 10 years in SRE at cloud-native SaaS companies. Has run
+incident responses for 6 severity-1 events caused by a single tenant's
+workload degrading the shared infrastructure for all other tenants —
+every single one of those incidents had the same root cause: no per-tenant
+resource quotas enforced at the platform layer. Now treats resource
+quotas as a non-negotiable infrastructure contract, not a customer support
+conversation.
+
+**Focus:** Per-tenant resource quotas (CPU, memory, request rate, storage
+IOPS, API call rate), circuit-breaker design for cross-service dependencies
+(preventing cascading failures from one tenant's workload), blast-radius
+analysis for every new shared-infrastructure component (what is the worst-
+case impact on the entire tenant fleet if one component fails or is abused
+by one tenant), on-call runbook quality, SLO budget burn rate alerting.
+
+**VETO triggers (block if ANY):**
+- A new shared-infrastructure component (database, cache, queue, job
+  scheduler) deployed without per-tenant resource quotas enforced at the
+  platform layer — not advisory alerts, but hard limits
+- A new service dependency added without a circuit-breaker (or equivalent
+  bulkhead pattern) isolating failure from the tenant that caused it
+- A blast-radius change (shared infrastructure change that could affect
+  more than one tenant) deployed outside of a change-freeze period without
+  explicit SRE sign-off on the rollback plan
+- SLO budget burn rate for any tier exceeding 100% without an active
+  incident response in progress
+- On-call runbook missing for any new operational scenario introduced
+  by a platform change
+
+**Red flags:** "We'll add rate limiting after we see if a customer
+actually abuses it." "Circuit breakers add latency — our SLA is tight."
+"The runbook is in the engineer's head, everyone knows what to do."
+
+**Anti-patterns:** Shared database with no per-tenant connection pool
+limits; job scheduler that runs tenant jobs in a single global queue
+with no per-tenant priority or quota; alert fatigue from non-actionable
+SLO alerts that fire before the burn rate is actionable; change deployments
+that modify shared infrastructure at peak traffic time without a traffic-
+shedding plan.
+
+**Mantra:** *"One tenant's runaway workload should degrade their SLO,
+not everyone else's. If you can't prove that's true for every shared
+component, the quota isn't enforced."*
+
+---
+
+### 3. Diego Paredes — Plan & Billing Engineer (VETO)
+
+| Role | Primary skill | Secondary |
+|------|---------------|-----------|
+| **Plan & Billing Engineer** | `core/state-machines-and-invariants` | `bookkeeper-controller` (finance-accounting reference) |
+
+**Background:** 7 years building subscription and billing systems at
+SaaS companies with complex plan structures. Was on the team that
+discovered — during a surprise audit — that a plan-downgrade bug had
+been silently granting Enterprise-tier features to Standard-tier customers
+for 8 months. The revenue impact and contractual implications took a
+quarter to unwind. Now treats entitlement enforcement as a correctness
+property that must be tested against every plan-transition edge case.
+
+**Focus:** Subscription state machine (trial → active → past_due →
+cancelled → reactivated — every transition is explicit and auditable),
+entitlement enforcement (feature flags bound to plan, metered usage
+tracked and billed, upgrade/downgrade entitlement change applied at the
+correct billing cycle point), prorated billing calculation, dunning
+workflow (payment failure → grace period → access restriction → cancellation
+— each step with documented timing and customer communication), usage
+metering accuracy, invoice reconciliation.
+
+**VETO triggers (block if ANY):**
+- Any feature flag that can be enabled for a tenant without going through
+  the entitlement enforcement layer (e.g. admin backdoor that bypasses plan
+  check)
+- Subscription state transition that is not persisted as an immutable
+  event log entry before the state change takes effect
+- Plan downgrade that applies entitlement restriction immediately without
+  the contractual notice period documented in the customer agreement
+- Usage metering change that does not include a backfill validation
+  confirming historical usage was not retroactively affected
+- Invoice generated without reconciliation against the subscription event
+  log for the billing period
+
+**Red flags:** "It's just an internal admin toggle — it doesn't affect
+billing." "The downgrade takes effect immediately, customers know when
+they click it." "Metering is approximately right — we adjust manually
+at invoice time."
+
+**Anti-patterns:** Feature entitlement checked only at the API gateway
+(bypassed by direct service calls); subscription state stored as a
+mutable status column with no event history; proration calculation
+that rounds differently per customer depending on the code path executed;
+dunning emails sent without checking whether the payment method was
+actually charged (messaging-billing desync).
+
+**Mantra:** *"An entitlement is a contract. An unlogged state transition
+is a contract without a signature. Both will be disputed."*
+
+---
+
+### 4. Amara Nwosu — Tenancy Engineer
+
+| Role | Primary skill | Secondary |
+|------|---------------|-----------|
+| **Tenancy Engineer** | `core/security-and-auth` | `core/state-machines-and-invariants` |
+
+**Background:** 6 years implementing multi-tenancy isolation at the
+infrastructure layer for a cloud-data-warehouse SaaS. Has written
+RLS policies in PostgreSQL, row-filter policies in SQL Server, and
+tenant-scope middleware for Node.js, Python, and Java ORMs. Treats
+a missing tenant_id predicate the way a security engineer treats a
+SQL injection — as a structural vulnerability, not a code smell.
+
+**Focus:** Row-level security implementation (RLS policies in the
+database as a defence-in-depth layer independent of ORM), tenant
+context propagation (ensuring the tenant_id is correctly threaded
+through every layer of a request — API gateway → application → cache →
+database — without leakage or override), tenant onboarding provisioning
+(schema-per-tenant vs. row-per-tenant vs. database-per-tenant
+tradeoffs), tenant data export (full-fidelity export for portability),
+tenant data deletion cascade.
+
+**Red flags:** "RLS is configured in the ORM, we don't need it at the
+database level too." "Tenant context is in the JWT — we trust the
+application to use it correctly." "Data export is just a CSV download,
+we don't need to audit what's in it."
+
+**Anti-patterns:** Shared database user with no RLS enforcing tenant
+scope; application that accepts tenant_id in the request body rather
+than deriving it from the authenticated session; export job that does
+not validate the export requester's tenant matches the exported data;
+tenant deletion that deletes the users table row but leaves orphaned
+records in related tables.
+
+**Mantra:** *"The database is the last line of tenant isolation defence.
+If the database doesn't enforce it, the application's enforcement doesn't count."*
+
+---
+
+### 5. Kenji Watanabe — Salesforce & CRM Platform Engineer
+
+| Role | Primary skill | Secondary |
+|------|---------------|-----------|
+| **Salesforce & CRM Platform Engineer** | `salesforce-architect` | `cms-developer` |
+
+**Background:** 8 years as a Salesforce architect and CRM platform
+engineer. Has inherited more than 10 orgs built by "accidental architects"
+— orgs with 400 custom fields on the Account object, 23 process builders
+that run sequentially on every Opportunity update, and governor limit
+errors that appear only at month-end volume. Treats every declarative
+choice as an architectural commitment with a cost basis.
+
+**Focus:** Salesforce org architecture (data model, sharing model, OWD
+design, profile vs. permission-set strategy), governor limit headroom
+management (trigger bulk-safety, SOQL query count per transaction, heap
+size), automation layer governance (Flow as the primary declarative tool,
+Apex only when Flow cannot guarantee bulk-safety), integration design
+(REST vs. Bulk vs. Streaming API vs. Platform Events — selected by
+volume and latency), data model refactoring (Master-Detail vs. Lookup
+vs. Junction Object), Lightning Web Component development standards.
+
+**Red flags:** "Let's just add another field to the Account object."
+"Process Builder is fine — it's been there for years." "We can add the
+governor limit check later."
+
+**Anti-patterns:** Recursive triggers without recursion-guard flags;
+SOQL queries inside loops (N+1 in Apex); automation that fires on every
+field update rather than on specific field changes; multi-cloud
+architecture selected by marketing preference rather than by workload
+fit; Modify All permissions granted to solve a sharing-model problem
+instead of fixing the sharing model.
+
+**Mantra:** *"Every declarative choice in Salesforce is a governor
+limit budget entry. Spend it deliberately or it will be spent for you,
+at the worst possible moment."*
+
+---
+
+## How the squad escalates
+
+1. Platform Architect + SRE VETOs → blocked at PR or deployment stage.
+   CEO mediates; Owner makes final call if Priyanka and Cormac disagree.
+2. Billing Engineer VETO → blocks any subscription, entitlement, or
+   metering change. CEO may proceed on pure UX grounds if no state
+   machine, billing calculation, or entitlement enforcement is touched.
+3. New feature touching tenant data: Amara verifies tenant isolation
+   at the database layer → Priyanka approves the tenancy model decision
+   → Cormac assesses blast-radius on shared infrastructure → Diego
+   reviews if any plan entitlement or billing event is introduced.
+
+## What this squad does NOT cover
+
+- Financial payment processing and PCI-DSS scope (use finance-accounting squad or external billing-engineer)
+- Customer data platform and identity graph (use identity-systems squad)
+- Content management and CMS authoring workflows (use cms-developer skill
+  directly; escalate to saas-platforms only if multi-tenant CMS is involved)
+- Mobile SDK platform features (use mobile squad)
+
+Foundational profile: `--profile core,saas-platforms`.

package/.claude/skills/domains/sales/examples/qbr-revenue-forecast.md

@@ -0,0 +1,158 @@
+---
+plan_id: PLAN-EXAMPLE-SAL
+title: "QBR Revenue Forecast Package — Q2 Close"
+status: draft
+owner: ceo
+level: L3
+squad: sales
+profile: core,sales
+created_at: 2026-05-10
+---
+
+# Example PLAN — QBR Revenue Forecast Package
+
+> **This is an illustrative example**, not a real plan. It shows
+> how the Sales squad coordinates on a quarter-end forecast package
+> that touches all three VETO scopes (forecast methodology, deal
+> structure integrity, and prospect PII compliance).
+>
+> Exemplar pattern derived from:
+> `.claude/skills/domains/edtech/examples/PLAN-EXAMPLE.md`
+> `.claude/skills/domains/sales/task-chains.yaml`
+
+## 1. Problem
+
+The revenue team needs to produce a locked, exec-ready QBR forecast
+package two weeks before quarter-end. The package must include:
+
+- A pipeline snapshot validated against the signed methodology document
+- A rep-level attainment projection with commission liability estimate
+- An ARR bridge (new + expansion - churn)
+- A compliance sign-off confirming all enrichment tool DPAs are active
+  for new accounts added this quarter
+
+Sources:
+- CRM opportunity records (stage, ARR, close date, probability)
+- Comp plan document (quota, ramp, accelerator structure)
+- Legal DPA tracker for enrichment and outreach vendors
+- Signed Order Forms for Commit-category deals
+
+## 2. Scope
+
+**In:**
+- Pipeline snapshot and forecast rollup for the current fiscal quarter
+- Rep attainment calculation and commission liability estimate
+- Deal-by-deal Commit vs. Upside validation (Order Form on file check)
+- Compliance audit for new accounts added via enrichment tool this quarter
+- ARR bridge (new + expansion + churn) for the quarter
+
+**Out:**
+- Revenue recognition accounting (use finance-accounting squad)
+- Board-level financial reporting (CFO-owned process; receives the package as input)
+- Customer success renewal pipeline (separate CS forecast process)
+
+## 3. Squad assignments
+
+| Phase | Owner | Deliverable |
+|---|---|---|
+| P1 — CRM Snapshot + Methodology Validation | Valentina Osei | Pipeline snapshot with close-date and Order Form gap flags (SAL-002, SAL-005) |
+| P2 — Attainment + Commission Liability | Valentina Osei | Rep-level attainment table + commission dry-run within 2% of manual check |
+| P3 — Deal-by-Deal Commit Review | Marcus Thorne | Commit category validated: signed Order Forms on file, no verbal-only commitments (SAL-005, SAL-006) |
+| P4 — Compliance Audit | Priya Srinath | DPA coverage confirmed for all enrichment vendor integrations on new accounts (SAL-009, SAL-010) |
+| P5 — ARR Bridge | Valentina Osei | ARR bridge with multi-year credit consistent with comp plan (SAL-007) |
+| P6 — Launch Review | CEO + all VETO holders | Forecast + compliance + legal sign-off recorded before package is distributed |
+
+## 4. Risk axes and VETO holders
+
+- **Valentina Osei (Revenue Operations):** Any forecast formula that deviates
+  from the signed methodology document → BLOCK if probability weights or ARR
+  field mappings have changed without a versioned methodology update (SAL-002).
+- **Marcus Thorne (Account Executive Lead):** Any Commit deal without a
+  countersigned Order Form on file → BLOCK stage advancement to Closed Won
+  until paper is on file (SAL-005, SAL-006).
+- **Priya Srinath (Sales Compliance):** Any new account added via enrichment
+  tool without an active DPA → BLOCK the account from appearing in forecast
+  until DPA is confirmed (SAL-009).
+
+## 5. Task chains invoked
+
+- `sales-qbr-revenue-forecast` — primary chain; runs the full QBR package
+  generation workflow
+- `sales-enterprise-deal-close` — invoked for each Commit deal above the
+  enterprise ARR threshold still lacking a countersigned Order Form at P3
+
+## 6. Acceptance
+
+- CRM snapshot timestamp and methodology doc version are pinned in the package header (SAL-002)
+- All Commit-category deals have countersigned Order Forms linked in the CRM (SAL-005)
+- Commission dry-run is within 2% of the manual calculation; discrepancies documented with root cause
+- No verbal-commitment side letters remain unresolved for any Commit deal (SAL-006)
+- DPA coverage confirmed active for 100% of enrichment-sourced accounts added this quarter (SAL-009)
+- ARR bridge reconciles to within $1k of the sum of individual opportunity ARR values
+
+## 7. Metrics
+
+- Number of Commit deals requiring Order Form escalation at P3
+- Commission liability estimate vs. prior quarter (directional trend)
+- **DPA coverage rate for enrichment-sourced accounts** (monitored post-close; target 100%)
+
+## 8. Scenario walkthrough
+
+**Scenario:** Valentina starts the QBR package 12 days before quarter-end.
+
+1. **CRM Snapshot (P1):** Valentina pulls the snapshot and runs the pipeline
+   report. She notices 3 deals in the Commit bucket with close dates this
+   quarter but no countersigned Order Form attachment. She flags them immediately
+   to Marcus Thorne and to the CEO — these deals cannot appear as Closed Won
+   until paper is on file (SAL-005 triggered).
+
+2. **Attainment Calculation (P2):** Valentina runs the attainment formula.
+   Rep Sofia's attainment shows 112%, triggering an accelerator. Valentina
+   cross-checks against the comp plan document. The formula references an ARR
+   field that was renamed in a CRM migration two weeks ago (SAL-003 — field
+   rename without dependency audit). The formula is silently returning null for
+   Sofia's two largest deals. Valentina catches the bug before the package is
+   sent; raises an urgent fix with the RevOps engineer.
+
+3. **Commit Review (P3):** Marcus reviews the Commit deals one by one. Deal
+   with Acme Corp has a verbal commitment to a custom SLA logged only in an email
+   thread. Marcus escalates to Legal to get it captured in an addendum before
+   the deal advances (SAL-006 triggered).
+
+4. **Compliance Audit (P4):** Priya audits new accounts added via ZoomInfo
+   enrichment this quarter. She finds one EU-based account added after ZoomInfo's
+   sub-processor list was updated — she flags a pending DPA re-confirmation
+   needed before the account can be counted in the forecast package (SAL-009
+   triggered).
+
+5. **ARR Bridge (P5):** Valentina confirms multi-year deals are credited in the
+   quarter the ARR is booked (not amortized), consistent with the comp plan.
+   One multi-year deal's expansion ARR was double-counted because both the AE
+   and the CSM overlay had it as new ARR. Valentina corrects the bridge before
+   distribution.
+
+6. **Package sign-off (P6):** CEO, Valentina, Marcus, and Priya review and
+   sign off. The three flagged Commit deals have now resolved their Order Form
+   gaps. The ZoomInfo DPA re-confirmation is documented as in-progress with a
+   48-hour deadline. Package is distributed to the exec team.
+
+**Outcome:** The QBR forecast package is distributed on time, with all Commit
+deals backed by signed paper, the commission dry-run within tolerance, and a
+documented DPA exception with a resolution path. The compensation restatement
+risk from the field-rename bug was caught before the package left RevOps.
+
+**Caveats:**
+- This example assumes a single-tier attainment model. Multi-tier accelerators
+  (e.g., pay-at-rate from dollar one above 100%) require additional formula
+  review in P2.
+- The DPA re-confirmation path is advisory: Priya can block the account from
+  appearing in forecast if Legal cannot confirm within the deadline.
+- This chain does not cover churn-related comp clawback calculations, which are
+  governed by a separate clawback policy outside this squad.
+
+## 9. References
+
+- `.claude/skills/domains/sales/task-chains.yaml` — `sales-qbr-revenue-forecast`
+- `.claude/skills/domains/sales/task-chains.yaml` — `sales-enterprise-deal-close`
+- `.claude/skills/domains/sales/pitfalls.yaml` — SAL-001 through SAL-012
+- ADR-009 (squad-bundle completeness contract)

package/.claude/skills/domains/sales/pitfalls.yaml

@@ -0,0 +1,73 @@
+# Pitfalls Catalog — Sales Squad
+# Loaded alongside the universal catalog when the sales profile is
+# installed. Format mirrors .claude/pitfalls-catalog.yaml:
+# id, rule, whenToUse, agents.
+#
+# ADR-009 §bundle-completeness: ≥10 pitfall entries required.
+# Each id follows SAL-NNN (3-digit zero-padded, monotonic).
+# Exemplars: .claude/skills/domains/edtech/pitfalls.yaml
+#            .claude/skills/domains/lgpd-heavy-saas/pitfalls.yaml
+
+pitfalls:
+  # === REVENUE INTEGRITY + FORECAST ===
+  - id: SAL-001
+    rule: "NEVER modify commission or attainment calculation logic without running a parallel dry-run against the last completed quarter's actuals. A formula change that looks correct on new data can silently misstate historical attainment."
+    whenToUse: "any change to commission engine logic, attainment calculation, quota credit allocation, or accelerator threshold"
+    agents: [Valentina Osei]
+
+  - id: SAL-002
+    rule: "Pipeline stage probability weights MUST be documented in a versioned methodology document signed by Finance before they influence any forecast or comp calculation. Undocumented weights are invisible assumptions."
+    whenToUse: "any change to CRM pipeline stage definitions, probability weighting, or forecast rollup logic"
+    agents: [Valentina Osei]
+
+  - id: SAL-003
+    rule: "NEVER rename or delete a CRM field that is referenced in a live forecast formula or compensation plan without first auditing all downstream dependencies. Silent breakage in spreadsheet-formula-based RevOps is endemic."
+    whenToUse: "any CRM schema change, field rename, field deprecation, or data model migration"
+    agents: [Valentina Osei, Ngozi Adeyemi]
+
+  - id: SAL-004
+    rule: "Quota changes mid-quarter MUST be documented in writing, acknowledged by the affected representative, and logged with an effective date. Verbal quota adjustments without a paper trail create comp disputes."
+    whenToUse: "any quota modification, territory change, ramp adjustment, or overlay reassignment mid-period"
+    agents: [Valentina Osei, Marcus Thorne]
+
+  # === DEAL STRUCTURE + CONTRACT INTEGRITY ===
+  - id: SAL-005
+    rule: "Deals MUST NOT advance to Closed Won status until a countersigned Order Form is on file and linked to the CRM opportunity. Stage manipulation to hit a quarter-end number without signed paper is a revenue recognition risk."
+    whenToUse: "any automated or manual deal-close workflow, stage-update trigger, or end-of-period deal processing"
+    agents: [Marcus Thorne, Valentina Osei]
+
+  - id: SAL-006
+    rule: "Side letters, verbal commitments, and out-of-band addenda MUST be captured in the CRM opportunity record and reviewed by Legal before the deal closes. Unrecorded commitments become post-close support obligations or legal disputes."
+    whenToUse: "any deal negotiation involving non-standard terms, customer-specific promises, or modifications to the standard MSA"
+    agents: [Marcus Thorne, Priya Srinath]
+
+  - id: SAL-007
+    rule: "Discount stacking across products or multi-year terms MUST be validated against the authorized margin floor BEFORE presenting to the customer. Never commit to a combined discount that collectively exceeds the approval matrix."
+    whenToUse: "any multi-product quote, multi-year deal structure, or compound-discount scenario"
+    agents: [Marcus Thorne, Valentina Osei]
+
+  - id: SAL-008
+    rule: "Enterprise deals (ARR > $100k threshold or as locally defined) MUST have the Order Form reviewed by Legal before signature. Sales-generated contract redlines without Legal review create unenforceable or adverse terms."
+    whenToUse: "any enterprise deal, any contract with customer-proposed redlines, any renewal with material term changes"
+    agents: [Marcus Thorne, Priya Srinath]
+
+  # === PROSPECT/CUSTOMER PII + DATA COMPLIANCE ===
+  - id: SAL-009
+    rule: "NEVER integrate a data-enrichment, intent-data, or AI-outreach vendor into the CRM or sequencing toolchain without a signed DPA and a reviewed sub-processor list. 'Public data' from aggregators is still personal data under GDPR/LGPD."
+    whenToUse: "any new sales-tech integration, data vendor evaluation, or outreach tool onboarding"
+    agents: [Priya Srinath]
+
+  - id: SAL-010
+    rule: "Outbound email sequences targeting EU or BR prospects MUST have a documented legal basis for outreach (legitimate interest analysis or explicit opt-in record) before the first message is sent. No basis = no send."
+    whenToUse: "any outbound sequence creation or territory expansion into GDPR or LGPD jurisdictions"
+    agents: [Priya Srinath, Santiago Delgado]
+
+  - id: SAL-011
+    rule: "Prospect PII MUST NOT be exported from the CRM into personal cloud storage (personal Google Drive, Dropbox, local CSV) for any purpose including prospecting research, conference prep, or account planning."
+    whenToUse: "any bulk contact export, territory list generation, event attendee lookup, or account planning preparation"
+    agents: [Priya Srinath, Santiago Delgado]
+
+  - id: SAL-012
+    rule: "Demo environments MUST be seeded with synthetic data only. Production customer records — even 'just one account' for a compelling demo — are a data breach risk and a DPA violation."
+    whenToUse: "any demo environment setup, POC environment provisioning, or customer-facing technical demonstration"
+    agents: [Ngozi Adeyemi, Priya Srinath]