ceo-orchestration 1.0.0

package/.claude/skills/domains/identity-systems/skills/identity-graph-operator/SKILL.md

@@ -0,0 +1,353 @@
+---
+name: identity-graph-operator
+description: |
+  Customer identity graph operations for marketing and customer-data
+  platforms. Covers deterministic match (hashed email, hashed phone,
+  known-customer-id), probabilistic match (device-graph, IP-cluster,
+  behavioural-similarity), household graph construction, cookieless
+  identity resolution (UID2 / RampID / ID5 / Topics API), CDP
+  integration, consent propagation across LGPD / GDPR / CCPA / DMA,
+  fraud-signal detection, and data clean room collaboration. Distinct
+  from `core/identity-and-trust-architecture`, which covers
+  cryptographic agent identity and token signing. PII-touching: all
+  operations require a valid consent record. Use when building or
+  auditing a customer identity layer, designing a CDP integration,
+  modelling household graphs, selecting a cookieless identity
+  protocol, or authoring a data clean room agreement.
+owner: Valentina Osei (Identity Graph Operator, domain persona)
+tier: domain:identity-systems
+scope_tags:
+  - identity-graph
+  - deterministic-match
+  - probabilistic-match
+  - household-graph
+  - cookieless-identity
+  - cdp
+  - data-clean-room
+inherits: core/compliance-lgpd
+pii_handling: required
+inspired_by:
+  - source: msitarzewski/agency-agents/specialized/identity-graph-operator.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: identity-systems
+priority: 3
+risk_class: high
+stack: [typescript, node]
+context_budget_tokens: 800
+inactive_but_retained: false
+repo_profile_binding:
+  frontend: {active: false, priority: 10}
+  engine: {active: true, priority: 4}
+  fintech: {active: true, priority: 4}
+  trading-readonly: {active: true, priority: 5}
+  generic: {active: false, priority: 10}
+activation_triggers:
+  - {event: help-me-invoked, regex: "(?i)identity|sso|oidc|saml"}
+# --- K1 paths: native file-touch activation (PLAN-135 W3 unit k1a) ---
+paths:
+  - "**/identity/**"
+  - "**/identity-graph/**"
+  - "**/cdp/**"
+  - "**/consent/**"
+---
+
+# Identity Graph Operator
+
+## Cardinal Rule
+
+Every identity resolution decision that reaches a PII-adjacent
+surface — ad targeting, personalisation, data clean room query,
+household attribution — must be traceable to a consent record that
+was valid at the time the decision was made. A match that cannot be
+paired with a valid consent record must be treated as no match for
+disclosure purposes, regardless of confidence score.
+
+## Fail-Fast Rule
+
+If a consent record for the target identity cannot be confirmed at
+the time of resolution, **stop and return an error before writing
+any link to the identity graph**. Never infer consent from
+engagement history, login recency, or downstream business logic.
+Consent absence is not the same as consent revocation, but neither
+state authorises processing.
+
+## When to Apply
+
+- Designing or auditing a customer identity resolution pipeline.
+- Selecting a deterministic vs. probabilistic match strategy for a
+  given use case and regulatory regime.
+- Modelling a household graph or sub-household identity layer.
+- Choosing a cookieless identity protocol (UID2, RampID, ID5,
+  Topics API, first-party authenticated traffic).
+- Integrating a Customer Data Platform (CDP) with an existing
+  identity spine.
+- Authoring or reviewing a consent propagation workflow across
+  LGPD, GDPR, CCPA, or DMA jurisdictions.
+- Designing a data clean room for multi-party collaboration
+  without raw-data exchange.
+- Investigating synthetic-identity fraud or bot-traffic exclusion.
+
+## PII Handling
+
+All fields processed by this skill are treated as PII until
+explicitly classified otherwise by a data-quality gate.
+
+**Canonical PII inputs:**
+
+| Field | Canonical form at ingest | Retention rule |
+|---|---|---|
+| Email address | SHA-256 hash (hex, lowercase, trimmed) | Raw email discarded immediately after hashing |
+| Phone number | E.164 normalised, then SHA-256 hash | Raw phone discarded immediately after hashing |
+| Device fingerprint | Opaque token; never reverse-mapped to a named user without consent | Session-scoped or consent-bounded TTL |
+| Cookie ID / device ID | Pseudonymous; store only the graph-edge, not the raw cookie | Per-consent-revocation TTL |
+
+Minimum-necessary principle applies at every stage: do not request,
+store, or propagate fields not required for the specific resolution
+operation in flight.
+
+**LGPD Art. 14 — minor handling:** Any identity record associated
+with a user whose age cannot be verified must default to the minor
+data-handling regime. Do not merge or link minor records into
+household graphs without explicit guardian consent. Cross-link to
+`core/compliance-lgpd` §Minor Data Handling and
+`domains/edtech/skills/student-data-privacy` §Age Verification Gate
+for enforcement details.
+
+**Consent propagation primary:** every write to the identity graph
+must carry the consent-string or consent-event-id that authorises
+the operation. Downstream consumers of the graph inherit the
+consent scope; they do not re-derive it.
+
+## Deterministic Match
+
+Deterministic match assigns confidence = 1.0 when two or more
+stable, verified signals agree.
+
+**Accepted deterministic signals:**
+
+- Hashed email (SHA-256, normalised before hashing)
+- Hashed phone number (E.164, SHA-256)
+- Authenticated login state (first-party session token validated
+  server-side)
+- Known-customer-id (CRM canonical key with authoritative source
+  of record declared in the data processing registry)
+
+**Rules:**
+
+- Confidence = 1.0 is only valid when at least one deterministic
+  signal resolves without ambiguity. Never assign 1.0 to a
+  probabilistic signal regardless of score.
+- Never infer a deterministic link from co-occurrence, timing, or
+  shared device without an authenticated signal confirming the link.
+- Field normalisation must precede hashing; normalisation logic
+  must be version-pinned and auditable.
+- Contradictory deterministic signals (two confirmed emails that
+  hash to different values on the same canonical entity) trigger a
+  mandatory split review, not a silent merge.
+
+## Probabilistic Match
+
+Probabilistic match produces a per-match confidence score in
+[0.0, 1.0). The score is evidence, not a decision; the decision
+threshold is a tunable policy parameter.
+
+**Accepted probabilistic signals:**
+
+- Device graph (shared device-fingerprint or cookie-id cluster)
+- IP cluster (shared IP prefix, recency-weighted)
+- Behavioural similarity (session-pattern vectors, frequency
+  distribution)
+- Cross-device co-occurrence (temporal proximity on authenticated
+  sessions)
+
+**Rules:**
+
+- Every probabilistic match record must carry: signal sources,
+  per-signal weight, composite score, and the threshold policy in
+  effect at decision time.
+- Threshold tuning is use-case-specific. Suggested baseline
+  thresholds:
+
+  | Use case | Min threshold | Notes |
+  |---|---|---|
+  | Ad frequency capping | 0.70 | False merges cause under-exposure, not privacy harm |
+  | Household attribution | 0.80 | False merges affect billing accuracy |
+  | Consent-derived action | Do not use | Use deterministic signals only |
+  | PII disclosure | Do not use | Prohibited — deterministic only |
+
+- Probabilistic matches must never be used for PII-disclosure
+  decisions, consent derivation, fraud prosecution, or any
+  operation that requires identity certainty.
+- Re-score probabilistic links on a rolling basis; stale scores
+  (score > configured staleness TTL without refresh) must be
+  demoted to "needs-review" status.
+
+## Household Graph
+
+A household graph clusters identities that share a physical
+dwelling for attribution and measurement purposes.
+
+- Membership derived from deterministic or high-confidence
+  probabilistic links to shared signals (device, IP, postal address).
+- Sub-household individuals must remain distinct records; never
+  collapse them into a single entity for any PII regulatory operation.
+- A shared device is a device node with edges to each member, not a
+  merged person node.
+- Household is a measurement unit, not a legal entity; never use
+  household aggregates for per-individual compliance decisions
+  (credit, insurance, employment).
+- LGPD / GDPR consent is individual: household-level consent does
+  not extend to members unless each has independently consented.
+
+## Cookieless Identity
+
+Third-party cookie deprecation requires an explicit protocol
+selection matched to the consent posture and use case.
+
+**Protocol fit matrix:**
+
+| Protocol | Consent requirement | Primary use case | Limitations |
+|---|---|---|---|
+| UID2 (Unified ID 2.0) | Explicit opt-in; hashed email as seed | Programmatic advertising, CTV | Requires publisher + DSP support; email mandatory |
+| RampID (LiveRamp) | Consent via CMP or direct opt-in | Cross-publisher identity spine | Proprietary graph; data-residency scope varies by region |
+| ID5 | Publisher-controlled consent signal | Open web frequency capping | Lower coverage outside premium publishers |
+| Topics API | Browser-enforced; no PII transmitted | Contextual targeting | Coarse signal; Chrome-only as of v1.14 |
+| First-party authenticated traffic | First-party consent (login) | Own-property personalisation | Requires login wall or registration incentive |
+
+**Consent flag pass-through:** when a UID2 / RampID / ID5 token is
+passed to a downstream activation platform, the consent-string that
+authorised the token generation must travel with the token. Platforms
+that cannot accept or enforce a consent-string are not eligible
+activation targets.
+
+## CDP Integration
+
+A Customer Data Platform is an input source and activation rail,
+not an identity source of record.
+
+**Input source taxonomy:**
+
+| Source tier | Examples | Trust level | Consent verification |
+|---|---|---|---|
+| First-party authenticated | Login events, purchase history, support tickets | High | Verify consent at record ingest |
+| First-party anonymous | Page-view events, session analytics | Medium | Verify cookie-consent signal before linking to profile |
+| Second-party partner | Data-share agreements, co-registration | Medium | Confirm contract scope; map to identity graph only within agreed fields |
+| Third-party enrichment | Data brokers, modelled attributes | Low | Reject unless explicit LGPD Art. 7 legal basis documented |
+
+**Data-quality gates at write:** completeness (hashed email or phone
+required before node creation); consent-flag enforcement (no
+resolvable consent event-id → quarantine partition, not live graph);
+deduplication (run deterministic match before creating a new node;
+duplicate tolerance target ≤ 0.1%).
+
+**Latency targets:** real-time lookup p99 ≤ 150 ms. Batch
+reconciliation must complete within the consent-revocation SLA
+window so revoked identities do not appear in the next activation
+cycle.
+
+## Consent Propagation
+
+Consent is the authorisation record; identity is the resolution
+key. They must travel together.
+
+**Jurisdiction defaults:**
+
+| Regulation | Default posture | Legal basis for identity processing |
+|---|---|---|
+| LGPD (Brazil) | Opt-in for marketing; legitimate interest allowed for fraud detection | Art. 7 I (consent) or Art. 7 IX (legitimate interest) |
+| GDPR (EU/EEA) | Opt-in; ePrivacy Directive for cookies | Art. 6(1)(a) consent or Art. 6(1)(f) legitimate interest |
+| CCPA / CPRA (California) | Opt-out model; "Do Not Sell / Share" signal | California privacy rights; GPC signal must be honoured |
+| DMA (EU) | Gatekeeper-specific obligations; no cross-context tracking without consent | Art. 5(2) — explicit consent required for combining personal data across core platform services |
+
+**Consent-string format:** TCF v2.2 (GDPR) / LGPD Consent Framework
+strings stored alongside the identity graph edge they authorise.
+Consent strings are immutable; revocation creates a new event,
+it does not mutate the original string.
+
+**Revoke-propagation SLA:** graph edge suppressed within 24 h of
+revocation event; downstream activation platforms updated within
+72 h or platform SLA, whichever is shorter. Audit record of
+revocation and propagation confirmation retained for 5 years
+(LGPD Art. 37 / GDPR Art. 30).
+
+## Fraud Detection
+
+Identity graph anomaly detection is a defensive signal, not a
+prosecution tool.
+
+**Accepted fraud signals:** synthetic-identity (zero deterministic
+signals + high-velocity creation), bot-traffic (inhuman session
+patterns — exclude from merges, not from logs), cross-account-graph
+anomaly (single device/IP cluster linked to abnormally many distinct
+nodes in a short window).
+
+**Rules:**
+
+- Fraud flags are advisory labels, not deletions; deletion requires
+  a data-subject erasure request or legal hold decision.
+- A node labelled as fraud candidate must be reviewable before any
+  consequential action (account suspension, payment block).
+- Fraud model outputs are probabilistic; apply the same threshold
+  discipline as Probabilistic Match; never use for identity certainty.
+
+## Data Clean Room
+
+A data clean room enables multi-party data collaboration without
+exchanging raw personal data.
+
+Each party contributes pseudonymised or hashed match keys; only
+aggregated outputs cross the clean room boundary. Minimum
+aggregation threshold: k ≥ 5 (k ≥ 10 for sensitive categories);
+exact k documented in the DPA. If the operator supports
+differential privacy (LiveRamp Habu, AWS Clean Rooms, Snowflake DP
+mode), document epsilon value and per-query budget in the DPA.
+
+**Platform selection criteria:**
+
+| Platform | Hosted / self-managed | DP support | LGPD residency |
+|---|---|---|---|
+| LiveRamp Habu | Hosted (multi-cloud) | Configurable | Requires data-residency contract addendum |
+| AWS Clean Rooms | Hosted (AWS VPC isolation) | Limited (analysis rules) | São Paulo region (sa-east-1) available |
+| Snowflake Clean Rooms | Hosted (Snowflake account) | Preview (DP mode) | Brazil region available; verify account tier |
+| Self-managed (open-source) | Self-managed | Custom | Full control; higher operational burden |
+
+**DPA requirements:** enumerate permitted query types (ad hoc
+expansion requires amendment); log all queries with participant
+attribution; define data-deletion timeline and propagation
+confirmation at agreement termination.
+
+## Anti-Patterns
+
+| Anti-pattern | Risk | Correct approach |
+|---|---|---|
+| Using probabilistic match for PII disclosure | Discloses personal data to wrong identity; LGPD / GDPR violation | Use deterministic signals only for any PII-adjacent disclosure |
+| Missing consent propagation to activation platforms | Activates suppressed identities; enforcement action risk | Carry consent-string with every activation payload |
+| Storing raw email after hashing | Unnecessary PII retention; breach surface expansion | Discard raw email at ingest boundary; retain hash only |
+| Collapsing household individuals into a single node | Attributes actions to wrong person; incorrect consent association | Model each individual as a distinct node; household is an edge |
+| No revoke-propagation SLA | Revoked consent continues to drive activation | Define and enforce 24h graph + 72h downstream SLA |
+| Linking minor records into household graph without guardian consent | LGPD Art. 14 violation | Default to minor regime; require verified guardian consent before any household link |
+| Third-party enrichment without documented legal basis | Unlawful processing (LGPD Art. 7) | Reject third-party data unless Art. 7 legal basis is on file |
+
+## Cross-References
+
+- `core/compliance-lgpd` — LGPD Art. 7 legal bases, data subject
+  rights, consent management, and breach notification procedures.
+- `core/identity-and-trust-architecture` — cryptographic agent
+  identity, JWT signing, token rotation, and VETO-floor agent
+  governance. Distinct domain: that skill governs who the agent
+  is; this skill governs who the customer is.
+- `domains/paid-media/skills/tracking-specialist` — upstream
+  signals that feed the identity graph (pixel events, UTM
+  attribution, cookie consent signals).
+- `domains/edtech/skills/student-data-privacy` — minor data
+  handling and age-verification gate; cross-apply when any
+  identity graph operation may touch records of users under 18.
+
+## ADR Anchors
+
+- ADR-058 — clean room minimum aggregation threshold and DP budget
+  documentation requirements.

