stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 2 Releases Wiki Activity
Files
17419ba7c4f8e35ed78033515115088eb40d20a7
git.stella-ops.org/docs-archived/ui-analysis/rework/01-ui-rework-adivsory.md

18 KiB
Raw Blame History

Below is a UI/UX advisory based on your new product vision (evidence-based release control plane with hybrid reachability) and the ASCII blueprints of the current UI information architecture.

I’m going to be blunt: you already have many of the right primitives (evidence bundles, proof chain, policy simulation, orchestration, reachability center), but the IA and “default story” still tells users “scanner + admin console.” The fix is not cosmetic—this is a release-first product re‑framing in navigation, objects, and workflows.

1) What the UI must communicate in 10 seconds

When a buyer opens Stella Ops, they must immediately understand:

  1. “What is deployed where” (by digest, per environment/target)
  2. “What is allowed to ship next” (promotion requests + approvals)
  3. “Why it is allowed/blocked” (policy gates + reachability evidence)
  4. “Where the evidence is” (one-click proof chain and export)

Everything else (vuln explorer, SBOM graph, VEX hub, feeds, ops health) is supporting detail.

Right now the UI communicates: “Security dashboard → findings → triage → policy → ops/admin.” That’s the wrong default narrative for a release control plane.

2) New UX mental model: 5 core objects, 3 core jobs

Core objects (they must exist everywhere as first-class nouns)

  • Release: bundle of component→digest mappings (immutable identity)
  • Environment: Dev/QA/Staging/Prod (policies, windows, approvals)
  • Promotion: request to move a Release to an Environment
  • Deployment: execution instance (workflow run against targets)
  • Evidence Packet: signed bundle of inputs/outputs of a decision/run

Core jobs (the UI must optimize for these first)

  1. Ship a release: create → request promotion → approve → deploy
  2. Explain/justify a decision: why allowed/blocked + evidence
  3. Operate with confidence: drift, CVE updates, replay, audit export

Your current UI has these elements, but they’re fragmented across Analyze/Triage/Policy/Evidence/Ops.

3) High-level IA change: make “Releases” the product, not a submenu

Current top-level nav (scanner-centric)

HOME / ANALYZE / TRIAGE / POLICY / OPS / NOTIFY / ADMIN

Recommended top-level nav (release control plane)

Use fewer, higher-signal nouns. Example:

  1. Control Plane (default landing)
  2. Releases
  3. Approvals
  4. Security
  5. Evidence
  6. Operations
  7. Settings (consolidated configuration)

If you insist on 5 groups max, merge:

  • Control Plane + Releases (same section)
  • Operations remains admin-only
  • Settings stays separate

What changes immediately

  • Home / becomes “Control Plane Overview” (release pipeline + action inbox)
  • Release Orchestrator becomes the central product area (not hidden)
  • Analyze/Triage collapse into “Security” (because they exist to inform release gating)
  • Evidence becomes a single unified section (today it’s scattered across triage, evidence-export, proof-chain, release evidence)

4) Shell & navigation redesign: move from top mega-menu to left rail

Your current header menu already has too many cognitive branches. A release control plane benefits from a left navigation rail + a top bar for global context.

Proposed shell blueprint

┌──────────────────────────────────────────────────────────────────────────────┐
│ Stella Ops        [Global Search: release/digest/CVE/env]   [Tenant ▼] [User] │
│ Offline: OK | Feeds: 2026-01-15 | Policy: prod-baseline v3 | Evidence: ON     │
├───────────────┬──────────────────────────────────────────────────────────────┤
│ CONTROL PLANE │  Control Plane Overview                                      │
│ Releases      │  ┌────────────────────────────────────────────────────────┐  │
│ Approvals     │  │ Environment Pipeline: Dev → QA → Staging → Prod         │  │
│ Security      │  │  Dev: v1.3.0  QA: v1.2.5  Stg: v1.2.4  Prod: v1.2.3      │  │
│ Evidence      │  └────────────────────────────────────────────────────────┘  │
│ Operations    │  ┌───────────────────────────┐ ┌──────────────────────────┐  │
│ Settings      │  │ Action Inbox              │ │ Drift & Risk Changes      │  │
│               │  │ - 3 approvals pending     │ │ - 2 prod drifts detected  │  │
│               │  │ - 1 blocked promotion     │ │ - 5 CVEs updated          │  │
│               │  │ - 2 failed deployments    │ │ - 1 key expiring          │  │
│               │  └───────────────────────────┘ └──────────────────────────┘  │
└───────────────┴──────────────────────────────────────────────────────────────┘

