¶

PRD¶

for¶

OpenComplAI.org¶

¶

Open-Source AI Compliance OS¶

¶

Document Control¶

¶

Change History¶

¶

1. Executive Summary¶

Open-Source AI Compliance OS is a local-first compliance platform that encodes EU AI Act obligations into deterministic checks, immutable evidence, and release-gating controls.

Provider-first start: initial releases prioritize AI providers (builders/marketers of AI systems) by embedding compliance into provider CI/CD and release workflows, producing audit-grade evidence and Annex IV technical documentation per release candidate.

Distribution-first: the project ships as an official containerized reference deployment for provider teams (Docker Compose) and as hardened enterprise distributions for regulated environments. The open-source core remains local-first; paid offerings focus on operational hardening, integrations, and support.

Outcomes¶

• Prevent non-compliant provider releases by enforcing compliance checks inside CI/CD.
• Produce tamper-evident evidence for audits, customer due diligence, and incidents.
• Detects provider-role shifts from substantial modification before production impact.
• Generate Annex IV technical documentation from system-of-record evidence per release candidate.

Success Criteria¶

• 100% regulated release pipelines use compliance gates.
• >= 3 provider release pipelines use compliance gates with signed status artifacts.
• Providers can deploy the reference distribution with Docker Compose and complete a passing `compliance check` within 15 minutes of install on a clean workstation.
• Secure 10-15 active design partners for the premium offering (can be unpaid) that install the open-source core and provide structured feedback.
• Reach 100+ active installations or stars on the public repository after launch.
• 100% official release artifacts include signed container images and an SBOM for supply-chain verification.
• 100% high-risk decisions produce immutable audit events.
• 0 sensitive-data egress beyond approved metadata schema.
• 99%+ dossier generation success rate per release candidate.

¶

2. Product Scope¶

In Scope (MVP)¶

• Evidence Vault (immutable logging and proof export)
• Risk Engine (Annex III classification, profiling override, substantial modification trap)
• Ground Truth Verification Graph (proof-or-alert workflow)
• Human-in-the-Loop state machine with mandatory rationale
• Documentation Generator (Art 11, Annex IV)
• Compliance-as-Code CLI/API
• Metadata-only sync through hardened egress policy
• Provider CI/CD integration (status artifacts, exit codes, deterministic gates)
• Dockerized reference deployment (Docker Compose) with persistent volumes for evidence, keys, and configuration
• Supply-chain integrity for releases (signed artifacts and SBOMs)
• Premium dashboard (metadata-only) for providers: hosted reporting and monitoring that ingests only allowlisted non-sensitive metadata artifacts (no raw evidence)

Out of Scope (MVP)¶

• Full legal advisory engine
• Non-EU framework automation packs
• Multi-tenant hosted SaaS for sensitive evidence workloads or raw evidence ingestion
• Autonomous legal interpretation via generative-only reasoning
• Deployer/operator runtime decision verification at high volume
• Deployer-side operational dashboards beyond exported metrics
• Fully managed hosted control-plane for customer evidence workloads

¶

3. Personas and User Problems¶

¶

4. System Architecture Overview¶

4.1 Components¶

• Compliance Gateway (CLI/API)
• Risk Engine
• Evidence Vault
• Ground Truth Verification Graph
• HITL Orchestrator
• Documentation Generator
• Egress Proxy

4.2 Local-First Boundary (Black Hole Region)¶

Local-only data classes:

• Raw training/validation/testing datasets
• Full inference payloads and detailed logs
• Model weights
• Pseudonymized special-category attributes for bias correction

Cloud-sync data classes:

• compliance_status
• last_assessment_ts
• risk_class
• aggregate, non-identifying health metrics

Dashboard ingest data classes (strictly metadata-only):

• system_id, commit_ref, policy_bundle_version
• risk_class, control pass/fail rates, pending_verifications_count
• Signed status artifacts (first_scan_status JSON + signature)
• Dossier bundle metadata (bundle_checksum, size_bytes, signed_by, timestamp)
• Aggregated event counts and metrics (non-identifying): pass/fail counts, trap frequency, override rates

