Stella Ops Triage UX Guide (Narrative-First + Proof-Linked)

Audience: Console product designers and engineers building the triage and evidence experience. For the underlying state-machine contract, see the Triage UI Reducer Spec.

0. Scope

This guide specifies the user experience for Stella Ops triage and evidence workflows:

• Narrative-first case view that answers the three operator questions quickly.
• Proof-linked evidence surfaces (SBOM/VEX/provenance/reachability/replay).
• Quiet-by-default noise controls with reversible, signed decisions.
• Smart-diff history that explains meaningful risk changes.

Architecture constraints:

• Lattice/risk evaluation executes in scanner.webservice.
• concelier and excititor preserve per-source provenance (every merged/pruned datum remains traceable to origin).

1. UX Contract

Every triage surface must answer, in order:

1. Can I ship this?
2. If not, what exactly blocks me?
3. What’s the minimum safe change to unblock?

Everything else is secondary and should be progressively disclosed.

2. Primary Objects in the UX

• Finding/Case: a specific vuln/rule tied to an asset (image/artifact/environment).
• Risk Result: deterministic lattice output (score/verdict/lane), computed by scanner.webservice.
• Evidence Artifact: signed, hash-addressed proof objects (SBOM slice, VEX doc, provenance, reachability slice, replay manifest).
• Decision: reversible user/system action that changes visibility/gating (mute/ack/exception) and is always signed/auditable.
• Snapshot: immutable record of inputs/outputs hashes enabling smart-diff.

3. Global UX Principles

3.1 Narrative-first, list-second

Default view is a case narrative header plus an evidence rail. Lists exist for scanning and sorting, but not as the primary cognitive surface.

3.2 Time-to-evidence target

From pipeline alert click -> human-readable verdict + first evidence link:

• p95 <= 30 seconds (including auth and initial fetch)
• evidence is always one click away (no deep tab chains)

3.3 Proof-linking is mandatory

Any chip/badge that asserts a fact must link to the exact evidence object(s) that justify it.

Examples:

• “Reachable: Yes” -> call-stack slice and/or runtime hit record
• “VEX: not_affected” -> effective VEX assertion plus signature details
• “Blocked by Policy Gate X” -> policy artifact plus lattice explanation

3.4 Quiet by default, never silent

Muted lanes are hidden by default but surfaced with counts and a toggle. Muting never deletes; it creates a signed decision with TTL/reason and is reversible.

3.5 Deterministic and replayable

Users must be able to export an evidence bundle containing:

• scan replay manifest (feeds/rules/policies/hashes)
• signed artifacts
• outputs (risk result, snapshots)

so auditors can replay identically.

4. Information Architecture

4.1 Screens

1. Findings table (global)

• purpose: scan, sort, filter, jump into cases
• default: muted lanes hidden
• banner: shows count of auto-muted by policy with a “Show” toggle

2. Case view (single-page narrative)

• purpose: decision making plus proof review
• above fold: verdict + chips + deterministic score
• right rail: evidence list
• tabs (max 3):
  • Evidence (default)
  • Reachability & Impact
  • History (smart-diff)

3. Export / verify bundle

• purpose: offline/audit verification
• async export job, then download DSSE-signed bundle when enabled
• verification UI: signature status, hash tree, issuer chain

4.2 Lanes (visibility buckets)

Lanes are a UX categorization derived from deterministic risk plus decisions:

• ACTIVE
• BLOCKED
• NEEDS_EXCEPTION
• MUTED_REACH (non-reachable)
• MUTED_VEX (effective VEX says not_affected)
• COMPENSATED (controls satisfy policy)

Default: show ACTIVE/BLOCKED/NEEDS_EXCEPTION. Muted lanes appear behind a toggle and via the banner counts.

5. Case View Layout (Required)

5.1 Top Bar

• Asset name / image tag / environment
• Last evaluated time
• Policy profile name (e.g., “Strict CI Gate”)

5.2 Verdict Banner (Above fold)

Large, unambiguous verdict:

