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):
- Header with long path title
- Runtime Activity block (shows executions, vs prior 30d, “source telemetry/service telemetry/api invocation observed/sample execution”)
- Ownership block using an aggregated “Path Ownership” abstraction:
- Aggregate “Invalid”
- Automation/Agent owner row
- Service Principal row
- Risk Conditions cards
- Execution Path graph (below the fold)
- Autonomous Execution Model section
- Deterministic Identity Linkage section
- 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 code (HTML)

Stitch design code (HTML)
A) Top-of-page hierarchy
- Title + breadcrumb + “Create ticket” remains in header.
- Add a small label above the graph section:
- “Execution-derived authority path” (muted, small).
- 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)
- Identify the Authority Path detail route/component (likely
AuthorityPathDetailPageor similar). - 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).
- Refactor Ownership:
- Replace aggregate ownership UI with two rows:
automationOwnerruntimeIdentityOwner(or equivalent identity owner)
- Keep data mapping consistent with current backend responses.
- Make deep sections collapsible by default using existing accordion/collapse patterns.
- 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.