4.3 Architectural Stress-Test Fixes Applied¶

• Replaced implicit/manual approval flow with explicit state machine transitions and hard release tokens.
• Replaced vague "alerting" with thresholded severity levels and deterministic freeze criteria.
• Replaced free-form sync with schema-allowlisted metadata channel and fail-closed enforcement.

¶

4.4 Deployment and Dockerization (Provider-First)¶

The reference deployment is a single-node, local-first container topology designed for provider teams to run in workstations and CI agents. It enforces the local-first boundary by default and requires explicit configuration for any metadata sync.

Supported modes:

• Docker Compose reference distribution for providers (default).
• Air-gapped mode: all verification dependencies disabled or replaced with offline adapters; metadata sync disabled; evidence export enabled.
• Kubernetes distribution (enterprise): supported as a paid packaging track; not required for MVP usage.

Container topology (logical):

• gateway-api: exposes the REST API and serves the CLI when used in client/server mode.
• risk-engine: deterministic classification and trap detection service.
• evidence-vault: append-only ledger and content-addressable evidence store.
• doc-generator: Annex IV bundle generator.
• egress-proxy: the only component allowed to call external endpoints; enforces allowlisted schema and destinations.

Persistent storage:

• evidence_data: immutable event ledger + CAS evidence objects.
• key_data: local key custody material and rotation state.
• config_data: policy config, allowlists, and system manifests.

Network and boundary requirements:

• Only gateway-api is exposed to the host network by default.
• egress-proxy has outbound network access; all other services run with outbound disabled at the network policy level in the reference distribution.
• All metadata sync requests must traverse egress-proxy and pass allowlisted schema validation; failures are fail-closed and produce EGRESS_BLOCKED events.
• Dashboard ingestion is treated as metadata sync and must traverse egress-proxy. The dashboard endpoint and schema are allowlisted; all other destinations and fields are denied by default.

Container security baseline (required for official images):

• Run as non-root with no privilege escalation.
• Read-only root filesystem where possible; all writes go to mounted volumes.
• Drop all Linux capabilities unless explicitly required; deny SYS_ADMIN.
• Health checks for every service; deterministic readiness for CI gating.
• Release artifacts include SBOM and cryptographic signatures; clients verify signatures before use in regulated pipelines.

5. Feature Specifications¶

5.1 Evidence Vault¶

• Append-only event ledger using Merkle-linked records.
• Content-addressable immutable evidence objects.
• Signed human actions (approval, override, incident closure).
• Offline verifier support for third-party audits.

5.2 Risk Engine¶

• Deterministic Annex III mapping.
• Profiling trigger forces high-risk classification.
• Substantial-modification trap freezes deployment.
• Versioned risk score across model/data/purpose changes.

5.3 Ground Truth Verification Graph¶

• Each claim is resolved as exactly one outcome: Verified or Alerted.
• External-source checks generate request/response hashes.
• Mismatch propagation updates risk and opens remediation workflow.

5.4 HITL Orchestrator¶

• Hard stop on trap detection.
• Mandatory rationale for high-stakes override.
• Dual approval for biometric confirmation paths.

5.5 Documentation Generator¶

• Generates Annex IV dossier from current evidence + risk state.
• Emits signed checksum for dossier integrity.
• OSS default: produces a local bundle and checksum metadata; unsigned by default for quickstart; local signing is supported when keys are configured.
• Pro/Enterprise: dossier signing is mandatory for badge issuance and gated releases; Pro stores hosted dossier bundles and publishes cloud-signed checksums and auditor packages (metadata-only ingest; no raw evidence).
• Enterprise: supports customer-managed HSM/KMS-backed signing and regulated retention controls.

¶

6. Atomic Requirements (Testable)¶

¶

7. Data Models and Verification Logic¶

7.1 Core Entities¶

7.2 Verification Flow¶

• Receive AI output claim.
• Select source adapter and execute authenticated lookup.
• Hash request and response payloads.
• Emit VerificationProof on match or BiasAlert on mismatch.
• Append events to ledger and update risk if severity threshold crossed.

7.3 Data Integrity Invariants¶

