Goals and non-goals

A clear statement of scope is the most useful thing this documentation can give you. Read this page before arguing about a feature.

What v2 is

The first coherent version of Unphish as a platform. A clear separation between the operator console (Hub), the operator app (Staging / Production), the customer-facing demo (Demo), and the development sandbox (Workbench).
A pre-production testbed. Staging mirrors production routes and contracts but uses staging-safe external effects: Postmark email bins, sandbox provider modes, no-op enforcement adapters.
A polished demo theatre. Demo runs on its own host (unphish-demo.engram.org) with curated fixtures and scenes designed for sales conversations.
A developer sandbox. Workbench has the same data contracts as production but switches the provider transport to fixture or sandbox mode. Running a model evaluation in workbench is a faithful reproduction of how it would behave in production.
A migration bridge from v1. v1 has 35,375 cases, 73,392 notes, 109 brands, 564 scan queries, 12,074 whitelist entries, and 1.45M WhoisFreaks NRD rows. All of this comes across — phased, validated, and labelled imported.
A single-auth platform. Authentik is the identity provider in every environment. The application stores no passwords.
An honest product. Every production-facing surface labels its data source. Demo data shows up as demo. Imported data shows up as imported. Unavailable means unavailable. We do not pretend a fixture is a live takedown.
AI-native. The data model treats classification, evidence synthesis, and the feedback loop as first-class. Confidence, sub-scores, and routing decisions are typed fields, not free-form prose.

What v2 is not

A 1:1 visual clone of v1. UX consolidation is intentional. "Threat Feed", "Cases", "Approvals", and "Verification" become filtered views of one case lifecycle.
Seven separate apps. Hub, Admin, Analyst, Partner, Client, Workbench, and Demo are surfaces inside a shared route tree, gated by host, role, and tenant scope.
A role-switching simulator. v1 had a fake role slider on Hub. v2 replaces that with explicit support preview (impersonation) — capability-gated, banner-visible, time-bounded, and audited.
A production app yet. Staging is pre-production. Production routes are locked behind readiness until cutover approval. Live enforcement requires both the cutover and explicit enforcement.submit_live capability.
A replacement for v1's historical audit trail. v1 audit stays in v1 archive. v2 owns its own audit going forward.
An externally managed status page. First-pass status is first-party and curated. Live API health checks come later.

The first delivery milestone (pilot)

The pilot bar is intentionally tight: a customer can be onboarded, threats can move end-to-end, and the operator can prove every action is audited.

Pilot epic	Acceptance
Hub Team	Invitation create / resend / revoke / accept against canonical tables; no local password rows; Authentik OIDC session path; role normalization; capability gates.
Real Data Foundation	Production tenants load live dashboard, stats, cases, intelligence, and enforcement data with explicit source metadata; no silent demo fallback.
Pilot Workflow	Threat submitted → case enriched → classified → routed by policy → auto-enforced or paused for review; client approval pause/resume; provider submission and verification visible end-to-end.
Legacy Parity	Each legacy capability mapped to retained / replaced / merged / retired; migration fixtures for clients, brands, cases, watchlists, whitelists, scans, enforcement records, API apps, SSO domains, quotas, and reports.
Workbench ↔ Production	Workbench pipelines use the same contracts as production. Replays for happy path, ambiguous, provider rejection, resurrection, and false-positive scenarios. Backtests compare model output against expected decisions.

Non-goals for the pilot

These are explicitly out of scope for the first cutover:

Production Workbench. Replaying real customer cases through workbench provider adapters is deferred. Staging-only for now.
Live external status page. First-party status only.
Internal-only role auto-promotion beyond Engram domains. Partner and client admins do not get system_role admin automatically.
Per-partner isolated deployments. All partners share multi-tenant hosting with branded domains. Isolated deployments may come later for specific contractual needs.
Migrating v1 password hashes. Users re-enroll through Authentik.
Migrating v1 TOTP secrets. Users re-enroll MFA in Authentik.
Replacing v1 audit history in place. v1 audit archived; v2 audit is forward-looking.

Open product decisions

These are not pilot blockers but must be resolved before full rollout:

Whether senior_analyst becomes a distinct role or stays a display label.
Which enforcement channels are required for the first customer pilot beyond XARF, CleanDNS, registrar/host, Meta, X, Cloudflare, and Google Safe Browsing.
Which reports are contractual for pilot clients vs. internal operational reports.
Whether partners ever require isolated deployments (multi-tenant with branded domains is the default).

The honesty principle

If you take one thing from this page, take this: a v2 surface that displays demo data without saying so is broken. Source labelling is not cosmetic. It is how customers, staff, and auditors trust what they are seeing.

If you cannot fetch live data, show an unavailable state. If you are showing imported data, label it. If you are in demo, show the demo banner. There is no acceptable circumstance in which a production customer sees fixture data without a label.