Skip to main content

UX & Information Architecture Review

Overall Grade: B-​

The platform has made significant progress since the March 3 review. The Overview page now leads with execution count (not path count), verdict sentences exist on cluster cards, the title is execution-determined ("Observed Autonomous Execution (30d)"), and the Risk Cluster Detail page now implements the full A/B/C/D section structure from the Clarity spec. The Authority Path Detail page is well-structured with graph-first layout, risk condition tiles, and clear ownership decomposition.

However, critical gaps remain: the Overview page has drifted back from the spec in a different direction (now showing delta percentages the spec explicitly removed), navigation has structural gaps that break wayfinding between the two primary user flows, authority paths still collapse role information, and terminology is inconsistent across pages. The CISO-vs-analyst audience separation is partially achieved but leaks in both directions.

Information Hierarchy​

PagePrimary MessageClear?Issues
Overview"Here is your observed autonomous execution activity and where the risk clusters are"PARTIALLYDelta percentages on KPI cards add noise the spec removed. Four secondary stat cards (Active Autonomous, Dormant, etc.) compete with the hero KPIs. No OWASP/business relevance framing per Deloitte feedback.
Risk Clusters List"These are your risk clusters ranked by priority"YESClean. Cards have verdict sentences. Priority badges are clear.
Risk Cluster Detail (Exposure Brief)"What happened, how exposed are you, governance failures, and how to fix it"YESBest CISO-facing page. Sections A-D match spec. Collapsible paths table prevents overload. Governance checklist is honest about "not-assessed" items.
Authority Paths List"All authority paths with filtering"YESAnalyst page, well-executed. Column for "Observed Executions (30d)" correctly named per spec.
Authority Path Detail"This specific path's execution evidence, risk conditions, and remediation"YESStrongest analyst page. Graph-first, risk tiles with duration, remediation with impact scores.
Exposures"Workloads with active findings"PARTIALLYNo summary bar. "Binding" column unexplained. Severity filter exists but no grouping or visual summary at top.
Findings"All findings in a flat table"NOFlat table with no grouping, no summary chart. Entity names now appear (improvement from March 3) but still analyst-only.
Data Domains"Business data classification and resources"YESMost CISO-intuitive page. Card layout with sensitivity, domain names, resource counts.
Identities"Service identities in the environment"YESClean table. Source badges work. Missing "Findings" column to show which are problematic.
Execution Chains"Cross-system execution chains"PARTIALLY"Execution chain" concept unexplained. Internal column labeled "Sensitive Domains" but underlying data field is blast_radius_domains -- good label choice.
Graph Explorer"Visual graph of all entities and relationships"NO (for CISO)Correctly scoped as analyst tool. 105-node default is unusable. Risk Paths preset exists but is buried in sidebar.
Dashboard (legacy)"Exposure discovery with findings and workload stats"N/AStill exists in codebase at /dashboard but not in navigation. Uses "RG1/RG2" jargon. Should be removed or hidden.
Exposure Detail"Deep dive on a single workload"YESStrong evidence presentation. Tabs (Graph/Effects/Evidence/Findings/Timeline) well-structured.

Navigation & Wayfinding​

Mental model alignment: WEAK​

The spec defines a clear mental model: Overview -> Cluster Exposure Brief -> Authority Paths -> Path Detail. This flow works but has gaps:

Primary navigation items (sidebar):

  • Overview
  • Risk Clusters
  • Authority Paths
  • Identities
  • Data Domains
  • Graph Explorer

Missing from sidebar but accessible via routes:

  • Exposures (/exposures) -- reachable only from the legacy Dashboard
  • Findings (/findings) -- reachable only from the legacy Dashboard or direct URL
  • Entities (/entities) -- reachable only from links within other pages
  • Execution Chains (/chains) -- reachable only from direct URL
  • Syncs (/syncs) -- reachable only from direct URL
  • Temporal Compare (/temporal) -- reachable only from direct URL
  • Dashboard (/dashboard) -- reachable only from direct URL