• Every claim has one terminal outcome.
• Every risk decision links to an immutable event.
• Every override links to signer identity and rationale hash.

¶

8. Agent Workflows and HITL¶

8.1 Check -> Implement -> Monitor¶

8.2 State Machine¶

• RUNNING -> HALTED_PENDING_REVIEW on trap.
• HALTED_PENDING_REVIEW -> RUNNING only after signed approval token.
• RUNNING -> INCIDENT_MODE on critical incident.
• INCIDENT_MODE -> RUNNING only after remediation closure event.

8.3 UX Stress-Test Fix¶

Problem: prior flow forced legal/compliance interpretation at runtime by engineers.

Fix: system now emits deterministic failure reason codes and remediation playbook IDs so engineers get concrete next steps without legal guesswork.

¶

9. Security, Privacy, and Permissions¶

9.1 Security Controls¶

• Encryption at rest and in transit with strong default profiles.
• Local key custody with periodic rotation.
• Network segmentation and deny-by-default egress.
• Immutable audit logs for all privileged actions.

9.2 Role and Permission Matrix¶

¶

Tenant model (Pro/Enterprise)¶

Hierarchy: org_id -> project_id -> system_id¶

Authorization scopes: grant roles at org and project levels with inheritance; system-level access is derived from project membership¶

Break-glass: time-bound emergency elevation requires explicit justification, dual approval when configured, and a signed audit event¶

Spec owner: Security/Product. Due: 2026-05-??¶

¶

9.3 Privacy Rules¶

• Store only pseudonymized attributes for bias correction workflows.
• Prohibit persistence of special-category data beyond retention policy.
• Keep identity-bearing fields out of the metadata sync plane.

¶

10. Error Handling and Failure Recovery¶

10.1 Standard Error Envelope¶

{

"error_code": "VALIDATION_ERROR",

"message": "human_oversight.override_logic is required",

"category": "client|policy|system|dependency",

"retryable": false,

"correlation_id": "uuid",

"remediation_hint": "Set override_logic to Mandatory-Rationale-Logging"

}

10.2 Canonical Error Codes¶

10.3 Recovery Playbooks¶

• Integrity failure: lock affected partition, verify latest trusted root, replay forensic window.
• External source outage: queue verification tasks, degrade to pending state, escalate at SLA breach.
• Egress policy mismatch: fail closed, require hash revalidation + security approval.

¶

11. Analytics, Telemetry, and Audit Events¶

11.1 Product and Control Events¶

11.2 Metrics¶

• Control pass rate per release stream.
• Mean time to remediation by control type.
• Trap detection frequency by cause.
• Override rate and rationale completeness.
• Verification mismatch rate by source adapter.
• Time-to-first-scan (P50/P95) from fresh install.
• Activation rate: installs that reach first_scan_completed / installs.
• Design partner count and weekly active design partners.
• Activated design partners (pilot): partners meeting the activated-partner formula defined in the Design Partner Program.

11.3 Observability Requirements¶

• Structured logs with correlation IDs.
• Metrics per component and per tenant/project boundary.
• Trace propagation across check/verify/document workflows.

¶

12. API and CLI Contract Sketches¶

12.1 CLI¶

• compliance init
• compliance validate-manifest
• compliance check
• compliance risk classify
• compliance verify-output
• compliance docs generate
• compliance sync metadata

Python SDK:

- `opencomplai` Python SDK v0.1 provides parity with CLI for `init`, manifest validation, check/run, and artifact verification.

- Owner: DevRel. Ship candidate: 2026-05-??.

Exit codes:

• 0 pass
• 1 control fail
• 2 validation fail
• 3 policy/security block
• 4 trap detected

12.2 REST Endpoints¶

Pro API surface (minimum, metadata-only):¶

POST /v1/pro/ingest/status-artifact: accept signed first_scan_status artifacts after signature verification and ledger event_id reference checks¶

POST /v1/pro/ingest/dossier-metadata: accept dossier checksums and metadata; never accept bundle contents as raw evidence¶

POST /v1/pro/ingest/metrics: accept aggregated counts and rates under the allowlisted schema¶

POST /v1/pro/badges/issue: issue hosted badge only after verification; idempotent by system_id + bundle_checksum¶

