Clarity UX Restructure: "So What / What Do I Do Now?"

Date: 2026-03-05 Status: Draft v1 Sprint priority: #1 (highest) Depends on: G2 (remediation content) for Section D of cluster detail. G3 (scope drift) for governance conditions display. Effort estimate: 3-5 days Owner: TBD Source: docs/product/notion-synced/clarity-so-what-what-do-i-do-now.md, feedback.md, authority-paths-primer.md

---

Problem

The current UX presents data (tables, counts, severity chips) but doesn't answer the three questions a CISO asks:

1. What happened? — What authority was exercised?
2. Am I exposed? — How bad is it?
3. What should I do? — Concrete next steps.

Every surface — overview, cluster detail, authority path detail — must be restructured to answer these questions within 5 seconds.

This plan supersedes 2026-02-21-ux-feedback-fixes-plan.md WS1 (overview), WS2 (table columns), and WS3 (detail page IA). Typography baseline (WS0) and UX debt items (WS4/WS5) from that plan remain valid and should ship first.

---

Scope

Three surfaces, each with backend and frontend work:

Surface	Current State	Target State
Overview page	KPI tiles + Priority Exposures table	Authority-first KPI cards + Top Risk Clusters
Cluster detail	Header + authority paths table	Authority Exposure Brief (Sections A-D narrative)
Authority path detail	Linear section list	Reordered: graph dominant, governance conditions, risk reducers, ownership decomposed

---

Surface 1: Overview Page

1A. Page Header

• Title: "Autonomous Authority Surface" (was "Autonomous Authority Posture")
• Subtitle (muted): "Deterministic mapping of standing autonomous authority derived from observed execution."
• Keep "Last refreshed..." control

1B. KPI Cards (2 cards, authority-first)

Card	Label	Value	Subtext
A	AUTONOMOUS AUTHORITY PATHS	count	"Deterministically mapped"
B	EXECUTED PATHS WITH INVALID OWNERSHIP	count	"Observed runtime activity (30d)"

Remove: All trend arrows, % deltas, traffic-light indicators.

Backend: GET /api/v1/posture/summary — ensure total_paths and invalid_ownership_executed_count_30d are available. If invalid_ownership_executed_count_30d doesn't exist, add it to posture-service.ts.

1C. Top Risk Clusters (replaces Priority Exposures)

Section title: "Top Risk Clusters" Action: "Export Report" button (right-aligned, placeholder in W1)

Each cluster card:

• Cluster title: Functional authority label describing threat (not attribute-based filter name)
  • Example: "Sensitive Financial Authority with Orphaned Governance" (not "Orphaned + Sensitive")
• Primary metric (large): "{N} Paths"
• Secondary line (muted): "{X} Observed runtime executions (30d)"
• Pill: "+N New" (if any new paths since last 30d)

Remove from cards: % of total autonomous executions, % of total paths, "Oldest finding", trend arrows/deltas, tag chips.

Per-cluster verdict sentence: <N> autonomous paths exercised <Domain>-scoped authority and invoked <Endpoint Type> <X> times in the last 30 days.

Backend:

• GET /api/v1/posture/risk-clusters — add verdict_sentence field (template-generated from cluster data)
• Add functional_label field to risk cluster model (deterministic mapping from cluster attribute combination)
• Add new_paths_30d count

1D. Navigation Renames

• "SV0 Platform" → "SecurityV0" in nav
• "Clusters" → "Risk Clusters" in left nav (if applicable)

---

Surface 2: Cluster Detail (Authority Exposure Brief)

This is the largest change. The current header + table layout becomes a top-to-bottom scrollable narrative.

2A. Section A — What Happened (Observed Authority)

One short execution-determined narrative paragraph. Describes:

• Authority exercised
• Domain touched
• Endpoint type invoked
• Execution frequency (30d)
• Evidence source

Rules: Only exercised authority. No potential permissions. No hypothetical language.

Backend: New field in risk cluster detail response: observed_authority_narrative (deterministic template from cluster data).

2B. Section B — Am I Exposed? (Scale & Activity)

Display as compact metrics strip:

• Number of authority paths
• Total executions (30d)
• Sensitive domains exercised
• Endpoint types invoked
• Active vs dormant state breakdown

Backend: Most of these exist in the risk cluster response. Add sensitive_domains_exercised: string[], endpoint_types_invoked: string[], active_dormant_breakdown: { active: number, dormant: number } if missing.

2C. Section C — Governance Condition (Why This Is Unstable)

Display instability drivers as compact cards:

• Orphaned identities
• Scope drift
• Long-lived tokens
• Identity reuse
• Lack of runtime telemetry

Blind spots are first-class findings — not having data is itself a governance condition.

Drift appears here as summary only: "Scope drift present across 3 authority paths". Never drift explanations or evidence at cluster level.

Backend: New governance_conditions array in cluster detail response. Each condition: { type: string, label: string, affected_path_count: number, summary: string }.

2D. Section D — How Do I Fix It? (Remediation Guidance)

1-3 recommended actions tied to exercised authority. Advisory only, no enforcement.

Aggregated from authority path-level "Top Risk Reducers" — cluster does not generate new reducers.

Backend: GET /api/v1/risk-clusters/:id/remediation — aggregates from GET /api/v1/authority-paths/:id/remediation across cluster paths. Deduplicates and ranks by impact.

