Assurance Packs Shell

Status: Implemented Owner: UI Guild Source: src/Web/StellaOps.Web/src/app/features/compliance/assurance-frameworks/

Purpose

The Console Assurance shell is the operator-facing discovery page for optional Assurance packs. It must not frame NIS2, DORA, or CRA as the product category. The page lists enabled and available packs, then links into pack-specific surfaces such as the NIS2 Evidence Pack control register, incident timelines, effectiveness dashboard, and DORA operator-support handoff artifacts when the pack descriptor is available.

Canonical routes:

• /assurance
• /assurance/nis2/control-register
• /assurance/nis2/incidents
• /assurance/nis2/effectiveness

Compatibility routes remain valid:

• /compliance
• /compliance/nis2/control-register
• /compliance/nis2/incidents
• /compliance/nis2/effectiveness

Navigation (Console IA)

As of the Proof-foundation redesign (SPRINT_20260709_001, EF-3), Assurance is the “Account” tier of the Proof pillar — the regulator-facing destination alongside Chain (custody) and Estate. It is a cockpit-parent nav item:

• The Account parent’s own route is /compliance (the readiness cockpit; c10 R1 made /compliance canonical and /assurance/* a redirect-only alias), so selecting it always lands on the cockpit — never a dead node.
• The framework lenses — Overview (/compliance), NIS2 (/compliance/nis2), DORA (/compliance/dora), CRA (/compliance/cra) — are children that the sidebar auto-expands whenever a /compliance route is active. The Transparency ledger (/setup/trust-signing/transparency, ui.admin-gated) is also cross-listed here (c10 R2, owner remark) alongside the Trust Center door.

Compliance is grouped as one episodic tier (CISO/DPO/auditor cadence) so it does not scatter the daily Chain/Estate surfaces. It is not a separate top-level pillar and is not under Operate (the former assurance-packs Operate item was retired when compliance moved into Proof). See src/app/core/navigation/navigation.config.ts (group proof, item account).

Readiness reads are independently fail-visible and bounded to 12 seconds. If one Authority, ExportCenter, or reporting source hangs, that capability settles to an explicit unavailable state while completed framework results remain visible; the cockpit does not remain globally busy forever.

Data Sources

EF-3 (compliance-as-query): the NIS2 control register additionally resolves each control’s stella-native evidence pointer live against the real gateway reads (deployed estate GET /estate/digest/{digest}, attestor transparency) with the caller’s token — showing a per-pointer resolution state (resolved with a real bundle-ref/hash · honest pending · unobservable for operator-supplied). The framework projection also surfaces the real published SoA-snapshot bundle-ref/hash. A ref/hash is populated only from a confirmed real source — never fabricated.

The shell reads live readiness where APIs exist and shows explicit unavailable states where they do not:

Unavailable API responses are not treated as success. Cards must show Export readiness unavailable, Reporting readiness unavailable, or Enablement unavailable when the corresponding live boundary cannot be read.

Operator Compliance Settings

The Assurance shell also includes a compact operator settings surface backed by Authority Console admin endpoints. It displays the effective tenant-operator-compliance-settings.v1 state for:

• active approver count;
• enabled handoff channel count;
• enabled operator-owned Assurance pack count;
• sanitized operator config hash and load status;
• effective retention policy years for dora-roi, dora-incident-report, tlpt-pack, and standards-mapping-evidence.

The surface is intentionally narrow. It may edit only the DORA RoI retention policy through PUT /console/admin/tenants/{tenantId}/operator-compliance. DORA RoI defaults to 7 years when absent from tenant settings. Operator edits must keep years between 5 and 10; non-default values require a reason and an approvedBy value. Shortening the current effective period also requires a shorteningApprovedBy value because Authority enforces the retention contract.

Legal and ownership boundary:

• The settings are customer/operator-owned workflow choices, not sealed runtime posture.
• The UI must not expose or persist signing keys, private key material, trust roots, public endpoint posture, SMTP/provider secrets, storage roots, schema asset roots, or network-egress policy.
• EvidenceLocker remains the durable retention ledger owner after regulatory artifacts are generated or exported; Authority provides the normalized operator policy and local config hash.
• The page must describe Assurance packs as evidence support and handoff workflows, not as legal compliance certification.

Setup Wizard Handoff

The setup wizard includes an optional Assurance Packs step for preflight review. The step is read-only until Authority pack enablement and the owning readiness APIs expose a setup-save contract. It defaults to no pack enabled, does not persist browser-only settings, and links operators to this /assurance shell plus the owning Trust, Export, Notify, and Identity surfaces.

The step must distinguish NIS2 SoA live-export readiness, DORA major incident handoff readiness, DORA RoI local-contract export readiness, DORA Article 45 sharing readiness, DORA TLPT evidence preparation, and CRA public publication readiness. It must also state that Assurance packs configure evidence support and workflows, not legal compliance certification.

Pack Cards

Each pack card shows:

• enabled, disabled, or unavailable enablement state;
• claim boundary from assurance-pack-v1;
• evidence scope and primary software-estate coverage;
• operator-supplied gaps that Stella cannot infer from telemetry;
• operator or module owner role;
• last evidence snapshot if a live source exists, otherwise a snapshot unavailable label;
• signed export readiness;
• reporting handoff readiness;
• setup gaps from Authority, ExportCenter, and Notify reason codes.

Initial cards:

NIS2 and DORA cards must show operator-observed-estate as the primary scope and describe the software Stella monitors or deploys as the covered estate. They must also show operator-supplied gaps such as legal entity data, governance, contracts, physical controls, HR/training, tolerance decisions, and filing approvals. These gaps are not setup errors by themselves; they are ownership labels that keep Stella-native evidence separate from operator facts.

The DORA card is intentionally visible as an optional pack, but it must not be shown as configured until Authority pack enablement and owning readiness APIs report configured state. Missing DORA export or reporting profile endpoints must appear as Export readiness unavailable or Reporting readiness unavailable. Existing DORA RoI retention editing can remain visible as an operator compliance setting because Authority owns that tenant setting independently from pack-level readiness.

Copy Rules

Allowed:

• Assurance Packs
• NIS2 Evidence Pack
• CRA Product Security Pack
• CRA Technical Documentation Pack
• DORA Operational Resilience Pack
• operator-owned
• local-contract handoff
• signed export readiness
• publication preflight

Forbidden:

• European Compliance as a product category
• Stella is NIS2 compliant
• NIS2 compliance mode
• DORA compliant mode
• CRA compliant mode

Verification

Focused checks for this surface should include:

• route tests for /compliance and the /assurance/* → /compliance/* redirect alias;
• component tests for disabled, enabled, blocked, and unavailable pack states;
• copy tests that reject forbidden compliance claims;
• browser verification at desktop and mobile widths when the local app can run.