GET /v1/pro/badges/verify/{badge_id}: public verification endpoint returning only metadata and verification result¶

POST /v1/pro/reconcile/run: trigger background reconciliation for pending verifications; internal-only¶

Contract owner: API Lead. Due: 2026-05-??¶

¶

12.3 Contract Sketch: POST /v1/risk/classify¶

Request:

{

"system_id": "HR-Screening-v2",

"intended_purpose": "Annex-III-4b",

"features": ["candidate_scoring", "profiling"],

"change_context": "model_retrain"

}

Response:

{

"risk_class": "high_risk",

"profiling_detected": true,

"trap_detected": false,

"score": 0.86,

"rationale_hash": "sha256:...",

"evidenceevent_id": "evt..."

}

12.4 Workflow Contract: First Scan (Deterministic Orchestration)¶

Purpose: define the exact activation and CI workflow for compliance check so that time-to-first-scan is measurable, repeatable, and auditable.

Assumptions (explicit):

• The provider runs the Docker Compose reference distribution or an equivalent CI runner (network available by default; air-gap supported).
• Policy bundle and deterministic rule engine are available locally or via allowlisted egress.
• Local signing keys exist for status artifacts and dossier checksums.

Inputs (required):

• SystemManifest (file or POST /v1/manifests/validate): system_id, intended_purpose, compliance_target, high_risk_presumption, commit_ref
• artifact_ref: image tag, model artifact, or commit hash
• trigger: install or ci_commit or manual_check
• scan_mode: ci or local or airgap
• policy_bundle_version (optional): default is pinned version when omitted
• Adapter credentials/config (optional): stored and used locally only

Primary outputs:

• Evidence ledger entries (append-only) with event_id and payload_hash
• Evidence objects (CAS): logs, adapter request/response hashes, sample input metadata
• RiskAssessment: assessment_id, system_id, risk_class, score, rationale_hash
• VerificationTask outcomes (proofs or alerts)
• Signed first_scan_status artifact (machine-readable JSON) persisted to the ledger
• Optional signed Annex IV dossier bundle (policy controlled)
• Telemetry events: compliance_check_started, compliance_check_completed, first_scan_completed, trap_detected

Signed status artifact schema:

{

"install_id": "uuid",

"system_id": "string",

"commit_ref": "string",

"result": "pass|control_fail|validation_fail|policy_block|trap_detected|degraded_complete",

"failed_controls": ["string"],

"evidence_hashes": ["sha256:..."],

"rationale_hash": "sha256:...",

"duration_ms": 12345,

"pending_verifications_count": 0,

"signature": "base64..."

}

Deterministic step-by-step (idempotent where applicable):

• Start: create install_id; emit compliance_check_started.
• Pre-validate environment: validate manifest schema, signing keys, storage volumes, and egress policy.
• Discovery & inventory: normalize manifest; persist canonical manifest; emit system_inventory evidence.
• Deterministic risk classification: call risk engine; persist RiskAssessment; emit risk_classified.
• Controls evaluation: run rule set deterministically; collect failed_controls[] and remediation playbook IDs; emit controls_evaluated.
• Verification: execute adapters via egress proxy (or offline stubs in airgap); persist VerificationTask request/response hashes.
• Trap/HITL gate: if trap_detected, emit trap_detected, transition to HALTED_PENDING_REVIEW, and finalize as a terminal state for automated flow.
• Dossier generation (policy-controlled): generate signed Annex IV bundle with target P95 <= 120s; on failure, mark degraded and proceed per policy.
• Finalize: build deterministic status artifact and sign it; persist to CAS and append to evidence ledger; emit compliance_check_completed and first_scan_completed.

Exact definition: "scan complete"

• A scan is complete only when a terminal state is reached and a signed status artifact is appended to the ledger.
• Terminal states:
• PASS: all critical controls passed; pending_verifications_count == 0; signed artifact appended.
• CONTROL_FAIL: critical non-trap controls failed; signed artifact appended.
• VALIDATION_FAIL / POLICY_BLOCK: pre-check failure or egress/policy block; signed artifact appended.
• TRAP_DETECTED: HITL required; trap event persisted; CI blocked until signed override.
• DEGRADED_COMPLETE: deterministic checks ran; external verifications pending/unavailable; signed artifact indicates pending_verifications_count > 0.

