Skip to content
Unified platform · one shell · 7 GA suites Pro · 8,000 cr Trial · day 3 of 15
Stage 0 — Platform home

One shell. 7 GA suites. Configured, not coded.

Every suite runs the same journey you see in the left rail. What changes per suite is registry configuration: its archetype mix (which ingestion paths it uses), its agents, its terminology, its workflow modules, its score weights. Pick a suite to load its configuration into the shell.

A · ProbeB · Connector C · AttestationD · Stream mixes per Z5 §3.7 (canonical)

Why this matters

Adding a suite is a registry entry, not a new UI. The EU AI Act tile loads as a live preview of the same shell — same stages, different configuration. That is the platform contract: suite-specific code only where a workflow module genuinely requires it (declared in the registry, e.g. GDPR's DSAR/DPIA consoles).

Stage 1 — Onboarding

Sign in & configure the workspace

Identity is delegated to your IdP. Then the platform-level choices: plan, data residency, evidence-handling mode, notifications. These apply to every suite — none of this is re-asked when you add suite #2.

Secure sign-in

Bearer JWT + capability token. Roles map from your IdP groups (persona bundles per the admin config).

Not signed in

Plan

Pro — $499/mo8,000 credits

Suites unlimited · seats unlimited · Slack + Teams alerts at zero credit cost · 15-day standardized trial.

Data residency applies platform-wide

Locked at workspace creation. No replication outside the chosen region.

Evidence-handling mode

Notifications — zero credit cost

Slack connected

Statutory-clock escalations, gate escalations, and breach alarms dispatch here (webhooks).

Sign in to continue.
Stage 2 — Suite overview

on the platform spine

Program defensibility score

platform layer · suite-weighted

Two layers, never confused: this composite scores the program (coverage · sealed · replay · drift, weights per suite). Individual findings carry severity + confidence only — the suite classifier deliberately emits no composite 0–100 per finding.

Trust Column

platform primitives · identical for all suites
🔐 FIPS-validated, HSM-backed key management · automated rotation
🖋 Hybrid signing — Ed25519 + post-quantum signatures
📒 Determinism Ledger · pinned model versions · deterministic replay state
🗄 Evidence Locker · WORM/ObjectLock · 7-yr floor
⏱ RFC 3161 timestamps · Merkle anchoring
🧭 CMC framework projection · NIST 800-53 spine
⚖️ Bounded autonomy · multi-model consensus · confidence floor
🔁 5-year byte-identical replay (target) · offline verifier

Agent catalog

Stage 3 — Ingest & scan

Ingestion follows the archetype mix

Four front doors, one signed pipeline. The tabs are not designed per suite — they are rendered from the suite's archetype mix. Each path first picks an adapter (a storage provider, a parser, or a SIEM source), then connects, uploads or registers — and every path emits the same ASP-1.0 target. An Org Admin can enable a path the suite supports but hasn't activated; paths outside the mix don't exist for this suite.

Ready to scan

idle0%
Scan to unlock findings.
Stage 4 — Human-in-the-loop review

Findings & the six decision gates

The full six-state machine: confirm · correct · reject · accept-risk · suppress · escalate — each with its required justification, each verdict signed at write time with your identity. Findings below the platform confidence floor cannot be decided — bounded autonomy routes them to the officer.

0 findings 0 critical0 high0 medium Decided 0
Decisions feed remediation and the sealed manifest.
Stage 5 — Remediation

Recommend → approve → execute → re-scan verify

Confirmed findings become remediation items with an owner and a due date. Approval shows a dry-run diff first, and dual control requires a second approver — switch to Approver 2 to close a remediation when Approver 1 signed the finding. Verification is a re-scan, not a checkbox.

No items yet — confirm or correct findings in Stage 4.

Stage 6 — Suite workflow modules

Declared by the suite, run on platform primitives

The only suite-specific surfaces in the product — and even these are registry-declared modules on shared primitives: the case console + statutory clock.

Stage 7 — Commit & seal

One bundle, designed to be hybrid-signed

Decisions, remediation records and workflow outcomes are designed to be committed into a tamper-evident bundle: SHA-256 chain-of-custody, hybrid Ed25519 + post-quantum signatures, RFC 3161 timestamp, pinned model + prompt provenance, ~7-year retention.

🔏

Commit & seal (illustrative)

Any byte-level change after sealing invalidates both signatures.

Seal to unlock replay & the external view.
Stage 8 — Replay & continuous monitoring

Re-derive the verdict — by design.

Integrity says nobody tampered. Replay is designed so the verdict re-derives from sealed inputs under pinned models — without the original engineer or the original LLM in the loop. Then keep it true continuously: cadence, change-triggered re-scans, session diff.

Deterministic replay

5-year target
$ acipta-verify --verdict --bundle sealed.acpt · awaiting seal

Continuous monitoring

cadence —
Session diff vs last scan:
resolved · 1 remediated (re-scan verified)
resolved · 1 accepted-risk (rationale on file)
new · 1 consent banner changed 2 days ago — drift detected
drift freshness 94% · evidence ≤ 24h
Stage 9 — Regulator · assessor · auditor

External access is itself evidence

A grant requires two identities (Org Admin + Approver), auto-expires, and every event lands in the signed access log. The packet verifies offline with no acipta account — it survives vendor dissolution.

Create external grant

no active grant

Scope: this suite's sealed bundle · read-only · expires in 30 days.

Switch roles in the top bar to provide each signature — one person cannot do both.

Offline packet

no acipta dependency

Sealed bundle + chain-of-custody + embedded standalone verifier.

Signed access log

CG-4 chain · exportable as evidence
No external access events yet.

Illustrative product walkthrough

A ~2½-minute voiced preview of the acipta platform. Simulated data — the cryptographic seal, signatures and replay are dramatized, not live. Capabilities depicted are in development and not generally available before GA. To see it on your stack, request a live walkthrough.

Illustrative product preview — simulated data. The seal, signatures and replay shown here are dramatized, not live. Capabilities depicted are in development and not generally available before GA.