Dead ends found:​

  1. Exposures page has no sidebar entry. A user who reaches Exposures via the Dashboard cannot find it again from the sidebar. The Exposures page is referenced in Sprint context as a key view.

  2. Findings page has no sidebar entry. Although the spec says findings should be surfaced within the cluster->path drill-down (and they are), the standalone Findings page is still a route with no navigation path except the legacy Dashboard or bookmarks.

  3. Legacy Dashboard (/dashboard) exists as a parallel universe. It uses different terminology ("Exposure Discovery", "RG1", "RG2"), different hierarchy (findings-first, workload-centric), and links to Exposures and Findings pages that are orphaned from the main nav. This creates a split personality: a user who lands on /dashboard versus / sees fundamentally different products.

  4. Entity Detail breadcrumb shows truncated hash IDs (e.g., 29283a22...) instead of entity names. The formatBreadcrumbSegment function in Layout.tsx truncates ObjectIDs but does not resolve them to display names. This means breadcrumbs on detail pages are unreadable.

  5. Graph Explorer -> Entity Detail has no return path. The "View in Graph" button on Entity Detail navigates to /graph without preserving focus state, so the user loses their graph context.

  • Overview -> Exposures: No link from Overview to the Exposures page. The spec's "Priority Exposures" section was replaced by "Top Risk Clusters," but Exposures as a concept is now disconnected.
  • Data Domains -> Authority Paths: No link showing "which authority paths reach this domain." The March 3 review recommended adding "Reached by X authority paths" to domain cards -- still missing.
  • Identities -> Authority Paths: No link showing "which authority paths use this identity."
  • Risk Cluster Detail -> related clusters: No cross-links between overlapping clusters (e.g., "Unowned Sensitive Access" overlaps with "Unowned Sensitive Access with LLM").

Breadcrumbs are implemented via URL path segments, which produces correct results for simple paths (Overview > Risk Clusters > orphaned_sensitive) but shows raw cluster keys rather than human-readable labels. Example: Overview > Clusters > orphaned_sensitive instead of Overview > Risk Clusters > Unowned Sensitive Access.

Label Audit​

Jargon count: 23 terms requiring domain knowledge​

TermWhere UsedProblemSuggested Replacement
Authority PathEverywhereCore concept, unavoidable, but never defined for new usersKeep, but add tooltip: "An execution route from a workload through an identity to a destination"
Risk ClusterNav, Overview, Cluster pagesAcceptable for security audienceKeep
Egress CategoryPath list, Cluster detail, badges"Egress" is network jargon"Data destination" or "Outbound access type"
Identity BindingPath detail, Exposure detailDeep IAM jargon"Authentication link" or "How the workload authenticates"
Orphaned OwnershipFindings, clusters, badgesAcceptable for security audience but unclear to business execs"No active owner" (already used in some places)
Dormant AuthorityStat cards, findingsWhat counts as "dormant"?Add "(no executions in 90+ days)" inline
Scope DriftFindings, cluster detailSecurity jargon"Permission expansion" or "Scope expanded beyond original grant"
Reachability DriftFindingsDeep security jargon"New destinations reached"
Ownership DriftFindingsAmbiguous -- drift of what?"Owner departed" or "Owner status changed"
Operator-AssistedOverview stat cardWhat is the difference from human-triggered?Combine into "Requires human session"
Active Autonomous / Dormant Authority (stat cards)OverviewLabels say "Identities" in tiny subtext but the main label doesn't"Active Autonomous Identities" and "Dormant Identities"
RG1, RG2, RG3, RG4, RG5Legacy DashboardCompletely opaqueNot in main nav -- but should be removed from codebase
blast_radius_domainsAPI field exposed in Execution ChainsExposed as "Sensitive Domains" in UI -- good, but underlying naming creates confusion in codeN/A (code-level)
unproven_executionFinding typeWhat does "unproven" mean?"No execution evidence observed"
unknown_identity_bindingFinding typeDouble jargon"Authentication method unknown"
privilege_justification_gapFinding typeReads like compliance language"Unjustified permissions"
reachable_sensitive_domainFinding typeOverly formal"Accesses sensitive data"
ownership_ambiguousFinding typeWhat makes ownership "ambiguous"?"Multiple or conflicting owners"
ownership_degradedFinding type in filter optionsNot distinct from "ownership_drift"Consolidate with ownership_drift
llm_egressFinding type, badges"Egress" is jargon"Sends data to LLM"
external_egressFinding type, badgesSame"Sends data externally"
execution_modeExposure detail badgeTechnical"How it runs"
evidence_completenessExposure detailWhat is "completeness"?"Evidence coverage" with explanation