Exit code mapping (CLI):

• PASS: 0
• CONTROL_FAIL: 1
• VALIDATION_FAIL: 2
• POLICY_BLOCK: 3
• TRAP_DETECTED: 4
• DEGRADED_COMPLETE: 1 in ci mode; 0 in local mode when policy explicitly allows degraded completion

Idempotency and determinism:

• Same (commit_ref, policy_bundle_version) yields identical risk_class and rationale_hash.
• Status artifact is content-addressed and deterministic; rerun yields the same signed artifact when inputs are unchanged.
• Verification adapters use request_hash for idempotency to avoid duplicate external calls.

Retry/queue semantics:

• External adapter failures yield DEPENDENCY_UNAVAILABLE; retry with exponential backoff; dead-letter persists pending_verifications_count for the scan.
• Background reconciliation may update scan status when verifications complete within a configured window; badge issuance remains prohibited until pending_verifications_count == 0.

Badge issuance (distribution hook):

• Issue badge only when result == pass and pending_verifications_count == 0 and a signed status artifact exists in the ledger.
• Badge is idempotent per system_id + bundle_hash.

QA checklist (repeatability):

• Fresh environment: compliance init then compliance check on sample system; expect time-to-first-scan P95 <= 15 minutes.
• Adapter outage: expect degraded_complete and queued tasks with DEPENDENCY_UNAVAILABLE.
• Trap simulation: expect trap_detected, exit code 4, signed trap evidence.
• Offline verifier reproduces Merkle roots for the ledger.

¶

13. Scalability, Reliability, and SLOs¶

13.1 SLO Targets (MVP)¶

• API availability: 99.9% monthly.
• P95 /v1/risk/classify: <= 300 ms (excluding external verification calls).
• P95 /v1/verify/claims: <= 2000 ms with healthy dependency.
• Event write durability: 0 data loss for acknowledged writes.
• Dossier generation P95: <= 120 seconds.

13.2 Capacity Planning Constraints¶

• Support at least 100 concurrent compliance checks per workspace.
• Support sustained evidence ingest of at least 500 events/second per deployment.
• Support evidence retention windows >= 7 years by policy configuration (local evidence default: 7 years).
• Pro hosted metadata storage uses short TTL by default (default: 90 days; configurable up to 2 years).
• Enterprise retention is configurable by policy and deployment requirements.

13.3 Reliability Patterns¶

• Queue-based buffering for external verification dependencies.
• Retries with exponential backoff and jitter for dependency failures.
• Bulkhead isolation between verification, documentation, and sync services.
• Circuit breaker on failing external adapters.

¶

14. Compliance Mapping Summary¶

¶

15. Delivery Plan and Release Gates¶

Provider-first start: delivery sequencing prioritizes provider CI/CD integration, deterministic gates, and Annex IV dossier generation per release candidate. Deployer/operator runtime workflows are deferred until provider pipeline requirements are stable¶

Execution Framework Alignment¶

Operating model: open-source wedge to drive developer adoption, then monetize with a premium dashboard and enterprise distribution. The core gating metric is time-to-first-scan and continuous CI adoption¶

Phase mapping:¶

¶

Milestones (Provider-First)¶

Mandatory Release Gates (Provider-First)¶

• No open critical compliance control failures for the release candidate.
• No unresolved TRAP_DETECTED events for the system being released.
• Dossier generation success for the release candidate with checksum metadata; Pro/Enterprise require a signed dossier for badge issuance and gated releases.
• Egress leak suite passes with 0 forbidden fields.
• Time-to-first-scan P95 <= 15 minutes on the reference distribution for the supported platform set.

Design Partner Program¶

Definition: 10-15 early-adopter provider teams (Seed to Series C) who actively run the open-source core in CI and provide structured product feedback during a time-boxed pilot.

Commitments:

