Skip to content
opencomplai.com Get Started

SaaS Premium Dashboard — Commercial Phase Plan (C0–C1)

Status: Deferred from v0.1. Planned for commercial phases C0–C1, post-seed. Scope owner: Commercial + Platform. Source of truth: see PRD §4.2 dashboard ingest data classes, PRD §commercialization & tier boundaries, 90-day scope.

This document captures what the SaaS premium dashboard is, why it is deferred until after the seed milestone, the dependencies the v0.1 codebase must preserve so the dashboard can be built without rework, and the C0–C1 milestone shape.

Why it is deferred from v0.1

The 90-day v0.1 scope is provider-first and local-first. The dashboard is a hosted Pro-tier surface that exists to monetize the open-source wedge once design-partner activation is proven. Building it before:

  • the deterministic Risk Engine ships (Phase 10),
  • signed status artifacts are emitted from CI (Phase 9–10),
  • the Annex IV dossier generator produces canonical bundles (Phase 12), and
  • the egress-proxy enforces the allowlisted metadata schema fail-closed (Phase 13)

would mean shipping a dashboard with nothing trustworthy to ingest. C0–C1 follow seed close, by which point those artifacts exist and design partners are emitting them weekly.

Product surface (C0–C1)

The dashboard is metadata-only. It never ingests raw evidence. It consumes signed artifacts produced locally by the OSS core and renders them for provider teams.

In scope for C0–C1:

  • Hosted metadata ingestion endpoint behind the egress-proxy allowlist.
  • Signature verification of every incoming first_scan_status artifact and dossier checksum; reject on verification failure.
  • Tenant-scoped views over: system_id, commit_ref, policy_bundle_version, risk_class, control pass/fail rates, pending_verifications_count, dossier bundle metadata, aggregated event counts.
  • Historical trend views and per-system release timeline.
  • Team-level alerting on trap detection, control regression, and dossier-generation failures (alert on metadata events only).
  • Hosted badge issuance: badge is issued only when signature verification succeeds and pending_verifications_count == 0.
  • Hosted dossier storage with cloud-signed checksums and exportable auditor packages.
  • One-command opt-in flow from the CLI that routes metadata via egress-proxy to the dashboard with explicit user confirmation and an immutable local audit event.
  • 3 CI connectors at GA (GitHub Actions first; remainder TBD by design-partner pull).
  • Pro RBAC: org, team, project scopes. Short configurable TTLs for stored metadata. Audit log of admin actions.

Explicitly out of scope for C0–C1 (do not build):

  • Raw evidence ingestion of any kind. The dashboard never sees evidence payloads, model artifacts, datasets, or PII. This is a permanent product boundary, not a deferral.
  • Deployer/operator runtime decision verification.
  • SSO/SCIM, central policy distribution, HSM/KMS-backed signing — these are Enterprise (C1+), tracked separately.
  • Multi-tenant hosting of sensitive workloads.

Architectural preconditions v0.1 must preserve

These are the non-negotiable invariants the v0.1 build must hold so the dashboard can be added without redesign. Each maps to an existing Phase deliverable.

Precondition Owner phase Why it matters for the dashboard
egress-proxy is the only component permitted to call external endpoints; allowlist is the only way out Phase 13 The dashboard endpoint is added as one allowlist entry; no other code path can leak to it
Dashboard ingest schema is canonical and versioned (see PRD §4.2) Phase 9–10 Schema-driven ingestion validates without server-side trust in clients
Signed status artifacts emitted by the CLI carry signer identity, payload hash, and signature Phase 9–10 Dashboard verifies before persisting; no signature, no row
Annex IV dossier bundles emit a bundle_checksum and metadata envelope distinct from the bundle itself Phase 12 Dashboard ingests the envelope only; the bundle stays local unless the customer opts into hosted storage
Ledger event IDs are stable references that can travel in metadata payloads Phase 7–8 Dashboard correlates aggregated metrics back to canonical local events without duplicating evidence
OpenTelemetry instrumentation in services exports counters/histograms only — no payload sampling Phase 15 Aggregated metrics path is reusable for the hosted dashboard without an evidence-leak risk
Opt-in metadata egress is gated by a one-command flow that writes an immutable audit event locally Phase 13 The hosted product never receives data the user did not explicitly enable