Inconsistencies (same concept, different names):​

ConceptName in Place AName in Place BName in Place C
Ownership status "invalid""Invalid" (badge)"Orphaned" (badge on different page)"No active owner" (cluster description)
Execution count in 30 days"Observed Executions (30d)" (Overview KPI)"30d Executions" (cluster detail table header)"Executions (30d)" (exposure grid)
Risk severity"Critical/High/Moderate/Low" (cluster priority)"critical/high/medium/low" (finding severity)"P0/P1" (not present in current UI, referenced in March 3 review)
The person who built the automation"Automation owner" (path detail)"Owner" (exposures table)"Creator" (entity detail)
Same finding type"orphaned_ownership" (code)"Invalid owner" (path detail tile)"Orphaned" (ownership badge)

Worst offenders:​

  1. Ownership terminology chaos: The same concept is called "orphaned," "invalid," "no active owner," and "ownership degraded" across different pages. A CISO seeing "Invalid" on one page and "Orphaned" on another will wonder if they are different states.

  2. "Egress" everywhere: The word "egress" appears in badges, finding types, cluster names, and filters. A CISO hears "egress" and thinks network -- not necessarily "this automation sends data to an LLM." The cluster labels ("LLM Data Egress", "Unowned External Egress") are better, but the badges still show raw "external" or "llm" without context.

  3. "Authority Path" vs "Execution Chain": Both describe connected execution flows but have different pages, different data models, and no cross-reference. The relationship between them is unexplained.

Data Presentation Issues​

[UX1] Overview KPI Cards Show Delta Percentages the Spec Removed​

  • Page: Overview (OverviewPage.tsx)
  • Problem: The KPI cards show DeltaBadge with percentage deltas (e.g., +838% executions, +81% paths). The Feb 22 UX feedback spec explicitly says "Remove all trend arrows and % deltas." The Clarity spec says hero tiles should not have deltas. The current Overview has re-added them.
  • Impact: The +838% execution delta is visually alarming and dominates attention. But without baseline context, a CISO cannot interpret it. Is +838% bad? Compared to what? This is the "numbers without context are noise" problem. It also contradicts the spec's position that trend deltas are unreliable at this stage.
  • Fix: Remove DeltaBadge from Overview KPI cards. If trend data is retained for future use, add it to the Cluster Detail (where the narrative provides context) rather than the Overview.

[UX2] Overview Title Has Changed Again​

  • Page: Overview (OverviewPage.tsx)
  • Problem: The title is now "Observed Autonomous Execution (30d)" -- this matches the Clarity spec title, not the Feb 22 Stitch target ("Autonomous Authority Surface"). The subtitle says "Deterministic view of autonomous activity observed across your environment." The March 3 review noted the title should be execution-determined.
  • Impact: Low -- the current title is arguably better than the Stitch target, as it foregrounds observed execution. But it represents a drift from the most recent spec instruction. Product team should explicitly decide which title wins.
  • Fix: Product decision needed. Current title is execution-determined and defensible. Document the choice.