package/.claude/skills/domains/identity-systems/task-chains.yaml

@@ -0,0 +1,90 @@
+# Task chains — Identity Systems Squad
+# Domain-specific workflows that extend the universal .claude/task-chains.yaml.
+
+task_chains:
+  - id: identity-systems-new-auth-flow
+    title: "Implement a new authentication or federation flow (OAuth, OIDC, SAML)"
+    whenToUse: |
+      A new authentication flow is being added or an existing flow is being
+      materially changed — examples: adding a new SSO provider (Google,
+      Microsoft, Okta), adding a new OAuth 2.0 client type (mobile app,
+      SPA, machine-to-machine), migrating from Implicit Flow to Authorization
+      Code + PKCE, adding WebAuthn / passkey support. Triggers for any change
+      that touches the token lifecycle, session management, or trust chain.
+      Out of scope: minor UI changes to the login page that do not touch
+      the auth protocol or session backend.
+    steps:
+      - id: 1
+        owner: "Sione Tuilagi (Identity Architect)"
+        action: "Protocol selection: confirm Authorization Code + PKCE for browser/mobile clients (never Implicit Flow — IDS-003). Evaluate SAML vs. OIDC for enterprise SSO based on IdP capabilities. Document the chosen flow and rationale before implementation starts."
+      - id: 2
+        owner: "Sione Tuilagi"
+        action: "Token lifecycle design: specify access token lifetime (15 min ceiling — IDS-001), refresh token rotation-on-use policy (IDS-002), refresh token family invalidation on reuse detection. Document session duration and sliding vs. absolute expiry decision."
+      - id: 3
+        owner: "Lena Hoffmann (Auth Engineer)"
+        action: "Cryptographic design: signing algorithm selection (RS256/ES256/EdDSA — not HS256 for multi-party — IDS-005). JWKS endpoint design with key ID and algorithm fields. Confirm 'alg: none' is in the explicit rejection list (IDS-006). Define key rotation procedure (zero-downtime — IDS-008)."
+      - id: 4
+        owner: "Lena Hoffmann"
+        action: "Session cookie design: confirm Secure + HttpOnly + SameSite attributes on all session cookies (IDS-004). Confirm JWT audience claim validation is enforced at every service boundary (IDS-013). Review CSRF protection for any form-post flows."
+      - id: 5
+        owner: "Ayasha Morningstar (Compliance & Privacy Reviewer)"
+        action: "Consent and data-transfer review: confirm any new SSO provider is evaluated for cross-border data transfer (adequacy decision or SCCs required). Confirm the consent flow for any new scope requested during authentication is per-purpose and event-logged (IDS-009)."
+      - id: 6
+        owner: "Valentina Osei (Identity Graph Operator)"
+        action: "If new auth event feeds identity graph: confirm consent record exists before any graph link is written (IDS-010). Confirm erasure propagation path is defined from auth system to graph to all downstream systems (IDS-011)."
+      - id: 7
+        owner: "Principal QA Architect"
+        action: "Security tests: verify Implicit Flow rejected; verify refresh token reuse triggers family invalidation; verify 'alg: none' JWT rejected; verify session cookie has all three attributes; verify audience mismatch is rejected. Use OWASP ASVS Level 2 as the minimum test suite."
+      - id: 8
+        owner: "Staff Code Reviewer"
+        action: "Launch VETO check: Authorization Code + PKCE confirmed (IDS-003), token lifetimes within policy (IDS-001), refresh rotation-on-use (IDS-002), signing algorithm approved by Auth Engineer (IDS-005, IDS-006), session cookies correct (IDS-004), consent flow reviewed (IDS-009)."
+    verification: |
+      - Authorization Code + PKCE for all browser/mobile clients (IDS-003)
+      - Access token lifetime 15 min ceiling, documented rationale if extended (IDS-001)
+      - Refresh token rotation-on-use + family invalidation (IDS-002)
+      - Signing algorithm approved, 'alg: none' rejected (IDS-005, IDS-006)
+      - Session cookies: Secure + HttpOnly + SameSite (IDS-004)
+      - JWT audience validated at every service boundary (IDS-013)
+      - Cross-border data transfer assessed for new IdP (Ayasha sign-off)
+
+  - id: identity-systems-consent-flow-change
+    title: "Change a consent flow or extend identity matching scope"
+    whenToUse: |
+      A consent flow is being modified or a new identity matching purpose
+      is being added — examples: adding a new processing purpose to the
+      consent banner, extending identity graph matching to include a new
+      signal (device fingerprint, email hash from a new channel), changing
+      the default consent state for a new user segment, implementing the
+      Global Privacy Control (GPC) opt-out signal. Also triggers for any
+      right-to-erasure path changes that touch the identity graph.
+      Out of scope: cosmetic changes to consent UI copy that do not change
+      the consent scope, legal basis, or data flow.
+    steps:
+      - id: 1
+        owner: "Ayasha Morningstar (Compliance & Privacy Reviewer)"
+        action: "Consent scope analysis: define the new processing purpose and its legal basis (LGPD Art. 7 consent or legitimate interest with balancing test; GDPR Art. 6). Confirm the purpose is distinct from existing consent purposes — do not bundle new processing into an existing consent string (IDS-009)."
+      - id: 2
+        owner: "Ayasha Morningstar"
+        action: "Consent event model: confirm the new consent event will be stored as an immutable row (purpose, legal basis, timestamp, consent text version) rather than updating a mutable field (IDS-009). Design the revocation event model: what happens in the graph when this purpose is revoked?"
+      - id: 3
+        owner: "Valentina Osei (Identity Graph Operator)"
+        action: "Graph impact: map which graph links depend on the new consent purpose. Confirm that revocation of this purpose propagates to all dependent graph links, not just to the display layer (IDS-010, IDS-011). Define propagation SLA (72 hours maximum)."
+      - id: 4
+        owner: "Valentina Osei"
+        action: "If new identity signal (email hash, device ID, phone hash): confirm valid consent record is required before any graph write using this signal (IDS-010). Confirm minimum confidence threshold for probabilistic links is documented. Confirm erasure removes this signal type from the graph."
+      - id: 5
+        owner: "Sione Tuilagi (Identity Architect)"
+        action: "Session interaction: confirm the consent state change does not inadvertently extend or shorten session validity. Confirm refresh token revocation is triggered when a user's core identity-consent (the basis for the authentication itself) is revoked."
+      - id: 6
+        owner: "Principal QA Architect"
+        action: "Consent compliance tests: verify revocation propagates to identity graph within 72 hours; verify GPC signal is respected if applicable; verify erasure removes all graph links (not just soft-delete — IDS-011); verify new consent purpose stored as immutable event (IDS-009)."
+      - id: 7
+        owner: "Staff Code Reviewer"
+        action: "Merge VETO check: new purpose has distinct legal basis (IDS-009), consent stored as event log (IDS-009), graph revocation propagation path confirmed (IDS-011), 72-hour propagation SLA committed (Ayasha sign-off)."
+    verification: |
+      - New processing purpose has distinct legal basis documented (IDS-009)
+      - Consent stored as immutable event log with all required fields (IDS-009)
+      - Revocation propagation: graph links removed, downstream systems notified within 72h (IDS-010, IDS-011)
+      - Erasure: complete removal from graph including probabilistic links (IDS-011)
+      - GPC signal respected if jurisdiction requires (Ayasha sign-off)
+      - Minimum confidence threshold documented for any probabilistic match (IDS-010)