2E. Authority Paths Table (collapsed by default)

After Section D, a "View Authority Paths (N)" button expands the authority path table. This prevents cognitive overload.

Table columns (per latest Notion spec):

1. Authority path ID
2. Authority path name (bold)
3. Observed Executions (30d) (bold) — renamed from "30D Runs"
4. Last execution
5. Findings
6. Ownership (valid/invalid/unknown — "Invalid" badge in red)
7. Egress
8. Status
9. First seen

Remove: sensitivity column, 30D Trend column. Change: data domain supports multiple domains per path.

Backend: Ensure data_domains: string[] is available on authority path list endpoint.

---

Surface 3: Authority Path Detail Page

3A. Section Order (target state)

1. Header + risk sentence + "Create ticket" button (inactive placeholder)
2. Runtime Execution Path (graph, dominant, above the fold — renamed from "Authority Path Diagram")
3. Active Governance Conditions (renamed from "Active Risk Conditions")
4. Top Risk Reducers (from remediation service — PR #22 partially implements)
5. Ownership (boundary-level decomposition)
6. Autonomous Execution Model (renamed from "Authority State")
7. Deterministic Identity Linkage (collapsed by default)
8. Audit Metadata (collapsed by default)

3B. Graph Becomes Primary

• Move graph to first major content block after header
• Add muted label: "Execution-derived authority path"
• Graph must visually dominate the page

3C. Remove Runtime Activity Block

Replace the large Runtime Activity card with a compact strip integrated into the governance conditions area:

• Right side: "Last execution" timestamp + "Observed executions (30d)" count
• Remove: "vs prior 30d", trend deltas, telemetry source breakdown

3D. Ownership Decomposition

Replace aggregated "Path Ownership" with two explicit rows:

Row	Label	Content
1	Automation owner	Business owner display name
2	Runtime identity	SP owner — show "Not assigned" or "Departed" with error color if invalid

Remove: Aggregate "Path Ownership" header, top-level "Invalid" badge, primary/secondary/inherited hierarchy.

Backend: Ensure authority path detail response includes automation_owner and runtime_identity_owner as separate fields.

3E. Observed vs Potential Authority

• Default view shows observed (exercised) authority only
• Add collapsed panel: "Additional Standing Authority (Not Exercised)"
• This is the observed/potential split from authority-paths-primer.md

Backend: GET /api/v1/authority-paths/:id — add standing_authority field (roles/permissions granted but not exercised in 30d).

3F. Rename Inventory

Current	New
Active risk conditions	Active Governance Conditions
Authority Path Diagram	Runtime Execution Path
Authority state	Autonomous Execution Model
Automation metadata	Audit Metadata
Path Ownership	(split into Automation owner + Runtime identity)

3G. Audit Metadata Cleanup

• Remove: "Auth chain depth", "Sync version"
• Keep: "Composition hash"
• Collapse by default

3H. "Create Remediation Ticket" Button

• Inactive placeholder in header area
• Visible for demo purposes (shows direction toward Phase 3 ticketing)
• Tooltip: "Coming soon — create a remediation ticket in ServiceNow"

---

Acceptance Criteria

1. Overview page answers "what are my top risks?" within 5 seconds
2. Cluster detail answers "what happened, am I exposed, what do I do?" as a readable narrative
3. Authority path detail leads with the graph and governance conditions
4. All renames applied consistently
5. No probabilistic scoring, no ML, no trend arrows
6. Build, lint, typecheck, tests pass

---

Implementation Sequence

Phase	Surface	Effort	Dependencies
C1	Overview page — KPI cards + header renames	0.5d	None
C2	Overview page — Top Risk Clusters (FE + BE verdict sentence/functional labels)	1-1.5d	C1
C3	Cluster detail — Sections A-D narrative (FE + BE narrative/governance/remediation)	1.5-2d	C2, G2 (for Section D aggregation)
C4	Authority path detail — section reorder + renames + ownership decomposition	1-1.5d	C3
C5	Authority path detail — observed vs potential toggle	0.5d	C4
C6	Table column changes (cluster + standalone views)	0.5d	C1

Total: 5-7d, parallelizable across FE/BE.

---

PR Sequence

PR	Scope	Depends On
PR-C1	Overview KPI cards + nav renames + header changes	Typography baseline (WS0 from old plan)
PR-C2	Top Risk Clusters (FE + BE)	PR-C1
PR-C3	Authority Exposure Brief Sections A-D	PR-C2, G2 backend
PR-C4	Authority path detail reorg + renames + ownership decomposition	PR-C3
PR-C5	Observed vs potential authority toggle	PR-C4
PR-C6	Table column updates	PR-C1

---

Risks

Risk	Impact	Mitigation
Cluster functional labels need product approval per cluster	Medium	Start with a deterministic mapping table from attribute combos to labels. Flag any ambiguous combos for product review.
Verdict sentence template may not fit all cluster shapes	Medium	Define a template with fallbacks for missing data (e.g., no endpoint type → omit that clause).
Observed vs potential split requires historical execution data that may not exist for all paths	Medium	If no execution data, show all authority as "standing" with a "No execution evidence" governance condition.
Ownership decomposition requires BE schema change	Low	Additive — new fields alongside existing ownership model.