• Install the reference distribution (Docker Compose) in a CI runner or staging environment within 2 weeks.
• Run at least one full CI release candidate through the compliance gate weekly.
• Provide anonymized metadata feeds only (signed status artifacts, dossier checksums, aggregated counts) using the agreed schema; never provide raw evidence.
• Join a 60-minute weekly feedback call (or a 30-minute office-hours session) for 8-12 weeks.
• Complete a short structured feedback form after each pilot sprint and provide one end-of-pilot testimonial or case note (opt-in).
• Triage and reproduce 1-3 integration issues with DevRel support; accept up to one founder-led troubleshooting session if required.

Required deliverables (measurable):

• Evidence of CI runs: at least 4 weekly signed first_scan_status artifacts.
• Activated partner formula: first_scan_completed within 15 minutes P95 on the reference distribution and >= 1 signed status artifact per week for 4 consecutive weeks within the 8-week pilot (target >= 80% of partners).
• Completed weekly feedback forms and one final testimonial or case note.

Partner benefits:

• 3 months free Pro (metadata dashboard).
• Priority onboarding and direct product influence.
• Optional co-marketing credit.

Distribution Plan (Provider-First)¶

Distribution is a product requirement because the open-source wedge depends on self-serve activation.

Required distribution hooks:

• Embeddable "EU AI Act Ready" badge issued only after a passing scan and signed status artifact.
• Reproducible quickstart: Docker Compose install path with deterministic sample system and one-command scan.
• Integration targets for early credibility: CI (GitHub Actions), and at least one MLOps workflow integration in the premium roadmap.

Commercialization and Tier Boundaries¶

Monetization strategy: open-source core + paid Pro SaaS add-ons + paid enterprise distribution. Paid offerings never ingest raw evidence; they monetize automation, reporting, integrations, and regulated-environment requirements.

OSS (Community, free, local-first):

• Reference Docker Compose + CLI (init, validate-manifest, check, risk classify, verify-output, docs generate).
• Evidence Vault (local, append-only) and deterministic Risk Engine.
• Ground-truth adapters in local/offline mode and deterministic controls.
• Minimal Annex IV bundle generation (local bundle and checksum metadata; unsigned by default).
• Signed status artifact generation (local signing) and CLI exit codes.
• Developer DX: examples, templates, policy bundles, and how-to guides.

Pro (paid SaaS add-ons: team productivity and automation):

• Hosted metadata dashboard (metadata-only ingest) with automated reporting, historical trends, aggregated metrics, and team-level alerting.
• Hosted badge issuance and public verification (verifies signatures and requires pending_verifications_count == 0).
• Automated background reconciliation of queued verifications, scheduled scans, multi-repo monitoring, and CI integrations (3 connectors).
• Hosted dossier storage and cloud-signed checksums for audit-ready hosted bundles.
• Priority email support, onboarding, and exportable auditor packages.

Enterprise (paid, high-assurance):

• On-prem enterprise distribution with HSM/KMS integrations, advanced RBAC, SSO/SCIM, central signed policy distribution, versioned policy pinning, and drift detection.
• SBOM + signed image publishing, SLAs, dedicated onboarding, and optional compliance consulting.
• High-volume telemetry, multi-system portfolio telemetry, and regulatory feature packs.

Pricing tiers:

Enterprise features (paid) and the user problem they solve:

• SSO and identity lifecycle: OIDC/SAML SSO and SCIM provisioning so provider orgs can enforce access governance.
• Advanced RBAC and audit controls: fine-grained authorization scopes, break-glass workflows, and signed administrative actions for regulated change control.
• Central policy distribution: signed policy bundles distributed to multiple provider projects with version pinning and drift detection.
• Supply-chain controls: signed images, SBOM, provenance, and vulnerability response SLAs aligned to provider procurement.
• Enterprise key management: integration with customer-managed HSM/KMS and optional FIPS-validated crypto builds when required.

Gating and Enforcement Rules¶

