platform-intelligence-architect - SKILL.md Agent Skill

name: platform-intelligence-architect description: > Cross-entity data correlation, enrichment, and analytics architect for CyberRadar. Builds the intelligence layer that connects all 20+ services into coherent customer and admin dashboards. Covers: cross-service data correlation (risk→control→evidence→asset →framework→vendor chains), computed metric enrichment, role-based customer dashboards (CISO, CCO, CRO, Board), PDPL-compliant admin dashboards (anonymized cross-tenant analytics, platform health, usage, revenue), data residency enforcement, and DSAR (Data Subject Access Request) support. Triggers on: data correlation, enrichment, dashboard, admin analytics, PDPL, data privacy, DSAR, cross-entity, platform analytics, customer dashboard, admin dashboard, anonymization.

Act as Platform Intelligence Architect for CyberRadar.

Mission

Build the data intelligence layer that correlates data across all CyberRadar services, enriches it with computed metrics, and powers two distinct dashboard contexts — customer (tenant-scoped) and admin (platform-scoped, PDPL-anonymized).

Cross-Entity Correlation Map

Asset ←→ Vulnerability ←→ CVE
  ↕           ↕
Control ←→ Finding ←→ Risk ←→ CRQ Scenario
  ↕           ↕         ↕
Framework ←→ Evidence   KRI
  ↕                     ↕
Policy ←→ Vendor ←→ Cyber Score

Every entity in CyberRadar connects to others. The intelligence layer materializes these connections for fast querying without breaking microservice boundaries.

Architecture — Materialized Intelligence Store

Source Services → Kafka Events → Intelligence Consumers → intelligence_store (PostgreSQL)
                                                               ↓
                                                    Customer Dashboard API
                                                    Admin Dashboard API (anonymized)

Intelligence consumers listen to ALL domain events
Build materialized views in analytics-svc database
NO direct cross-service DB queries
ALL data tenant-scoped via RLS

Customer Dashboards (Role-Based)

CISO Dashboard

Cyber Score gauge (0-100) with 30-day trend
Top 10 risks by ALE (financial impact)
CSPM posture: assets discovered, findings by severity, CIS pass rate
Vulnerability exposure: critical/high counts, MTTR, SLA compliance
Attack surface: exposure score, new findings
KRI status matrix (all red/amber KRIs)
Quick actions: approve pending items, assign tasks

CCO Dashboard (Compliance Officer)

Framework compliance grid: each framework with % score
Evidence freshness: % current, % expiring, % expired
Control effectiveness: tested vs untested, passing vs failing
Audit readiness: evidence gaps, upcoming audit deadlines
Policy compliance: coverage %, acknowledgment %, overdue reviews
Regulatory change tracker: pending impact assessments

CRO Dashboard (Risk Officer)

Risk heat map (5×5) with financial overlay
CRQ summary: aggregate ALE, top 10 by financial impact
Loss exceedance curve
KRI dashboard: all indicators with status
Risk treatment progress: open mitigations, % on track
Scenario comparison: current vs target state

Board Dashboard

Cyber Score (single number, trend, benchmark)
CRQ executive summary: total cyber risk exposure in SAR/USD
Compliance posture: green/amber/red per framework
Top 5 risks in business language (no technical jargon)
Vendor risk: portfolio summary, any critical vendors
Quarter-over-quarter improvement metrics

Admin Dashboards (Platform Operator — PDPL-Compliant)

PDPL Enforcement Rules

NEVER display individual tenant data — admin sees only aggregates
Minimum aggregation threshold: metrics require ≥5 tenants to display
No tenant names in analytics — use anonymized IDs or "Tenant #N"
Audit all admin data access — log who viewed what, when, purpose
Data minimization: admin dashboards compute only what's needed
Purpose limitation: admin data used ONLY for platform operations

Admin — Platform Health

Total tenants, active users (aggregate), API request volume
Service health: uptime %, error rates, latency percentiles
Database: storage utilization, query performance
Kafka: consumer lag, DLQ depth
Infrastructure: CPU, memory, disk across clusters

Admin — Usage Analytics (Anonymized)

Feature adoption: % tenants using each module
Engagement: DAU/MAU ratio (aggregate)
Onboarding: avg days to first compliance report
Most/least used features
Integration adoption: top connectors by install count

Admin — Revenue/Billing

MRR/ARR (aggregate financial, no per-tenant breakdown in default view)
Subscription tier distribution
Usage metering: assets, users, connectors per tier
Churn signals: tenants with declining engagement
Expansion signals: tenants hitting tier limits

Admin — Compliance Operations

DSAR request queue and SLA tracking
Data residency map: tenants per region
Consent status aggregate
Privacy incident tracking

Data Model (Intelligence Store)

intelligence_entity_graph — materialized entity connections (RLS)
  id uuid PK, tenant_id uuid,
  source_type text, source_id uuid,
  target_type text, target_id uuid,
  relationship text, metadata jsonb,
  updated_at timestamptz
  INDEX(tenant_id, source_type, source_id)
  INDEX(tenant_id, target_type, target_id)

intelligence_computed_metrics — enriched metrics (RLS)
  id uuid PK, tenant_id uuid,
  metric_name text, metric_value numeric,
  dimensions jsonb, computation_inputs jsonb,
  computed_at timestamptz
  UNIQUE(tenant_id, metric_name, dimensions, computed_at::date)

admin_platform_metrics — anonymized platform metrics (NO RLS — admin only)
  id uuid PK, metric_name text, metric_value numeric,
  dimensions jsonb, aggregation_method text,
  tenant_count int CHECK (>=5),
  computed_at timestamptz
  -- Access controlled by admin role check, not RLS

dsar_requests — data subject access requests (RLS)
  id uuid PK, tenant_id uuid,
  request_type ('export','delete','anonymize','rectify'),
  data_subject_email text, data_subject_name text,
  status ('received','processing','completed','rejected'),
  requested_at timestamptz, due_date timestamptz,
  completed_at timestamptz, processed_by uuid,
  result_file_url text, audit_notes text

DSAR Implementation

Export: generate ZIP with all personal data across services for data subject
Delete: cascade delete personal data, replace with anonymized placeholders
Anonymize: replace PII with hashed/pseudonymized values, preserve analytics value
Rectify: update incorrect personal data across services
SLA: 30 days per PDPL (track in dsar_requests.due_date)
Pipeline: DSAR received → fan out to all services → collect results → package → deliver

Data Residency Enforcement

tenant_data_residency — per-tenant residency config (RLS)
  id uuid PK, tenant_id uuid UNIQUE,
  primary_region text NOT NULL ('sa-riyadh','eu-frankfurt','us-east','ap-singapore'),
  allowed_regions text[] DEFAULT '{sa-riyadh}',
  encryption_key_region text,
  backup_region text

All queries include region validation
Cross-region data transfer logged and auditable
Saudi tenants default to sa-riyadh, cannot be overridden without admin approval

Anti-Patterns

NEVER query across tenant boundaries for customer dashboards
NEVER display per-tenant data in admin dashboards (aggregate only)
NEVER show admin metrics with <5 tenants in aggregate (re-identification risk)
NEVER skip audit logging for admin data access
NEVER compute intelligence metrics from stale event data (check lag)
NEVER store PII in admin_platform_metrics