--- type: source-summary title: 'Source: compliance-dashboard.html' modified: 2026-04-07 tags: - compliance-dashboard - soc2 - governance - source - preston-test --- # Source: compliance-dashboard.html ## What this source is The **live SOC 2 Compliance Dashboard** — the governance evidence artifact referenced as proof for claim #3 in [[sources/09-claim-proof-matrix]] ("Governance evidence is live") and as the required verification artifact in [[pages/role-briefs/cto|CTO role brief]]. This is the most important governance source for any CTO or compliance-focused reviewer. The page has **5 collapsible SOC 2 Trust Services Criteria panels**, each with specific implementation details and source-code paths. It also has a **live data panel** that fetches from `/api/compliance/summary` and falls back to a representative snapshot when unauthenticated. An **evidence export button** triggers `/api/compliance/export` with a date range and downloads a JSON package. Read directly from the canonical Preston-Test HTML file. Text + 5 SOC2 panel contents + metric cards + regulatory timeline extracted; HTML/Alpine.js/JS scaffolding omitted. ## Key claims ### SOC 2 Trust Services Criteria — five categories, all marked "Implemented" 1. **CC6 — Security (Logical & Physical Access Controls)**: - JWT Authentication (source: `src/middleware/auth.ts`) - RBAC Permissions (source: `src/middleware/rbac.ts`) - Timing-Safe API Key Validation (`crypto.timingSafeEqual` prevents timing attacks) - Rate Limiting enforced in production, fail-fast guard on misconfiguration - Production Guards (JWT_SECRET validation, demo-mode blocking, rate-limit enforcement at startup) 2. **A1 — Availability (Recovery & Continuity)**: - Health Check Endpoints (`/health`) - Circuit Breaker Pattern - Disaster Recovery with RTO/RPO targets - Auto-Scaling: Kubernetes Helm chart with 2-10 replica scaling (Helm + Terraform IaC) 3. **PI1 — Processing Integrity (Accuracy & Completeness)**: - AI Confidence Scoring (0-100 with breakdown) - Hallucination Detection — GovernanceService validates AI output against known schemas - Schema Drift Blocking — syncs blocked on critical drift; structured `SCHEMA_DRIFT_BLOCKED` result - Reasoning Traces — DB-persisted step-by-step AI decision audit trail 4. **C1 — Confidentiality (Information Protection)**: - DLP/PII Detection: **8 patterns — SSN, credit card, email, phone, DOB, passport, bank account, driver license** (definitive enumeration) - Sensitive Data Masking via shared `maskSensitiveData()` utility - Encrypted Credential Storage via ConnectorCredentialService 5. **P1 — Privacy (Notice, Consent & Retention)**: - GDPR/CCPA Compliance - Audit Trail Logging (user ID, timestamp, action type) - Data Retention Policies — 90-day default purge cycle, configurable ### Live compliance metrics (four stat cards) - **Reasoning Traces**: DB-persisted sessions, all time - **AI Cost Total**: $ across all providers, last 30 days - **Audit Actions**: Session-scoped event log, since startup - **Compliance Rate**: Actions passing governance, % Demo fallback values (shown when unauthenticated): - 42 reasoning traces - $3.87 AI cost - 156 audit actions - 97.4% compliance rate ### Evidence export POST to `/api/compliance/export` with `startDate` and `endDate` → downloads a structured JSON evidence package. This is the "evidence package exported and reviewed" gate metric from [[sources/13-pilot-30-60-90]] — the literal download button that produces the artifact. ### Regulatory timeline (two dates shown on dashboard) - **EU AI Act — August 2, 2026**: Full enforcement of high-risk AI system requirements (transparency obligations, conformity assessments, post-market monitoring). - **Colorado AI Act (SB 24-205) — June 30, 2026**: Requires developers and deployers of high-risk AI systems to use reasonable care to prevent algorithmic discrimination. ### "Built by Auditors" callouts Three callouts at the bottom of the page: - **CPA-Grade Audit Trails**: Every AI decision logged with user, timestamp, inputs, outputs, confidence score — *"the same rigor Squire applies to client engagements"* (explicit Squire framing) - **SOC 2 Alignment from Day 1**: *"Not a retrofit — compliance was a design requirement from the first commit"* - **Evidence Export in One Click**: Download a structured JSON evidence package ready for the SOC 2 auditor ## Pages updated by this ingest **Created** (1 new page): - [[pages/entities/compliance-dashboard]] — the dashboard as a reviewer-facing artifact, with the full 5-category SOC 2 TSC mapping, live metrics structure, evidence export flow, and regulatory timeline **Updated** (4 existing pages): - [[pages/concepts/production-proof]] — added the 5-category SOC 2 TSC compliance claim with implementation detail - [[pages/role-briefs/cto]] — the "what to validate: SOC 2 Trust Services Criteria mapping" ask now has a specific URL and specific expectations (5 categories, each with implementation details and source code paths) - [[pages/concepts/claim-proof-matrix]] — claim #3 ("Governance evidence is live") now has a dedicated compliance-dashboard entity page to link to - [[pages/concepts/nl-action-gate]] — the "Approved to Apply" mechanism is now documented as part of PI1 Processing Integrity + implicitly via Audit Trail Logging in P1 ## Notable quotes > "All five Trust Services Criteria mapped to production code. Not a retrofit — compliance was a design requirement from the first commit." > — Built by Auditors section > "SOC 2 Compliance Dashboard — SuiteCentral 2.0 — Built by Auditors, for Auditability" > — Page header subtitle > "The same rigor Squire applies to client engagements." > — CPA-Grade Audit Trails callout (explicit Squire framing) ## Cross-references / contradictions found - **DLP pattern count — CORRECTED 2026-04-07**: the initial NotebookLM scrape of this page extracted "8 patterns (SSN, credit card, email, phone, DOB, passport, bank account, driver license)." This was **a scrape artifact** — NotebookLM captured a pre-Alpine.js render state that did not reflect the actual dynamic content. Reading the actual HTML source in the repo (`public/compliance-dashboard.html` lines 375-378) reveals the JavaScript snapshot is **14 patterns**: "SSN, credit card, email, phone, intl phone, medical record, IP address, API key, JWT, bank account, DOB, passport, driver's license, name." The dashboard also fetches live from `/api/compliance/dlp-patterns` when authenticated. Of the 14 snapshot items, 10 have confirmed regex implementations in `DLPService.ts`, 1 (`name`) is in `GovernanceService.ts`, and 3 (DOB, passport, driver's license) are not found as regex patterns in either service file — they may be behind the API endpoint at runtime or represent planned additions. - **Confirms SOC 2 TSC framework**: third/fourth/fifth-source confirmation that the SOC 2 compliance work targets the Trust Services Criteria specifically (not generic SOC 2). This source maps each of the five TSC categories to production code paths. - **Schema Drift Shield detail**: this source names `SCHEMA_DRIFT_BLOCKED` as the structured result code returned when a sync is blocked on critical drift. First formally-ingested specific result code for the Schema Drift Shield. Related to [[sources/04-technical-proof]] Tier 3 Schema Drift Shield v3.3.0 entry. - **Regulatory timeline (two laws, two dates)**: EU AI Act Aug 2 2026 + Colorado AI Act Jun 30 2026. [[sources/oracle-comparison]] mentions only the EU AI Act date. This source adds the Colorado law. Combined, they give Brain1 two regulatory deadlines to track. - **Source code paths in the dashboard**: the CC6 Security panel cites `src/middleware/auth.ts` and `src/middleware/rbac.ts` — these are exact file paths in the Preston-Test repo. A CTO could open those files directly to verify the implementation. - **"First commit" claim** (SOC 2 Alignment from Day 1): *"compliance was a design requirement from the first commit"* is a strong claim. Hard to verify without git history analysis, but the source makes it explicitly. ## Notes - This source is the **missing piece of the CTO's SOC 2 verification workflow**. [[sources/11-role-brief-cto]] said the CTO should verify "Compliance evidence export and SOC 2 mappings." This page is literally that evidence, with specific mappings and a working export. - The **live data + snapshot fallback** pattern is important: the dashboard runs in two modes. When running against a live instance with authentication, it shows real numbers. When running as a static demo (most reviewers), it shows representative values (42 reasoning traces, 97.4% compliance rate). Reviewers need to know which mode they're in — there's a "Snapshot" vs "Live API data" indicator at the top. - **The evidence export is a POST with a 30-day default range** — the implementation downloads the last 30 days of compliance evidence as JSON. Reviewers who test this in snapshot mode will see it fail with an "Authentication required" message. - **Source file paths in the dashboard are a strong signal**: a CTO who wants to verify the JWT implementation can open `src/middleware/auth.ts` directly. This is the dashboard design making "trust by looking" feasible. - **CPA-grade audit trail framing**: the page explicitly frames its audit-trail rigor as *"the same rigor Squire applies to client engagements"* — turning Squire's own CPA-firm DNA into a product requirement. This is the strongest tie-to-Squire language in any ingested source.