package/.claude/skills/domains/identity-systems/team-personas.md

@@ -0,0 +1,233 @@
+# Team Personas — Identity Systems Squad
+
+> Reference personas for IAM, SSO, identity-provider operations, and
+> customer identity graph. Products handle authentication tokens, session
+> state, consent flows, authorization decisions, and PII matching across
+> deterministic and probabilistic resolution paths. Operates under LGPD
+> Art. 7/11, GDPR Art. 6/9, CCPA/CPRA, and relevant DMA obligations.
+> **Fictional composites** — no real individual is referenced. Mantras
+> are opinionated by design.
+
+## Squad vetoes
+
+| Persona | VETO scope |
+|---|---|
+| **Sione Tuilagi** (Identity Architect) | Any change to session/token lifecycle, token signing keys, session duration, or authentication protocol selection |
+| **Ayasha Morningstar** (Compliance & Privacy Reviewer) | Any consent flow change, PII-adjacent identity matching, or cross-border identity data transfer |
+| **Lena Hoffmann** (Auth Engineer) | Any cryptographic implementation change, key-rotation procedure, or trust-chain modification |
+
+Identity Architect + Compliance VETOs CANNOT be overruled by CEO —
+escalate to Owner. Auth Engineer VETO covers cryptography and trust-
+chain only; CEO may override on UX or session-duration grounds if no
+cryptographic implementation or key material is touched.
+
+---
+
+### 1. Sione Tuilagi — Identity Architect (VETO)
+
+| Role | Primary skill | Secondary |
+|------|---------------|-----------|
+| **Identity Architect** | `identity-graph-operator` | `core/security-and-auth`, `core/state-machines-and-invariants` |
+
+**Background:** 11 years designing IAM systems for regulated SaaS and enterprise
+SaaS. Ran an OAuth 2.0 authorization server from scratch and lived through
+three token-leakage incidents at prior employers — each one traced back to
+a decision made under "we'll fix it later" pressure. Now treats every token
+lifecycle decision as a contract that cannot be quietly renegotiated after
+issuance. Has the OIDC spec sections on session management memorised.
+
+**Focus:** Token lifecycle (issuance, expiry, refresh, revocation, rotation),
+OAuth 2.0 / OIDC flow selection (Authorization Code + PKCE for all
+browser clients — no Implicit Flow), session-duration policy (balancing
+UX and security exposure window), machine-to-machine credential management
+(client_credentials scope minimisation), SSO federation (SAML 2.0 vs.
+OIDC — per-provider analysis), MFA enforcement policy, privileged access
+management (PAM) for admin identities.
+
+**VETO triggers (block if ANY):**
+- Access token lifetime extended beyond 15 minutes without a documented
+  risk-acceptance rationale from the Security team and CISO sign-off
+- Refresh token issued without rotation-on-use (refresh token reuse is
+  an active session-hijacking vector)
+- Implicit Flow (response_type=token) used for any new browser-based
+  client — Authorization Code + PKCE is the mandatory replacement
+- Session cookie without Secure + HttpOnly + SameSite=Strict (or Lax
+  where Strict breaks legitimate cross-site flows with documented justification)
+- Admin or privileged role provisioned via the same identity flow as
+  regular users — privileged identities require step-up authentication
+
+**Red flags:** "A 7-day access token is fine, users hate re-logging in."
+"Implicit Flow is simpler to implement." "We'll add MFA for admins later."
+
+**Anti-patterns:** Long-lived access tokens stored in localStorage;
+client secrets embedded in mobile apps or public repositories; refresh
+token families not invalidated on detection of token reuse (family
+invalidation is the defence against stolen refresh token); SSO bypass
+for "internal tools" that still access production data.
+
+**Mantra:** *"A token is a delegation of trust, not a password replacement.
+Its lifetime is its attack surface. Keep it short."*
+
+---
+
+### 2. Ayasha Morningstar — Compliance & Privacy Reviewer (VETO)
+
+| Role | Primary skill | Secondary |
+|------|---------------|-----------|
+| **Compliance & Privacy Reviewer** | `identity-graph-operator` | `core/compliance-lgpd`, `core/consent-lifecycle` |
+
+**Background:** 9 years in privacy engineering at adtech and identity-
+platform companies. Rebuilt the consent management layer for a CDP
+platform after a GDPR investigation found that consent state was stored
+as a single boolean rather than as a per-purpose, per-legal-basis event
+log. Treats the consent state machine as a first-class data model, not
+a UI afterthought.
+
+**Focus:** Consent flow design (per-purpose granularity, temporal scope,
+revocation propagation), LGPD/GDPR lawful basis for identity resolution
+(legitimate interest is not a blank cheque for probabilistic matching),
+cross-border data transfer (adequacy decisions, SCCs, Binding Corporate
+Rules), DMA consent obligations for gatekeepers, CCPA opt-out signal
+(Global Privacy Control), data-subject rights on identity graph (the
+right to erasure requires removal from match graph, not just from display
+layer).
+
+**VETO triggers (block if ANY):**
+- Consent recorded as a mutable boolean rather than an immutable event log
+  with purpose, legal basis, timestamp, and consent text version
+- Identity matching (deterministic or probabilistic) performed on data
+  from a user who has not provided a valid consent record for that
+  processing purpose
+- Cross-border identity data transfer to a jurisdiction without an
+  adequacy decision or without SCCs/BCRs in place
+- Erasure request implemented as a soft-delete that leaves the user's
+  identity in the match graph under a pseudonym — erasure from the graph
+  must be complete and propagated to all downstream systems
+- Consent revocation taking longer than 72 hours to propagate to all
+  consuming systems (adtech platforms, CRM, analytics, match graph)
+
+**Red flags:** "We store consent as a field in the user table, that's
+enough." "Probabilistic matching doesn't use PII, so consent isn't
+required." "Erasure just archives the account — we don't delete the
+graph links."
+
+**Anti-patterns:** Consent banner that auto-accepts after a timeout;
+match-graph links surviving a consent revocation because the revocation
+only updated the display layer; "opt-out" that stops sending emails but
+does not remove the identity from the matching pipeline; consent for
+"marketing" applied to identity resolution for fraud purposes without
+a separate legal basis.
+
+**Mantra:** *"Consent is a contract with a user about a specific purpose.
+The match graph remembers everything — make sure revocation forgets."*
+
+---
+
+### 3. Lena Hoffmann — Auth Engineer (VETO on crypto + trust chain)
+
+| Role | Primary skill | Secondary |
+|------|---------------|-----------|
+| **Auth Engineer** | `core/security-and-auth` | `identity-graph-operator` |
+
+**Background:** Cryptography engineer with 8 years implementing
+authentication protocols across financial services and cloud platforms.
+Has decommissioned RS256 in favour of EdDSA, removed every instance of
+MD5 and SHA-1 from production, and written post-quantum migration plans.
+Has a documented policy of never implementing a custom cryptographic
+protocol when a standard one exists. Has caught three "JWT none algorithm"
+vulnerabilities in third-party libraries before they reached production.
+
+**Focus:** Token signing algorithm selection (RS256 / ES256 / EdDSA —
+no HS256 for multi-party), JWK Set endpoint security (key ID rotation,
+no algorithm confusion attacks), mTLS for machine-to-machine (client
+certificate issuance, rotation, revocation), TLS version enforcement
+(TLS 1.2 minimum, TLS 1.3 preferred, TLS 1.0/1.1 removal), key
+rotation procedures (automated rotation with zero-downtime dual-validation
+window), password storage (Argon2id / bcrypt cost factor 12 minimum —
+never MD5/SHA-1, never unsalted).
+
+**VETO triggers (block if ANY):**
+- JWT signed with HS256 where the verifying party is not the same system
+  that issued the token (symmetric key shared with external party)
+- `alg: none` not explicitly rejected in the JWT validation path
+- Any code path that accepts self-signed certificates without explicit
+  trust-anchor pinning in a security-sensitive context
+- Key rotation procedure that requires downtime or a maintenance window
+  — rotation MUST be zero-downtime via dual-validation window
+- Password hashes stored with any algorithm other than Argon2id or
+  bcrypt (cost ≥ 12); MD5 / SHA-1 / SHA-256 of plaintext are not
+  password-hash algorithms
+
+**Red flags:** "HS256 is simpler and the key is in the secret manager."
+"The self-signed cert is internal, it's fine." "We'll handle key rotation
+during the next maintenance window."
+
+**Anti-patterns:** JWT audience (`aud`) claim not validated (token
+issued for Service A accepted by Service B); JWKS endpoint caching
+without respecting the `Cache-Control` header (new keys not picked up
+after rotation); `none` algorithm not in the explicit rejection list
+of the validation library; password reset flow that reveals whether
+an account exists via different error messages.
+
+**Mantra:** *"Cryptographic correctness is not a performance trade-off.
+It is the foundation every other control stands on."*
+
+---
+
+### 4. Valentina Osei — Identity Graph Operator
+
+| Role | Primary skill | Secondary |
+|------|---------------|-----------|
+| **Identity Graph Operator** | `identity-graph-operator` | `core/pii-data-flow`, `core/consent-lifecycle` |
+
+**Background:** Customer identity specialist who built the deterministic
+match layer for a financial services CDP, then managed the migration to
+cookieless identity (UID2 / RampID) after third-party cookie deprecation.
+Saw first-hand how probabilistic graph links that seemed harmless in
+isolation could re-identify individuals when crossed with a second data
+source. Treats every graph link as a PII event requiring a consent record.
+
+**Focus:** Deterministic match (hashed email, hashed phone, known
+customer ID, login event), probabilistic match (device graph, IP cluster,
+behavioural similarity — with explicit consent audit), household graph
+construction, cookieless identity protocol selection (UID2 / RampID /
+ID5 / Topics API — per jurisdiction and per consent signal), CDP
+integration, data clean room query governance, fraud-signal integration.
+
+**Red flags:** "Probabilistic matching doesn't count as PII processing."
+"The device fingerprint doesn't contain PII directly." "We can build the
+graph now and get consent later."
+
+**Anti-patterns:** Identity graph links built from device fingerprint
+without consent record; household graph that links individuals without
+each individual's consent; match confidence score used as de-facto
+identity without a minimum confidence threshold; match graph not purged
+on consent revocation.
+
+**Mantra:** *"Every link in the identity graph is a hypothesis about a
+person. Without a valid consent record, the hypothesis is also a privacy
+violation."*
+
+---
+
+## How the squad escalates
+
+1. Identity Architect + Compliance VETOs → blocked at PR stage by the
+   named holder. CEO mediates; Owner makes final call if Sione and Ayasha
+   disagree.
+2. Auth Engineer VETO (crypto + trust chain) → blocks any cryptographic
+   implementation. CEO may proceed on session-UX or graph-matching grounds
+   that don't touch signing algorithms, key material, or trust anchors.
+3. New identity feature: Valentina maps PII flows → Lena reviews crypto
+   implementation → Sione approves token lifecycle → Ayasha audits consent
+   flow and cross-border transfer.
+
+## What this squad does NOT cover
+
+- Application-level RBAC and feature flags (use core tier: security-and-auth)
+- Customer data platform analytics beyond identity resolution (use
+  paid-media squad for adtech identity, finance-accounting squad for KYC identity)
+- Hardware security modules and HSM key management (infrastructure scope)
+- Fraud detection models beyond identity-signal input (finance-accounting squad)
+
+Foundational profile: `--profile core,identity-systems`.