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 09-claim-proof-matrix (“Governance evidence is live”) and as the required verification artifact in 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 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):

• 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):

• production-proof — added the 5-category SOC 2 TSC compliance claim with implementation detail
• 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)
• claim-proof-matrix — claim #3 (“Governance evidence is live”) now has a dedicated compliance-dashboard entity page to link to
• 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 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. 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. 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.