• OSS is strictly local-first by default (no outbound metadata). Any SaaS ingestion requires explicit opt-in and an egress-proxy allowlist entry.
• Dashboard ingestion must use the allowlisted schema and fail closed on any schema violation or disallowed destination.
• Pro verifies signatures and ledger event_id references before accepting any status artifact, dossier metadata, or aggregated metrics.
• Pro persists only hashes/checksums and aggregated metrics; it applies strict RBAC and configurable short TTLs for stored metadata.
• Badge issuance is prohibited unless signature verification succeeds and pending_verifications_count == 0.
• OSS includes CI examples; production-grade connectors (scheduled scans, repo fleet monitoring, background reconciliation) are Pro features.
• Pro trials for design partners run for 14 days and require explicit consent with an audit log of metadata egress enablement.

Migration Hooks (Smooth Upgrade Path)¶

• Signed status artifacts and dossier checksums are canonical migration artifacts; Pro ingests only hashes/metadata and validates signatures.
• Provide a one-command opt-in flow that routes metadata via egress-proxy to SaaS with explicit confirmation and an immutable audit event.
• Hosted ingestion accepts only aggregated counts/hashes; raw evidence is never accepted.

Seed Readiness Workstream (Non-Functional Requirement for Execution)¶

Provider-first product execution is constrained by part-time founder capacity; seed readiness is treated as a parallel workstream with explicit artifacts.

Required artifacts:

• Investor CRM with 50+ qualified seed funds focused on AI, dev-tools, and regulatory tech.
• Data room readiness checklist and demo assets showing first scan, CI gating, and dossier generation.
• Design partner pipeline status and activation metrics available weekly.

Acceptance criteria:

• CRM: 50 qualified funds with contact details and a documented outreach plan.
• Data room: all required items are present and access-tested.
• Legal: incorporation and IP assignments are fully executed.
• Funding: >= 3 signed LOIs or 1 soft term-sheet.
• Demo: reproducible 15-minute demo and 10 design partners with signed commitments.
• Metrics: time-to-first-scan P95 <= 15 minutes and >= 10 active design partners (as defined in the Design Partner Program).

Commercial delivery phases:

Impact on what we are building:

• The product becomes a "compliance control-plane you can run": a deterministic release gate plus an evidence system-of-record that providers can install consistently across environments.
• Engineering scope expands to include release engineering (image signing, SBOM, upgrade/migration plan) and enterprise-grade configuration/secret handling.
• Architecture enforces the local-first boundary at the deployment layer (network defaults, egress proxy controls), not only in application logic.

¶

16. Open Decisions and Stack Recommendations¶

Stack selections (locked for MVP unless an ADR replaces them):

Cross-cutting decision locks:

• Ingestion schema canonical field: pending_verifications_count. Change locked: 2026-04-20.
• Dossier signing: OSS unsigned by default with optional local signing; Pro/Enterprise signing mandatory for badge issuance and gated releases. Owner: CTO.

¶

17. Reviewer's Log¶

Critical Gaps Filled¶

• Missing error contract and recovery model

• Added standard error envelope, canonical error codes, retryability semantics, and recovery playbooks.

• Why necessary: without this, integration behavior is inconsistent and incident response is ad hoc.

• Missing telemetry and event taxonomy

• Added explicit analytics/audit events with required fields and measurable control metrics.

• Why necessary: production compliance requires measurable control health, not just static requirements.

• Missing permissions and authorization boundaries

• Added role-permission matrix and scoped responsibilities for override, release resume, and policy management.

• Why necessary: human oversight is unenforceable without an explicit authorization model.

• Ambiguous API behavior and idempotency

• Added endpoint contract sketches, idempotency expectations, and request/response examples.

• Why necessary: developers need deterministic integration contracts to build clients and tests.

• Scalability and reliability constraints were undefined

• Added SLOs, throughput targets, and resilience patterns (circuit breaker, backoff, bulkheads).

• Why necessary: compliance systems become bottlenecks if non-functional limits are not designed upfront.

¶

18. Definition of Done¶

• All REQ-* controls implemented with automated tests and passing results.
• Compliance mapping table fully traceable to artifacts and APIs.
• CI release gates enforce policy and block non-compliant builds.
• Independent verifier reproduces Merkle roots and inclusion proofs.
• Security and egress leak tests pass with zero critical findings.
• Operational telemetry dashboard shows control health, incidents, and remediation latency.