If any v0.1 change weakens one of these, raise a change-request per scope-90-day §change-control.

C0 → C1 milestones

C0 — Activation foundation (post-seed close)

Goal: convert >= 1 design partner into a paying Pro customer on the hosted dashboard.

Exit criteria:

  • Ingestion endpoint live behind egress-proxy allowlist; rejects unsigned, schema-invalid, or off-allowlist payloads with EGRESS_BLOCKED semantics.
  • Signature verification covers 100% of first_scan_status and dossier checksum payloads.
  • Pro tenant onboarding flow (signup, org create, opt-in CLI command, first artifact rendered) completes in < 15 minutes for a partner with v0.1 already installed.
  • Per-system release timeline view, control pass/fail rates, trap-frequency aggregate.
  • Email alerting on TRAP_DETECTED and dossier-failure metadata events.
  • Audit log of admin actions and metadata-egress consent events.
  • Pricing: Pro at the rate fixed in the PRD pricing table.
  • Acceptance: >= 1 paid Pro subscription from a converted design partner.

C1 — Stable contracts + enterprise wedge

Goal: secure first annual enterprise subscription; stabilize Pro contracts for portfolio scale.

Exit criteria:

  • API/CLI contracts for metadata ingest are versioned; breaking changes follow deprecation policy.
  • Versioned policy bundles flow through the dashboard's policy-version field; mismatches surface as alerts.
  • Hosted dossier storage with cloud-signed checksums; exportable auditor package generated on demand.
  • Multi-repo / multi-system portfolio view per tenant.
  • 3 CI connectors at GA.
  • Enterprise distribution v1 (SSO + RBAC + central policy distribution) ships as a sibling track — explicitly not part of the SaaS dashboard scope, but RBAC primitives in the dashboard align with the enterprise model.
  • Acceptance: first annual enterprise subscription signed with defined scope.

Non-functional requirements (Pro tier)

  • Metadata-only: any field outside the allowlisted schema is rejected. There is no escape hatch for "just this one payload."
  • Tenant isolation: per-tenant encryption keys for at-rest metadata; no cross-tenant query paths.
  • Retention: configurable per tenant with a short default; the dashboard is not the system of record — the OSS Evidence Vault is.
  • Availability: target 99.5% for ingestion and read; degraded read is acceptable if signature verification is unavailable (fail-closed on write, fail-open on read of already-verified data).
  • Audit: every administrative action and every metadata-egress consent event produces an immutable record on both the OSS side and the SaaS side.

Dependencies on still-deferred OSS work

These OSS items are not in v0.1 but are required before the dashboard ships. Tracking them here so the C0 plan does not assume more than v0.1 delivers.

  • TypeScript/JavaScript SDK (post-seed): the dashboard's web verifier benefits from a published JS SDK for signature verification in-browser, but is not strictly blocking — server-side verification is sufficient at C0.
  • Egress leak suite (Phase 13): must pass with 0 forbidden fields before any tenant is onboarded.
  • SBOM + signed image publishing (Phase 14): required for procurement at C1.

Open questions to resolve before C0 build starts

  • Hosting region(s) and data-residency commitments for EU providers.
  • Whether the dashboard issues its own signing keys for cloud-signed dossier checksums, or delegates to a managed KMS from day one.
  • Connector priority order after GitHub Actions (GitLab CI, CircleCI, Jenkins, Buildkite).
  • Whether the badge service lives inside the dashboard surface or as a separate public verifier service.

Carry these into the C0 kickoff doc; do not resolve them in v0.1.