Skip to main content

UX Feedback 2026-02-22 : Authority Path Details

Claude Code Prompt: Authority Path Detail Page — Before/After Refactor

Context

We have an existing Authority Path detail page in app.securityv0.com (screenshots attached) that is too verbose, telemetry-heavy, and buries the authority graph. We want to refactor it to match the attached mockup: graph-first, risk conditions strip, ownership decomposition (automation owner + runtime identity), runtime evidence secondary, and deep proof/metadata collapsed.

Assume React + Tailwind (or our existing component system). Implement as a refactor, not a redesign. Preserve existing data bindings and backend calls. Only change layout, labeling, and section structure.


BEFORE (current behavior / layout)

Current page structure (top to bottom):

  1. Header with long path title
  2. Runtime Activity block (shows executions, vs prior 30d, “source telemetry/service telemetry/api invocation observed/sample execution”)
  3. Ownership block using an aggregated “Path Ownership” abstraction:
  • Aggregate “Invalid”
  • Automation/Agent owner row
  • Service Principal row
  1. Risk Conditions cards
  2. Execution Path graph (below the fold)
  3. Autonomous Execution Model section
  4. Deterministic Identity Linkage section
  5. Audit Metadata

Problems:

  • Graph is not the primary control surface; it appears too late.
  • Runtime/telemetry elements are overly prominent and include “vs prior 30d” style metrics we cannot fully guarantee.
  • Ownership is too “compounded”; CISO feedback: wants breakdown by ownership boundary (automation owner vs runtime identity / SP) not an aggregated status.
  • Too many sections expanded by default; page feels dense and not CISO-optimized.

AFTER (target behavior / layout)

Refactor the Authority Path detail page to match the mockup:

https://stitch.withgoogle.com/projects/6789925312600581530?node-id=f96f0fcd20e0405e926ff2ac2cf9d35d

Stitch design

Stitch design code (HTML)

Stitch design

Stitch design code (HTML)

A) Top-of-page hierarchy

  1. Title + breadcrumb + “Create ticket” remains in header.
  2. Add a small label above the graph section:
  • “Execution-derived authority path” (muted, small).
  1. Graph becomes the first major card (dominant, above the fold).

B) Replace “Runtime Activity” block with a compact strip

Remove the large Runtime Activity card entirely.

Instead create a single combined strip card below the graph:

Section title: “Active risk conditions”

Left side (risk condition tiles/badges):

  • Invalid owner (with “Since Xd”)
  • Sensitive: fin (with “Since Xd”)
  • LLM egress (with “Since Xd”)

Right side (runtime evidence, visually secondary):

  • Last execution (timestamp)
  • Observed executions (30d) (count)

Rules:

  • Use wording “Observed executions (30d)” (not “Executions”, not “30D runs”).
  • Do not show “vs prior 30d” or any trend deltas anywhere on this page.

C) Ownership: replace compounded view with boundary-level view

Replace the current “Path Ownership”/aggregate abstraction with a simpler “Ownership” card:

Ownership card structure:

  • Row 1: Automation owner (business owner)
  • Show name if present.
  • Row 2: Runtime identity
  • If missing: show “Not assigned” (styled as invalid)
  • Include optional short reason text when invalid (muted): e.g. “Service principal owner departed” (do not show both “Not assigned” and “departed” as separate states; pick one primary state and a single reason).

Remove:

  • Aggregate “Path Ownership” header text “Aggregate status across all objects in this path”
  • The separate “Invalid” badge at the top of the ownership card
  • Any extra ownership hierarchy like primary/secondary/inherited

D) Authority state

Keep “Authority state” card (Execution model, Auth type, Human session required) but ensure:

  • It is secondary to Ownership (layout can remain side-by-side as in mockup).
  • No extra telemetry language appears inside it.

E) Everything below becomes secondary / collapsible

Below Ownership + Authority state, keep deeper sections but collapse by default:

  • Deterministic linkage proof
  • Automation metadata
  • Audit metadata
  • Any identity linkage details

Only expand these when user clicks.


Implementation Instructions (how to do it)

  1. Identify the Authority Path detail route/component (likely AuthorityPathDetailPage or similar).
  2. Rearrange existing components rather than rewriting logic:
  • Move graph component to top.
  • Remove/hide the existing Runtime Activity component.
  • Create a new “Risk & Runtime Strip” component using existing fields:
    • Risk conditions already computed (invalid owner, sensitive domain, llm egress).
    • Runtime fields already computed (last execution, observed executions 30d).
  1. Refactor Ownership:
  • Replace aggregate ownership UI with two rows:
    • automationOwner
    • runtimeIdentityOwner (or equivalent identity owner)
  • Keep data mapping consistent with current backend responses.
  1. Make deep sections collapsible by default using existing accordion/collapse patterns.
  2. Ensure typography/hierarchy matches mockup:
  • Graph card is the largest block.
  • Risk condition tiles are prominent.
  • Runtime evidence text is smaller and muted.

Acceptance Criteria

  • Graph is above the fold and is the first major content block after header.
  • No “vs prior 30d”, no trend deltas, no telemetry source breakdown list.
  • Strip card exists with:
  • Left: risk conditions (invalid owner, sensitive: fin, llm egress) each with “Since Xd”
  • Right: last execution + observed executions (30d)
  • Ownership card shows only:
  • Automation owner
  • Runtime identity (with invalid display if missing)
  • Deterministic linkage proof + metadata sections are collapsed by default.
  • No new backend dependencies or new data collection required.

Notes

  • This is a wedge-phase UX. Avoid adding new concepts (risk scoring, remediation workflows).
  • Keep labels tight and consistent with the mockup.
  • Prefer minimal diffs and component reuse.