[UX3] Authority Path Roles Collapse -- Sprint Blocker​

  • Page: Authority Paths List, Cluster Detail paths table, Path inline expansion
  • Problem: The API returns via_roles arrays with multiple roles (e.g., ["sql_clinical_reader", "sql_admin_reader"]), and the UI renders all of them in the expanded row. However, in the table row itself, roles are not shown at all. The table row shows only the path chain (workload -> identity -> destination). The roles are only visible when the user expands the row. Sergey's feedback says "Authority paths collapsing -- showing 1 role when there are 4."
  • Impact: A CISO scanning the authority paths table has no visibility into the privilege surface. Two paths to the same destination might have very different risk profiles because of different roles, but this is invisible at the table level. The Standing Authority panel on Path Detail also truncates roles: path.via_roles.slice(0, 2).join(", ") + (+N).
  • Fix: Add a "Via Roles" column to the authority paths table, or show role count in the PathLabel component. For the standing authority table, show all roles or at minimum a count badge.

[UX4] Risk Cluster Detail: Governance Checklist Has False Deduplication​

  • Page: Risk Cluster Detail (RiskClusterDetailPage.tsx)
  • Problem: The GovernanceChecklist component maps multiple distinct finding types to the same label "Orphaned identities" -- orphaned_ownership, unknown_identity_binding, and ownership_drift all produce "Orphaned identities" as the label. The deduplication then removes the duplicates, so a cluster with both orphaned ownership AND unknown identity binding shows only one line. These are different governance failures being collapsed into one.
  • Impact: The CISO sees fewer governance conditions than actually exist. This undersells the severity and hides the specific failure mode. It directly contradicts the spec's requirement to "explain structural amplification."
  • Fix: Use distinct labels: "Orphaned identities" for orphaned_ownership, "Unbound identity" for unknown_identity_binding, "Ownership changed" for ownership_drift. The spec lists these as separate conditions.

[UX5] "Not-Assessed" Governance Conditions Shown Unconditionally​

  • Page: Risk Cluster Detail, Governance Checklist
  • Problem: "Long-lived tokens" and "Lack of runtime telemetry" are always shown as "not-assessed" with a grey icon. These appear on every cluster regardless of context.
  • Impact: Two of the governance conditions always show the same thing on every cluster, adding visual weight with zero informational value. A CISO will quickly learn to ignore this section.
  • Fix: Only show "not-assessed" conditions when they are contextually relevant (e.g., show "Long-lived tokens: not assessed" only for clusters involving credentials). Or remove them until the platform can actually assess them.

[UX6] Findings Page Has No Visual Summary​

  • Page: Findings (FindingsList.tsx)
  • Problem: 6 findings in a flat table with filters. No severity distribution chart, no grouping by type, no summary sentence. Just a flat table. The March 3 review flagged this exact issue. The API response includes bySeverity and byType metadata that could power a summary bar.
  • Impact: A CISO landing on this page has to mentally aggregate: "How many critical? What types?" The data exists in the API response but is not rendered.
  • Fix: Add a summary strip at the top: severity distribution bar + type counts. The API already returns meta.bySeverity and meta.byType. This is a rendering change, not a data change.

[UX7] Exposures Page: "Binding" Column Is Cryptic​

  • Page: Exposures (ExposuresPage.tsx)
  • Problem: The Exposures table has a "Binding" column that shows "Bound" or "Unbound." This is deep IAM jargon. The March 3 review recommended adding a tooltip -- still missing.
  • Impact: A CISO sees "Unbound" and has no idea what it means. Is it bad? The column header offers no help.
  • Fix: Either rename to "Identity Link" with a tooltip ("Whether this workload authenticates via a verified service identity"), or add an informational icon with explanation.