Top bar is for:

  • Global search
  • Tenant context
  • Offline / feed snapshot / policy baseline status (your differentiators)
  • Evidence mode (exportability / signing availability)
  • User actions

Left nav is for the product story.

5) Consolidate configuration into a single “Settings” area

You already identified this, and you’re correct. Right now configuration is scattered:

  • /setup, /console/configuration, /integrations, /admin/*, /ops/*, /concelier/*

This creates a “Where do I configure X?” problem and makes the product feel unfinished.

Proposed Settings structure (single hub, left-side tabs)

Settings

  • Integrations

    • Registries
    • SCM
    • CI/CD
    • Targets & Hosts
    • Secrets
    • Notifications

  • Release Control

    • Environments (policies, approval rules, freeze windows)
    • Targets (Docker/Compose/ECS/Nomad)
    • Agents (health, capabilities)
    • Workflows (templates, step registry)

  • Trust & Signing

    • Keys (rotation)
    • Issuers
    • Certificates
    • Rekor / transparency settings

  • Security Data

    • Advisory sources / connectors
    • Feed mirror / airgap
    • Version locks

  • Identity & Access

    • Users
    • Roles & scopes
    • OAuth clients
    • API keys

  • Tenant / Branding

  • Usage & Limits (quotas, throttle)

  • System

    • Platform health
    • Doctor diagnostics
    • SLOs
    • Jobs / queues (admin-only)

What to move under Settings (specific existing routes)

  • /console/configuration → Settings → Integrations
  • /integrations/* → Settings → Integrations (same UI, one place)
  • /admin/trust/* → Settings → Trust & Signing
  • /admin/registries → Settings → Integrations → Registries (merge)
  • /admin/notifications → Settings → Integrations → Notifications (or Settings → Notifications)
  • /ops/feeds, /ops/offline-kit → Settings → Security Data (unless you want “Operations”)
  • /ops/quotas → Settings → Usage & Limits
  • /console/admin/* → Settings → Identity & Access (admin-only)

This one consolidation will make the product feel 2x more mature.

6) Rebuild “Home” into a Release Control Plane dashboard (not a security dashboard)

Your current Home dashboard is well designed—but it optimizes the wrong story (vulns, risk, reachability pie charts).

Replace / with: “Control Plane Overview”

Must show:

  • Environment pipeline status (what’s deployed)
  • Pending promotions & approvals
  • Deployment outcomes (last N)
  • Drift / risk changes since last evidence
  • “System trust posture” (feeds stale? keys expiring? offline?)

Security metrics should be secondary and contextual.

Keep the current security dashboard, but move it under Security

  • The existing / dashboard becomes /security/overview (or /security/dashboard)

7) Make “Approvals” a first-class product surface, not a subpage

Approvals are the moment where buyers “feel” governance and auditability.

Current approvals blueprint is good; what’s missing is evidence-first structure

Approval card must answer:

  1. What is changing?
  2. What is the risk delta?
  3. What do the gates say?
  4. Where is the evidence?
  5. What do I do next?

Suggested approval card layout

Release: app-svc v1.2.5  (Digest bundle locked)
From: QA   →  To: Staging        Requested by: deploy-bot   2h ago

WHAT CHANGED (Diff summary)
- Components changed: 3
- New CVEs introduced: 2 (1 reachable)
- Fixed CVEs: 5
- Config drift: none

GATES (Policy baseline: stg-baseline v3.1)
✅ SBOM valid + signed
✅ Provenance present (SLSA attestation)
⚠️ 3 high CVEs (2 not-affected via VEX, 1 uncertain reachability)
❌ 1 reachable critical path found (confidence 0.82)

ACTIONS:
[View Evidence Packet] [View Reachability Witness] [Request Exception] [Approve] [Reject]

Key UX improvements:

  • Diff-first becomes a core affordance everywhere (you already have lineage diff patterns—reuse them).
  • “View Reachability Witness” must exist right on the approval decision (this is your moat).

8) Unify “Releases” around digest-first identity and environment mapping

Today you have:

  • Artifact Workspace (triage)
  • Release Orchestrator (separate)
  • Findings and scans (analyze)

To match the vision, “Release” becomes the thing users manage, and “Artifacts” become a supporting detail.

New Releases area should have 4 core pages

  1. Releases List
  2. Release Detail
  3. Environment Detail
  4. Deployment Runs

Release detail page should be your flagship screen

Must include:

  • Release identity (bundle, digests)
  • Promotion history and current deployment per environment
  • Gate results (policy + reachability + VEX)
  • Evidence packet + proof chain (one-click)
  • “Create promotion request” and “Rollback” actions

Release detail blueprint (suggested)

RELEASE: v1.2.5   Bundle: sha256:bundle...    Created by CI: gh-actions #882

[Overview] [Components] [Gates] [Promotions] [Deployments] [Evidence] [Proof Chain]

OVERVIEW
- Dev: deployed ✓     QA: deployed ✓     Staging: pending approval ⚠     Prod: v1.2.3
- Risk score: 62 (↓ -8 from previous)   Reachability coverage: 89%

PRIMARY ACTIONS: [Request Promotion] [Generate Evidence] [Export] [Replay Verify]

9) Embed reachability everywhere it matters (and nowhere it doesn’t)

Reachability is not a separate “center” for most users. It’s an explanation layer that must appear:

  • On approvals (decision moment)
  • On finding detail (why this CVE matters)
  • On release gates (why blocked/allowed)
  • In evidence packet (what was proven)

Reachability presentation rules (UX contract)

  • Always show a three-tier summary:

    • State: Reachable / Unreachable / Uncertain
    • Confidence: numeric and explained (“0.82; runtime signal present”)
    • Evidence: witness path / guards / dynamic edges

  • Only show full graphs on demand (progressive disclosure).

  • “Uncertain” must be actionable: show why uncertain, and the top 1–2 ways to resolve uncertainty (runtime signal, config, guard).

Add a “Witness Viewer” component (reusable)

A dedicated view that can render:

  • Mermaid/DOT export
  • Call path
  • Guards/dynamic loading notes
  • Evidence URIs
  • Replay/verify button

This becomes a shared panel used in:

  • Approvals
  • Finding detail slide-out
  • Evidence packet viewer

10) Evidence: stop scattering it; make one “Evidence” experience

You currently have evidence in:

  • /evidence/*
  • /proofs/:subjectDigest
  • /triage/audit-bundles
  • /release-orchestrator/evidence

This is a classic maturity killer: users lose trust when “audit artifacts” are spread across 4 locations.

Recommended change

Create one Evidence section with:

  • Evidence Packets (searchable, filterable by release/env/deployment)
  • Proof Chains
  • Replay/Verify
  • Export Center
  • Audit Bundles (as a type of evidence packet)

Then:

  • Remove / hide “Evidence” tabs inside other areas, replacing them with a link:

    • “Open Evidence Packet” → takes you to Evidence section pre-filtered.

11) Rename/merge “Analyze” + “Triage” into a single “Security” area

Right now:

  • Analyze = findings/vulns/graph/lineage/reachability/vex/unknowns/patch-map
  • Triage = artifacts/exceptions/audit bundles/risk profiles

To a customer this reads like: “two versions of security.”

Recommended Security structure

Security

  • Overview (the old home security dashboard)
  • Findings (scans & findings)
  • Vulnerabilities (global library CVEs)
  • Artifact Intelligence (SBOM graph, lineage diff, unknowns, patch map)
  • VEX (hub + consensus + conflicts)
  • Exceptions (policy exceptions and risk acceptances)
  • Risk (profiles / scoring explanations)

And crucially:

  • Each of these pages must link back to Releases/Environments impacted.

Example:

  • Vulnerability detail shows: “Impacts: 3 releases; deployed in Prod: yes/no.”

That’s how security becomes a gate, not a silo.

12) Fix route and naming inconsistencies (small work, big polish)

Your own observations list the fragmentation. Customers feel this as “unfinished.”

Normalize path prefixes

  • /release-orchestrator/* → /releases/* (or /control-plane/*)
  • /admin/vex-hub/* → /security/vex/*
  • /scheduler/* → /ops/scheduler/* (or /operations/scheduler/*)
  • /console/admin/* → /settings/access/* (admin-only)
  • /concelier/trivy-db-settings → /settings/security-data/trivy

Normalize nouns in the UI

  • “Artifact Workspace” is security-centric; for release product it becomes:

    • “Artifacts” (inventory) or “Digests”

  • “Scans & Findings” should be “Findings”

  • “Policy Studio” is fine for power users, but add a simple “Policies” list entry for everyone.

13) Add an “Action Inbox” to unify the product experience

Today approvals are one page, exceptions are another, dead-letter jobs are in ops, drift alerts are separate docs.

Create a single page: Inbox

  • Pending approvals
  • Pending exception reviews
  • Drift alerts (reachability drift, risk drift)
  • Failed deployments
  • Key expirations / feed staleness (if they block evidence)

This becomes the daily entry point for an operator.

14) Styling and readability guidance (practical, not decorative)

A release control plane UI must be “audit calm,” not “security noisy.”

Rules:

  • Prefer text + badge over emoji status indicators in production UI.

  • Use progressive disclosure: summary → details panel → deep technical view.

  • Replace “dashboard card overload” with 2–3 high-signal panels:

    • Pipeline
    • Inbox
    • Drift/Risk Changes

  • Make digest visibility consistent:

    • show short digest everywhere; full digest on hover/copy

  • Provide “Copy” buttons for operational fields (digest, env, release id, evidence id).

  • Use consistent phrasing for gates:

    • PASS / WARN / BLOCK
    • always with one-line reason

  • Show policy baseline version and feed snapshot version where decisions are made. That’s trust.

15) Concrete agent task list (what to change, where)

A) Navigation & IA refactor

  1. Add new top-level nav items:

    • Control Plane, Releases, Approvals, Security, Evidence, Operations, Settings

  2. Move Release Orchestrator into nav and make it default landing route.

  3. Remove Analyze/Triage split from top-level; merge into Security.

  4. Move VEX Hub out of /admin and into Security section (keep permissions).

  5. Add Settings section and start migrating config pages under it.

B) Home / replacement

  1. Replace HomeDashboardComponent content:

    • Pipeline view, inbox, drift/risk deltas, system trust posture.

  2. Move existing “Security Dashboard” content to /security/overview.

C) Release experience upgrades

  1. Implement Release Detail flagship page:

    • Tabs: Overview, Components, Gates, Promotions, Deployments, Evidence, Proof Chain

  2. Implement Diff-first view for promotions (reuse lineage diff patterns).

D) Approvals redesign

  1. Make Approvals a first-class nav item.
  2. Add “View Evidence Packet” + “View Reachability Witness” as primary actions.
  3. Add “Request Exception” flow from the approval screen (no hunting).

E) Evidence unification

  1. Create a single Evidence hub:

    • Bundles, Proof Chains, Replay/Verify, Export

  2. Redirect:

    • /proofs/:subjectDigest into Evidence area
    • /release-orchestrator/evidence becomes a filtered Evidence view
    • /triage/audit-bundles becomes Evidence → Audit Bundles

F) Settings consolidation

  1. Create Settings shell page + left sidebar.

  2. Migrate:

    • Integrations (merge configuration pane + integration hub)
    • Trust, registries, notifications, feeds/offline kit, quotas

  3. Deprecate redundant entry points after migration.

G) Cross-linking (critical)

Add “Impacts” panels everywhere:

  • On CVE detail: affected releases/environments + deployed status
  • On Finding detail: show release gate impact + direct link to approval/promotion
  • On Release gate: show underlying findings list filtered to that release

H) Reachability witness viewer component

  1. Build a reusable panel:

    • State, confidence, witness path, guards/dynamic loading flags, replay verify

  2. Embed it in:

    • Approvals
    • Finding detail
    • Evidence packet viewer

16) What I would prioritize (highest ROI, least debate)

If you do only three things first, do these:

  1. Make / the Control Plane Overview (pipeline + inbox + drift)
  2. Consolidate Settings (stop configuration fragmentation)
  3. Make Approvals evidence-first with reachability witness (moat on display)

Everything else becomes easier after those.