Web application providing compliance officers, external auditors, data subjects, and domain experts with secure access to the platform's regulatory compliance engine — audit trails, evidence packages, human gate decisions, DSR management, model card governance, and regulatory report generation.
Operator Cockpit
Developer Workbench
Compliance & HITL
Data Subject Self-Service
10 endpoints · Single enforcement boundary
7 Compliance Tables
Process Knowledge
Ed25519-Signed Packages
Hash-Chain Immutable
PRD 18 specifies 50 regulatory compliance requirements — human gate decisions, evidence packages, DSR workflows, model card governance, incident management, regulatory reporting — implemented through a compliance service with 10 REST endpoints and 7 database tables. The enforcement engine exists. What doesn't exist is the interface for the humans who aren't the platform operator.
Five categories of people are implicitly promised service by PRD 18's requirements and have no way to receive it:
Triage DSRs within GDPR's 30-day window, approve gate decisions, manage incidents against NY DFS's 72-hour clock, sign off on model reviews
Scoped, time-limited access to evidence packages, audit chains, gate records, and model cards for working papers
Self-service for GDPR Articles 15–22: access, erasure, portability, rectification, objection requests
Review extracted knowledge candidates from the Process Knowledge Base — rules, decision trees, SOPs
Read-only access to BRDs, architecture specs, outcome metrics, and cost reports
The portal reads from and writes to the same compliance service, audit store, evidence packages, model card registry, and DSR router that the App and CLI access through MCP. It is not a separate system — it is a different protocol (HTTP) in front of the same enforcement boundary. App is mobile operator cockpit, CLI is developer workbench, Portal is the compliance surface for everyone else.
Following PRD 6 precedent (Memory Dashboard): FastAPI + HTMX + D3.js + Chart.js. Same architectural pattern, extended for additional views.
Internal portal — behind Netbird-protected reverse proxy. OIDC authentication against shared IdP with role-based access control.
Public DSR portal — separate container, separate domain, rate-limited, WAF-protected, isolated from internal services. Verified requests push into the internal compliance service queue — no direct database access.
| Role | Access Scope | Write Permissions |
|---|---|---|
admin | Full | User management, role assignment |
compliance_officer | All compliance surfaces | Gate decisions, DSR resolution, incident notes, model card reviews |
auditor | Scoped by engagement + date range | None (read-only + download) |
sme | Process knowledge queue | Approve/reject/modify knowledge candidates |
viewer | Project docs, dashboards, reports | None |
Read-only interface to PRD 18's immutable_audit_events table. Hash-chain verification visible in UI.
Interface to PRD 18's evidence_packages table. Ed25519-signed bundles.
Interface to PRD 18's human_gate_decisions table.
Full lifecycle for GDPR Articles 15–22. Internal form + public self-service.
NY DFS 72-hour notification workflow via PRD 18's incident_records.
NAIC/SR 11-7 model governance via PRD 18's model_cards table.
On-demand regulator-ready artifacts from accumulated evidence.
Multi-framework scoring from PRD 5 governance MCP tools.
Interface to PRD 14 human verification gate.
immutable_audit_events directly — all through compliance service REST API.Build a compliance portal web application for the agentic AI platform:
1. INFRASTRUCTURE: FastAPI + HTMX + D3.js + Chart.js. Two containers:
internal portal (Netbird-protected) and public DSR portal (WAF,
rate-limited, CAPTCHA, isolated). OIDC auth with 5 roles:
admin, compliance_officer, auditor, sme, viewer.
2. AUDIT EXPLORER: Read-only view of immutable_audit_events with
hash-chain verification, session timeline reconstruction, filters
(time/user/session/type/classification), JSONL export.
3. EVIDENCE PACKAGES: Ed25519 signature verification, version history,
diff view, download with audit logging, watermarked PDF for auditors.
4. GATE DECISIONS: Pending queue, evidence presentation panel,
approve/deny/escalate with rationale, MFA step-up for
confidential/restricted, SOX separation-of-duties, signed receipts.
5. DSR MANAGEMENT: GDPR Art 15-22 intake (internal + public),
30-day SLA countdown with escalation alerts, status workflow
(received-verified-processing-evidence_generated-delivered-closed),
filtered evidence package generation, secure delivery.
6. INCIDENTS: 72-hour NY DFS countdown, investigation notes,
affected session linkage, notification tracking,
auto-populated post-incident reports.
7. MODEL CARDS: Registry (Opus/Sonnet/Haiku/Gemini/nomic-embed-text),
NAIC responsible persons, annual review scheduling with reminders,
review workflow with sign-off.
8. REGULATORY REPORTS: On-demand generation of SOX attestation,
NY DFS certification, EU AI Act conformity, NAIC adverse action.
Ed25519 signed, draft-review-approve-sign-deliver workflow.
9. COMPLIANCE DASHBOARDS: ISO 42001, EU AI Act, OWASP, SOC 2,
ISO 27001, GLBA scoring with trends, gap analysis drill-down.
10. PROCESS KNOWLEDGE: Verification queue for PRD 14 extracted
knowledge with YAML diff viewer, approve/reject/modify,
domain expert assignment, batch operations.
11. OUTCOME VIEWS: Cost per outcome, quality trends, ROI,
agent economics, forecasting with confidence intervals.
Critical constraint: portal calls compliance service REST API only.
Zero business logic in portal. Auditor access assumes credential
compromise: time-boxed, watermarked, scoped, instant-revoke.
Public DSR surface is architecturally separate from internal portal.The portal is deliberately not a CRUD application. It renders data produced by the compliance engine and captures a small number of specific human decisions. Every write path maps to a PRD 18 requirement that mandates human involvement.
The public DSR portal and internal portal share a codebase but deploy as separate containers with separate domains, separate auth flows, and separate network exposure. A compromised public endpoint cannot reach internal compliance surfaces.
Server-rendered partials rather than React/Vue. Smaller attack surface (no client-side state to tamper with), simpler security model (auth is server-side only), faster time to render, and consistency with PRD 6. Compliance interfaces need to be boring, reliable, and auditable.
Time-boxed to engagement window with no renewal mechanism. Downloads watermarked with auditor identity. Every artifact view logged. Revocation is instant and total. Scope is minimum required per engagement.
The compliance service (PRD 18) owns all business logic. The portal calls the service's REST API. If logic appears in the portal that should be in the service, it migrates to the service. This prevents drift between surfaces.
PRD 6 Memory Dashboard is an operator tool. The compliance portal is for non-operators. Distinct applications with distinct auth, access models, and purposes. Mixing them creates access control confusion.
Primary integration. Portal renders and captures decisions against all 7 compliance tables through compliance service REST API (10 endpoints).
Incident triggers from Guardian TERMINATE. Portal traffic monitored by behavioral analysis. Session timeline reconstruction.
Verification queue surfaces extracted knowledge candidates for domain expert review. Approved knowledge enters production.
Compliance dashboard scores from governance MCP tools (compliance_dashboard, governance_report, governance_gap_analysis).
A2A gateway patterns applied to portal HTTP endpoints. Authentication, rate limiting, audit from PRD 17.
Project documentation rendering uses PRD 7's proxy for clean markdown-to-HTML conversion of BRDs and specs.
Authentication and RBAC. Audit explorer with hash-chain verification. Evidence package library with watermarked downloads. Gate decision workspace with SOX separation-of-duties.
Exit criteria: compliance officer can approve a pending gate; auditor can access scoped evidence with watermarked download; audit explorer renders verified timeline.
DSR management with 30-day SLA. Incident console with 72-hour countdown. Model card registry. Regulatory report generation. Public DSR portal deployment.
Exit criteria: data subject can submit GDPR request through public portal; incident clock fires notifications; all four regulatory report types generate.
Process knowledge verification queue. Compliance dashboards. Outcome and economics views. Batch operations for high-volume review cycles.
Exit criteria: domain expert can review knowledge batches; compliance dashboards show accurate scores with trends; stakeholders can access reports.
Each phase is independently valuable and deployable. Phase 1 gets you defensible within two months. The full portal is 4–5 months. Build in parallel with the existing App + CLI + VPS stack.