[UX8] No OWASP/Business Relevance Framing​

  • Page: All CISO-facing pages
  • Problem: Deloitte feedback (from Sergey's email): "What's the OWASP impact? What's the business relevance?" The OWASP Top 10 for Agentic Applications mapping exists in the specs (mapping-to-owasp-top-10-for-agentic-applications.md) and shows strong coverage (ASI02, ASI03, ASI08, ASI10), but none of this is surfaced in the UI. Findings, clusters, and paths have no OWASP classification visible.
  • Impact: When a CISO presents SecurityV0 findings to a board or auditor, they need to map them to a recognized framework. Currently they must do this manually.
  • Fix: Add OWASP classification as a tag/badge on Risk Cluster cards and Finding Detail pages. Start with the finding types that map cleanly: orphaned_ownership -> ASI03 (Identity & Privilege Abuse), scope_drift -> ASI10 (Rogue Agents), llm_egress -> ASI02 (Tool Misuse).

[UX9] Overview Secondary Stat Cards Compete with Hero KPIs​

  • Page: Overview
  • Problem: Below the two hero KPI cards, there are four smaller stat cards: "Active Autonomous" (5 identities), "Dormant Authority" (2 identities), "Autonomous" (7 workloads), "Operator-Assisted" (3 workloads). The tiny "Identities" and "Workloads" subtext is the only way to know what these numbers count.
  • Impact: These four cards dilute the hero message. A CISO scanning down sees: big number (769), big number (29), then four small numbers (5, 2, 7, 3) without clear context. The small numbers do not help answer "so what?"
  • Fix: Either remove these cards from the Overview (they are identity/workload inventory, not execution exposure) or collapse them into a single "Environment Summary" row that is clearly subordinate. The spec does not prescribe these cards.

[UX10] Cluster Detail Remediation Guidance: Impact Scores at 0​

  • Page: Risk Cluster Detail, Section D
  • Problem: The cluster remediation API returns actions with impact_score: 0 for some items. The path-level remediation API returns actions with scores from 0 to 10. The ImpactBar component renders these, but a 0% bar is meaningless.
  • Impact: Remediation actions that show "impact: 0" undermine trust. If the impact is unknown, say so. If it is calculated, a zero implies the action has no effect.
  • Fix: Either suppress impact_score display when the value is 0 or show "Impact not assessed" text instead of an empty bar.

Progressive Disclosure: Overview -> Cluster -> Path -> Detail​

Flow Assessment: FUNCTIONAL with friction points​

The intended flow works:

  1. Overview shows KPI cards + Top Risk Clusters -> click a cluster card
  2. Cluster Detail (Exposure Brief) shows Sections A-D + collapsible paths table -> expand table, click a path
  3. Authority Paths List (or inline expand in Cluster Detail) -> click "View Full Detail"
  4. Authority Path Detail shows graph + risk conditions + remediation + ownership + standing authority

Friction points in this flow:

  • Step 1 -> 2: Clicking a cluster card on Overview navigates to /clusters/{key} (the Exposure Brief page). This works. However, the "View all" link above the clusters section navigates to /clusters (the Clusters List page), which is an intermediate index page that adds one click. The clusters should be directly accessible from Overview without the index.

  • Step 2 -> 3: The "View Authority Paths" collapsible table in Cluster Detail works well. But clicking "View Full Detail" from the expanded row navigates to the standalone Authority Path Detail page, losing the cluster context. There is no breadcrumb trail back to the specific cluster.

  • Step 3 -> 4: Authority Path Detail has no breadcrumb to the parent cluster. A user who drilled down from Overview -> Cluster -> Path Detail can only go "back" via browser history. The breadcrumb shows Overview > authority-paths > {hash} instead of Overview > Clusters > Unowned Sensitive Access > {path name}.

  • Alternative entry: A user can also reach Authority Paths List directly from the sidebar. From there, the flow into Path Detail works. But there is no way to reverse navigate from a Path Detail page to its containing cluster(s).

Audience Separation: CISO vs Analyst​

What the spec prescribes:​

  • CISO pages: Overview, Cluster Exposure Brief -- verdict sentences, execution-determined, <5s comprehension
  • Analyst pages: Authority Path Detail -- graph, evidence, remediation targeting

Current state:​

CISO-appropriate pages (working well):

  • Overview: mostly right (see issues above)
  • Risk Cluster Detail (Exposure Brief): strong -- Sections A-D, narrative, governance checklist, remediation guidance
  • Data Domains: naturally CISO-readable

Analyst-appropriate pages (working well):

  • Authority Path Detail: strong -- graph-first, risk tiles, remediation with impact scores
  • Authority Paths List: good table with appropriate filters
  • Graph Explorer: correctly scoped

Audience leaks:

  1. Cluster Detail paths table shows analyst-level detail (via_roles, source system, finding type pills) inside what should be a CISO page. The spec says "View Authority Paths (N)" should be a button revealing the table -- this is implemented correctly. But the table, once expanded, is dense enough to lose a CISO.

  2. Findings page is accessible but has no sidebar entry and no CISO framing. It should either be an analyst sub-section or get a summary view.

  3. Exposures page tries to serve both audiences and satisfies neither. It lacks the summary narrative a CISO needs and lacks the depth an analyst wants.

Consistency Audit​

Visual consistency: GOOD​

  • Card styling (border, padding, rounded corners) is consistent across pages
  • Badge system (severity, ownership, egress, system) is shared via badges.tsx
  • Typography scale follows a consistent pattern (xs for metadata, sm for values, base/lg for headers)
  • Color semantics are consistent (red = bad, green = good, amber = warning)

Behavioral consistency: GOOD​

  • Expandable rows use the same pattern across Authority Paths List, Cluster Detail table, and Exposures table
  • Filter dropdowns are consistent via DataTableFilters component
  • Loading/error/empty states use shared components throughout

Terminology consistency: POOR (see Label Audit above)​

Layout consistency: MOSTLY GOOD​

  • All list pages follow: header + count -> filters -> table/cards
  • All detail pages follow: back link -> header card -> content sections
  • Exception: Exposure Detail uses tabs while Authority Path Detail uses vertical scroll. Both are detail pages for similar-level entities but use different navigation patterns.

What Works​

These patterns are well-executed and should be preserved and replicated:

  1. Risk Cluster Detail (Exposure Brief) Sections A-D structure. This is the single best implementation of the Clarity spec. The narrative in Section A provides instant comprehension. The Exposure Grid in Section B quantifies scale. The Governance Checklist in Section C explains why this is unstable. The Remediation Guidance in Section D gives concrete next steps. This pattern answers all three acceptance criteria: What happened? Am I exposed? What should I do?

  2. Verdict sentences on PathRiskClusterCard. The buildVerdictSentence function composes plain-English sentences from structured data: "3 autonomous identities accessed sensitive systems 681 times in the last 30 days -- none have an assigned owner." This is exactly what the spec prescribed. The data-driven sentence generation is a replicable pattern.

  3. Authority Path Detail graph-first layout. Graph dominates above the fold. Risk condition tiles with "Since Xd" create urgency. Remediation guidance with impact scoring provides actionable next steps. The standing authority panel (collapsed) correctly separates observed from potential authority.

  4. PathLabel component. Shows the full chain (workload -> identity -> destination) with source system badges inline. This compact representation works well in table rows and is reused across multiple pages.

  5. DeltaBadge security-inverted colors. Red for increase (more risk), green for decrease. This is correct for a security context and avoids the "green = growth = good" mistake common in business dashboards.

  6. Collapsible authority paths table in Cluster Detail. Progressive disclosure done right -- the narrative comes first, the table is revealed on demand. This prevents cognitive overload while keeping analyst data accessible.

  7. Finding tiles with inline drift breakdowns. The expandable finding tiles on Authority Path Detail show drift-specific details (roles added, destinations expanded, owners departed) inline without navigating away. This is well-designed progressive disclosure.

  8. Cluster descriptions from API. Cluster labels have been upgraded from attribute-based ("Orphaned + Sensitive") to functional ("Unowned Sensitive Access"). The descriptions are plain English ("Autonomous identities with no active owner accessing sensitive or restricted data domains"). This directly addresses the Clarity spec requirement.

Priority Recommendations​

1. Fix authority path role visibility -- affects CISO + analyst workflows​

Sprint blocker per Sergey's feedback. Via roles are invisible at the table level and truncated in standing authority. A path with sql_clinical_reader + sql_admin_reader shows identical table representation to one with incident_writer. Add role count or role names to the path table row. Implementation: modify PathLabel or add a "Roles" column to the authority paths table in both AuthorityPathsListPage and RiskClusterDetailPage.

2. Remove delta percentages from Overview KPI cards -- affects CISO comprehension​

Spec contradiction. The +838% execution delta dominates the Overview and contradicts the Feb 22 spec's explicit removal of trend deltas. Remove DeltaBadge from the two hero KPI cards. If delta tracking is valued, surface it in the Cluster Detail narrative where context exists.

3. Fix governance checklist deduplication -- affects CISO risk assessment​

Three different finding types (orphaned_ownership, unknown_identity_binding, ownership_drift) all map to "Orphaned identities," then get deduplicated to show only once. This hides real governance failures. Use distinct labels for each finding type in the checklist.

4. Add OWASP/business relevance tags -- affects CISO board presentations​

Deloitte feedback is clear: CISOs need framework alignment. Start by adding OWASP ASI classification badges to cluster cards and finding detail pages. The mapping already exists in the Notion specs.

5. Resolve navigation orphans -- affects all user workflows​

Exposures, Findings, Execution Chains, and Entities are all accessible pages with no sidebar entry. Either add them to the sidebar (possibly under an "Analyst" section separator) or remove their standalone routes and serve their data only within the progressive disclosure flow. The current state means users can reach pages they cannot find again.

6. Fix breadcrumbs on detail pages -- affects wayfinding​

Breadcrumbs show hash IDs and raw URL segments instead of human-readable names. For cluster detail: show cluster label. For path detail: show path chain summary. For entity detail: show entity display name. The entity batch API already provides display names -- the breadcrumb component just doesn't use them.

7. Remove or hide legacy Dashboard -- affects product coherence​

The legacy Dashboard at /dashboard uses different terminology, different hierarchy, and different metrics than the Overview. It is not in the sidebar navigation but is still routable. It should be removed or redirected to / to prevent confusion.

8. Add Findings summary strip -- affects CISO page readability​

The API already returns meta.bySeverity and meta.byType in the findings response. Render these as a severity distribution bar + type count chips above the table. This is a low-effort, high-impact rendering change.

Appendix: API Data Observations​

Data from live demo-w1 tenant queries on 2026-03-15:

  • Posture summary: 769 total executions (30d), 29 active paths, 19 executed with invalid ownership. Delta shows +838% execution increase -- this is a demo data artifact but illustrates why deltas without context are misleading.
  • Risk clusters: 6 clusters. Labels are now functional ("Unowned Sensitive Access", "LLM Data Egress", "Dormant External Access") rather than attribute-based. Verdict sentence data (action_phrase, governance_clause, identity_count) is fully populated.
  • Authority paths: 30 total, with via_roles arrays properly populated (1-2 roles per path in sample). Role IDs present for entity linking.
  • Findings: Only 6 findings returned from the API (down from 51 in March 3 review). The bySeverity breakdown is: 1 critical, 3 high, 2 medium. The byType breakdown is: 3 dormant_authority, 2 reachable_sensitive_domain, 1 scope_drift. This suggests the evaluator rules or seed data have been refined.
  • Path remediation: Returns concrete actions with impact_score, signals, and applies_to fields. Some scores are 0 (see UX10).
  • Cluster remediation endpoint: Not found (404). The UI uses a different endpoint pattern that works.