• SHIP
• BLOCKED
• NEEDS EXCEPTION

Below verdict:

• One-line “why” summary (max ~140 chars), e.g. “Reachable path observed; exploit signal present; Policy ‘prod-strict’ blocks.”

5.3 Chips (Each chip is clickable)

Minimum set:

• Reachability: Reachable / Not reachable / Unknown (with confidence)
• Effective VEX: affected / not_affected / under_investigation
• Exploit signal: yes/no + source indicator
• Exposure: internet-exposed yes/no (if available)
• Asset tier: tier label
• Gate: allow/block/exception-needed (policy gate name)

Chip click behavior:

• opens evidence panel anchored to the proof objects
• shows source chain (concelier/excititor preserved sources)

5.4 Evidence Rail (Always visible right side)

List of evidence artifacts with:

• type icon
• title
• issuer
• signed/verified indicator
• short content digest
• created timestamp

Actions per item:

• preview
• copy digest
• open raw
• “show in bundle” marker

5.5 Actions Footer (Only primary actions)

• create work item
• acknowledge / mute (opens decision drawer)
• propose exception (decision with TTL plus approver chain)
• export evidence bundle

No more than 4 primary buttons. Secondary actions go into a menu.

6. Decision Flows (Mute/Ack/Exception)

6.1 Decision Drawer (common UI)

Fields:

• decision kind: mute reach / mute VEX / acknowledge / exception
• reason code (dropdown) plus free-text note
• TTL (required for exceptions; optional for mutes)
• policy ref (auto-filled; editable only by admins)
• sign and apply (server-side signing where enabled; user identity included)

On submit:

• create decision (audited)
• re-evaluate lane/verdict if applicable
• create snapshot (“DECISION” trigger)
• show toast with undo link

6.2 Undo

Undo is implemented as “revoke decision” (signed revoke record or revocation fields). Never delete.

7. Smart-Diff UX

7.1 Timeline

Chronological snapshots:

• when (timestamp)
• trigger (feed/vex/sbom/policy/runtime/decision/rescan)
• summary (short)

7.2 Diff panel

Two-column diff:

• inputs changed (with proof links): VEX assertion changed, policy version changed, runtime trace arrived, etc.
• outputs changed: lane, verdict, score, gates

7.3 Meaningful change definition

The UI only highlights meaningful changes:

• verdict change
• lane change
• score crosses a policy threshold
• reachability state changes
• effective VEX status changes

Other changes remain in expandable details.

8. Performance & UI Engineering Requirements

• findings table uses virtual scroll and server-side pagination
• case view loads in 2 steps:
  1. header narrative (small payload)
  2. evidence list plus snapshots (lazy)
• evidence previews are lazy-loaded and cancellable
• use ETag/If-None-Match for case and evidence list endpoints
• UI must remain usable under high latency (air-gapped / offline kits):
  • show cached last-known verdict with a clear “stale” marker
  • allow exporting bundles from cached artifacts when permissible

9. Accessibility & Operator Usability

• keyboard navigation: table rows, chips, evidence list
• high contrast mode supported
• all status is conveyed by text + shape (not color only)
• copy-to-clipboard for digests, purls, CVE IDs

10. Telemetry (Must instrument)

• TTFS: notification click -> verdict banner rendered
• time-to-proof: click chip -> proof preview shown
• mute reversal rate (auto-muted later becomes actionable)
• bundle export success/latency

11. Responsibilities by Service

• scanner.webservice:
  • produces reachability results, risk results, snapshots
  • stores/serves case narrative header, evidence indexes, smart-diff
• concelier:
  • aggregates vuln feeds and preserves per-source provenance
• excititor:
  • merges VEX and preserves original assertion sources
• notify.webservice:
  • emits first_signal / risk_changed / gate_blocked
• scheduler.webservice:
  • re-evaluates existing images on feed/policy updates, triggers snapshots

Document Version: 1.0 Target Platform: .NET 10, PostgreSQL >= 16, Angular v17