Skip to main content

Product QA Report: Full PRD-to-Implementation Gap Analysis

Overall Verdict​

The implementation has made significant progress since the 2026-03-03 review. Four of the six critical gaps identified then have been addressed (verdict sentences, dashboard title, hero metric, functional cluster names). However, two sprint-critical issues remain unfixed (missing object names in remediation, authority path collapsing), and the remediation guidance feature -- while present -- deviates from the spec in ways that undermine its usefulness for operators. The product is approaching design-partner readiness but has specific defects that would erode trust in a live CISO demo.

Summary​

  • Spec features checked: 28
  • Implemented: 17 | Partial: 8 | Missing: 2 | Diverged: 1
  • Defects found: 3 critical, 5 major, 6 minor

PRD Alignment​

#Spec FeatureStatusNotes
1Functional cluster names (not attribute-based)ImplementedCluster labels now use functional names: "Unowned Sensitive Access", "LLM Data Egress", etc. (was "Orphaned + Sensitive"). Fixed since 03-03.
2Verdict sentence on cluster cardsImplementedbuildVerdictSentence() in PathRiskClusterCard.tsx composes sentences using action_phrase + governance_clause from API. API serves these fields on all 6 clusters. Fixed since 03-03.
3Dashboard title: execution-determined framingImplementedTitle is "Observed Autonomous Execution (30d)" with subtitle "Deterministic view of autonomous activity observed across your environment." Matches spec intent. Fixed since 03-03.
4Hero tile 1: total executions (big number)ImplementedCard A shows "Observed Executions (30d)" = 769 with delta badge (+838%). Fixed since 03-03.
5Hero tile 2: active authority pathsImplementedCard B shows "Active Authority Paths" = 29 with "19 with invalid ownership" subtext.
6Identity & workload count tilesImplemented4 stat cards: Active Autonomous (5), Dormant Authority (2), Autonomous Workloads (7), Operator-Assisted (3).
7Delta badges on hero tilesImplementedDeltaBadge component renders +838% and +81% on the two hero tiles.
8Progressive disclosure: Overview -> Cluster -> Paths -> DetailImplementedNavigation flow works: cluster cards link to /clusters/:key, which shows Authority Exposure Brief with collapsible path table.
9Authority Exposure Brief (Sections A-D)ImplementedRiskClusterDetailPage.tsx renders Section A (narrative), B (exposure grid), C (governance checklist), D (remediation). Section headers use A/B/C/D lettering.
10Section A: What Happened narrativeImplementedbuildNarrative() composes: "3 autonomous identities accessed sensitive systems 681 times in the last 30 days. None have an assigned owner." Uses action_phrase + governance_clause from API.
11Section B: Am I Exposed? (5 metrics)ImplementedShows: Authority Paths (13), Executions/30d (681), Active/Dormant (13/0), Domains Exercised (customer, engineering, ...), Egress Type (external, llm). Matches spec.
12Section C: Governance Condition checklistPartialShows failing conditions (orphaned identities, scope drift, identity reuse) and not-assessed (long-lived tokens, lack of runtime telemetry). Missing: does not display drift as a count ("Scope drift present across N paths"). Shows binary pass/fail instead.
13Section D: How Do I Fix It?PartialShows both cluster-level aggregated remediation and fallback guidance bullets. Cluster remediation includes targets with links. But: applies_to field lacks specific object names -- see D1 below.
14"View Authority Paths (N)" collapsible tableImplementedButton at bottom of cluster detail, collapsed by default, shows path count. Expands to show full table. Matches spec.
15Authority Path Detail: graph firstImplementedAuthorityPathDiagram renders immediately after header, before risk conditions. Matches spec.
16"Active Governance Conditions" (renamed from "Active risk conditions")ImplementedLabel in RiskConditionsStrip is "Active Governance Conditions". Matches drift UX spec.
17Scope Drift card with drift breakdownImplementedInlineScopeDriftBreakdown shows: "Roles: 1 baseline -> 2 current (+1)", new role pills. Evidence refs include baseline_role_count, current_role_count, new_roles.
18Reachability drift card with expansion detailImplementedInlineReachabilityDriftBreakdown shows baseline destination count and new destination names.
19Ownership drift cardImplementedInlineOwnershipDriftBreakdown shows removed/disabled owner names.
20Top Risk Reducers (path-level)PartialSection present with correct title. Shows action, signals, impact bar. But: applies_to uses generic terms, not specific graph elements (see D1). Impact scores are inconsistent (0, 1, 10).
21Reducer applies_to must name specific path elementsDivergedSpec requires: "Role: sql_admin_reader", "Identity: svc-foundry-ascribe-prod". API returns: "LLM endpoint access", "egress path", "execution path". This is Sergey's flagged issue.
22Ownership section: 2-row boundary decompositionPartialShows "Automation owner" and "Runtime identity" rows. But only shows owner name or "Not assigned" -- does not show the departed owner name inline as spec requires.
23Standing Authority panel (collapsed)Implemented"Additional Standing Authority (Not Exercised)" panel, collapsed by default, fetches dormant paths for the same workload. Matches spec.
24Evidence grade indicator (A/B/C)MissingNot present anywhere in the UI. The competitive differentiator (observed vs standing vs blind spot) is invisible. Noted in 03-03 review, still not implemented.
25Scope drift card: remove intervalsPartialIntervals are still rendered in the expanded finding tile (finding.intervals.length > 0). Drift UX spec says "Remove the intervals part."
26Scope drift card: condition explanation textPartialSpec says show: "This authority path gained an additional role. The automation now executes with broader privileges than previously observed on this authority path." Current: shows deterministic_explanation from API, which is similar but uses technical language referencing entity IDs.
27Breadcrumb shows entity name instead of hashPartialformatBreadcrumbSegment() truncates hex IDs to xxxxxxxx... but does not resolve to entity display names. Still shows hash.
28Authority path collapsing: show all rolesMissingEach path in the list shows only its own via_roles. When an identity has 5 roles across 5 different paths, each path row shows 1 role. There is no UI element showing that the identity actually has 5 roles total. The expanded row shows "Via Roles" but only for that specific path. This is Sergey's flagged issue about "path shows 1 role but actually has 4 roles."

Perspective Reviews​

User Perspective​

Scanning ease: Good. The Overview page is immediately scannable with clear KPI cards, delta badges, and cluster cards. The verdict sentences on cluster cards are the biggest UX win since the last review -- they eliminate the need to mentally assemble meaning from raw counts.

Navigation: The sidebar is clean with 6 primary items. The breadcrumb shows route segments but not entity names (hash IDs appear as 0a3a4bb8...). First-time users can orient via the progressive disclosure flow.

Labels: Most labels are self-explanatory. The "Export Report" button being disabled with no tooltip explanation is confusing. The "Create ticket" button on path detail is similarly disabled but has a "Coming soon" tooltip -- this is better.

Empty states: Properly handled across all pages with helpful messages.

Pain point: The authority paths table shows paths with 1 role each, but doesn't surface that the underlying identity may have 5+ roles total. A user scanning the table would underestimate the true privilege scope.

CISO Perspective​

Executive summaries: Strong. The Overview page with "769 Observed Executions" and "29 Active Authority Paths (19 with invalid ownership)" passes the 5-second comprehension test.

Verdict sentences: Working correctly. "3 autonomous identities accessed sensitive systems 681 times in the last 30 days -- none have an assigned owner" is immediately actionable.

Organizational meaning: Good. Cluster cards show sensitive domains (customer, finance, hr) and governance clauses. The Authority Exposure Brief sections A-D provide structured answers to "What happened?", "Am I exposed?", "Why is this unstable?", "How do I fix it?"

Accountability: Weak in remediation. The "Top Risk Reducers" section says "Restrict LLM endpoint access" with applies_to: "LLM endpoint access". A CISO cannot hand this to an operator -- which LLM endpoint? Which role? Which identity? The spec requires: "Role: sql_admin_reader" or "Identity: svc-foundry-ascribe-prod".

Authority path collapsing: A CISO viewing a path showing 1 role would not realize the identity has 4 additional roles through other paths. This misrepresents the true blast radius.

Analyst Perspective​

Data richness: Good for findings. Each finding tile shows severity, status, "Since Xd", deterministic explanation, drift breakdown (scope drift shows baseline/current role counts, new roles), and link to finding detail.

Investigation depth: The AuthorityPathDiagram provides visual flow (workload -> identity -> destination -> data_domain). The node click opens a drawer with entity details. The standing authority panel shows dormant paths.

Dead ends: The path remediation applies_to field does not link to specific entities. An analyst cannot click through from "execution path" to the actual graph node. The evidence field in remediation actions contains finding_id and entity_id but these are not rendered as links.

Provenance: Finding tiles show detected_at and link to finding detail. Evidence pack IDs are present in the API response but not surfaced in the remediation UI.

Correctness Perspective​

Claims vs evidence: The verdict sentence "3 autonomous identities accessed sensitive systems 681 times" is supported by the API data (identity_count: 3, total_execution_30d: 681). Checked: correct.

Impact score inconsistency: Path remediation for 0a3a4bb8... returns impact scores of 0, 1, and 10 across 3 actions. The "Restrict LLM endpoint access" action has impact_score=0 (lowest possible) despite being the highest-risk action. This makes the impact ranking misleading.

Governance condition checklist accuracy: The GovernanceChecklist component maps reachability_drift to "Scope drift" and ownership_drift to "Orphaned identities" -- these are incorrect labels. Reachability drift is not scope drift. Ownership drift is not the same as orphaned identities.

Cluster-level finding types vs path-level: The cluster meta says finding_types: ["orphaned_ownership", "reachable_sensitive_domain"] but individual paths within the cluster also have scope_drift, llm_egress, reachability_drift, ownership_drift. The code correctly uses observedFindingTypes (from paths) for the governance checklist, not the cluster-level types. This is correct behavior.

Number accuracy: posture summary says active_paths: 29, authority paths list returns 30 total (including 1 removed). Cluster path counts sum to 49 (13+9+4+17+4+2) which exceeds 29 because paths can belong to multiple clusters. This is expected but not explained in the UI.

Evidence Integrity Review​

Claims Stronger Than Evidence​

  1. Remediation "Reduce execution paths to least-privilege scope" -- This is generic advice, not a specific reducer. The spec says: "Generic advice is not allowed. Reducers must target specific nodes or edges on the authority path graph."

  2. "Implement data loss prevention controls on the egress path" -- This recommends adding infrastructure (DLP) that doesn't exist. The spec says reducers should be "operator actions" tied to "structural changes operators can perform in the source system."

  3. Impact scores -- The ImpactBar component renders impact_score 0 as an empty bar, making "Restrict LLM endpoint access" appear to have zero impact. This is a correctness issue in the ranking algorithm.

Inference Presented as Fact​

  1. Ownership section: "Service principal owner departed" is shown as a dash-separated suffix on "Not assigned". This is correct when owner_descriptions includes "(deleted)" but the UI hardcodes "Service principal owner departed" regardless of the actual reason.

  2. Identity binding: The IdentityBindingCard hardcodes "OIDC (Federated)" as the protocol when an identity exists. This may not be accurate for all identity types (e.g., ServiceNow integration users use client credentials, not OIDC).

Defect List​

[D1] Remediation applies_to uses generic terms instead of specific object names -- CRITICAL​

  • Category: PRD mismatch
  • Location: ui/src/pages/AuthorityPathDetailPage.tsx:509-518 (RemediationGuidance component) and backend remediation generator
  • Problem: The spec (Actionability and remediation guidance W1) requires each reducer to include an applies_to field targeting specific path elements: "Role: sql_admin_reader", "Identity: svc-foundry-ascribe-prod", "Connection: Billing_Payment_Methods", "Endpoint: external LLM". The live API returns: "LLM endpoint access", "egress path", "execution path", "execution path destinations". These are category labels, not specific objects.
  • API evidence:
    • Path 0a3a4bb8 remediation: applies_to: "LLM endpoint access" -- should be "Endpoint: Billing_Payment_Methods (LLM)"
    • Path 3831f7f6 remediation: applies_to: "execution path" -- should be "Role: ap_write, ar_write"
  • Why it matters: This is exactly the issue Sergey flagged in his March 13 email: "we added auth paths, but also need the object name specifically." Without specific object names, an operator cannot act on the guidance. This undermines the product's "prescriptive remediation" promise.
  • Recommended fix: Update the backend remediation generator (src/evaluator/ or src/evidence/) to resolve entity/role/destination names from the authority path graph and populate applies_to with the format: {element_type}: {display_name}. The UI already renders action.applies_to -- no UI change needed.

[D2] Authority path collapsing hides total role count -- CRITICAL​

  • Category: PRD mismatch / data accuracy
  • Location: ui/src/pages/AuthorityPathsListPage.tsx (expanded row) and ui/src/pages/RiskClusterDetailPage.tsx (path table)
  • Problem: When identity svc-foundry-agent701 has 5 different authority paths, each with a different role (foundry_ai_executor, incident_creator, incident_writer, provisioner_agent_executor, AzureFunction.Invoke), each path row shows only 1 role. The expanded row "Via Roles" section only shows that path's roles. There is no indication that the identity has 5 roles total across all its paths. A user seeing "1 role" per row would not realize the true privilege scope.
  • API evidence: svc-foundry-agent701 appears in 5 paths with 5 unique roles. Each path's via_roles array contains only 1 entry.
  • Why it matters: This is Sergey's flagged issue about "collapsing authority paths -- path shows 1 role but actually has 4 roles." A CISO evaluating blast radius would systematically underestimate the privilege scope of each identity.
  • Recommended fix: Add an "Identity Total Roles" indicator to the authority path table row or expanded section. Options: (a) Show total role count as a badge on the identity name: "svc-foundry-agent701 (5 roles across 5 paths)". (b) Add a "See all roles for this identity" link in the expanded row. The data is available -- the API returns all paths, and roles can be aggregated client-side by grouping on identity.id.

[D3] Remediation impact scores are inverted/inconsistent -- CRITICAL​

  • Category: Correctness
  • Location: Backend remediation generator (API response), visualized in ui/src/pages/AuthorityPathDetailPage.tsx:471-483 (ImpactBar)
  • Problem: Path 0a3a4bb8 remediation returns: "Restrict LLM endpoint access" with impact_score: 0, "Implement DLP controls" with impact_score: 1, "Reduce execution paths to least-privilege" with impact_score: 10. The highest-impact action (restrict LLM) has score 0, while the most generic action (reduce scope) has score 10. This inverts the intended ranking.
  • Why it matters: The spec says "Reducers are ranked by expected reduction in authority exposure." An impact_score of 0 renders as an empty bar in the ImpactBar component, making the most important action appear to have zero impact. This erodes user trust in the guidance system.
  • Recommended fix: Audit the impact scoring algorithm in the backend. The "Restrict LLM endpoint access" action should have the highest impact score since it eliminates the exfiltration vector. Ensure scores are calibrated: 8-10 for actions that remove access to reachable systems, 5-7 for privilege reduction, 3-5 for governance improvements.

[D4] Governance condition labels incorrectly map finding types -- MAJOR​

  • Category: Correctness / terminology
  • Location: ui/src/pages/RiskClusterDetailPage.tsx:119-169 (GovernanceChecklist)
  • Problem: The mapping conflates different finding types:
    • reachability_drift is mapped to label "Scope drift" (line 145) -- but reachability drift and scope drift are distinct concepts per the drift intelligence spec
    • ownership_drift is mapped to label "Orphaned identities" (line 150) -- but ownership drift (owner departed/disabled) is a governance change event, not the same as orphaned_ownership
    • unknown_identity_binding is mapped to label "Orphaned identities" (line 141) -- unbound identities are not orphaned
  • Why it matters: CISOs would see "Orphaned identities" when the actual condition is "Ownership decay" or "Unbound identity binding." This misrepresents the governance state.
  • Recommended fix: Use distinct labels for each condition: reachability_drift -> "Reachability expansion", ownership_drift -> "Ownership decay", unknown_identity_binding -> "Unbound identity". These labels already exist in the authority path detail's RISK_TILE_LABELS map -- reuse them.

[D5] Finding intervals still rendered despite drift UX spec removal -- MAJOR​

  • Category: PRD mismatch
  • Location: ui/src/pages/AuthorityPathDetailPage.tsx:360-380 (FindingTile expanded view)
  • Problem: The drift UX spec explicitly states: "Remove the 'intervals' part." The expanded finding tile still renders intervals when finding.intervals.length > 0, showing date ranges like "3/10/2026 -> now".
  • Why it matters: Intervals add cognitive load without adding value. The drift spec replaced intervals with structured drift breakdown (baseline -> current role count, new roles, detected date). The drift breakdown IS implemented, but intervals appear alongside it, creating redundancy.
  • Recommended fix: Remove the intervals rendering block (lines 360-380) from FindingTile. Keep only the drift breakdown components (InlineScopeDriftBreakdown, InlineReachabilityDriftBreakdown, InlineOwnershipDriftBreakdown).

[D6] Evidence grade indicator (A/B/C) not implemented -- MAJOR​

  • Category: Missing feature
  • Location: Not present anywhere in UI
  • Problem: The execution evidence feasibility study and CISO readability review both call for visible evidence grades: Grade A (confirmed execution), Grade B (inferred execution), Grade C (standing authority only). This is described as the platform's competitive differentiator. No UI element renders evidence grades.
  • Why it matters: The platform's core positioning is "we show what DID execute, not what COULD." Without visible grades, users cannot distinguish between observed execution and standing authority, undermining the key differentiator.
  • Recommended fix: Add evidence grade badges to: (a) authority path table rows, (b) authority path detail header, (c) cluster card summaries. The data foundation exists -- execution_30d > 0 = Grade A, execution_30d == 0 && status == "active" = Grade C. Grade B requires the execution evidence materializer.

[D7] Ownership section hardcodes "Service principal owner departed" -- MAJOR​

  • Category: Correctness
  • Location: ui/src/pages/AuthorityPathDetailPage.tsx:584-586
  • Problem: When ownership is invalid and no identity owner is found, the code renders: "Not assigned" + "Service principal owner departed". This reason text is hardcoded regardless of the actual owner status. The API finding for path 0a3a4bb8 shows owner_descriptions: ["Maria Lopez (deleted)"] -- the code should use this specific information.
  • Why it matters: An operator seeing "Service principal owner departed" when the actual issue is "Maria Lopez (deleted)" loses the specific accountability trail needed for remediation.
  • Recommended fix: Read owner_descriptions from the orphaned_ownership finding's evidence_refs and render the actual departed owner name: "Maria Lopez (departed)" instead of generic text.

[D8] Breadcrumb still shows truncated hash IDs instead of entity names -- MAJOR​

  • Category: UX / PRD mismatch
  • Location: ui/src/components/Layout.tsx:59-64 (formatBreadcrumbSegment)
  • Problem: The breadcrumb for /authority-paths/0a3a4bb896821dc3813c9608 shows "0a3a4bb8..." instead of the entity/path display name. The 2026-03-03 review flagged this as a trivial fix.
  • Why it matters: Hash IDs in breadcrumbs make navigation feel developer-oriented, not CISO-oriented. Every other element on the page uses human-readable names.
  • Recommended fix: For authority path routes, fetch and display the path label (workload -> destination) in the breadcrumb. This requires passing route context or using the already-fetched data from the detail query.

[D9] Remediation guidance includes non-operator advice -- MINOR​

  • Category: PRD mismatch
  • Location: Backend remediation generator
  • Problem: The spec says: "Reducers correspond to structural changes operators can perform in the source system." The live API returns "Implement data loss prevention controls on the egress path" which recommends adding new infrastructure rather than making a structural change in the existing source system.
  • Why it matters: DLP implementation is a multi-week project, not an operator action. Mixing project-scale recommendations with quick structural fixes (like removing a role) dilutes the actionability.
  • Recommended fix: Ensure all remediation actions map to source system operations: remove role, reassign owner, restrict scope, disable credential, etc. Filter out infrastructure recommendations.

[D10] Identity binding card hardcodes "OIDC (Federated)" protocol -- MINOR​

  • Category: Correctness
  • Location: ui/src/pages/AuthorityPathDetailPage.tsx:621
  • Problem: The IdentityBindingCard renders "OIDC (Federated)" as the protocol whenever an identity exists. ServiceNow integration users authenticate via client credentials, not OIDC. The actual auth mechanism is not stored in the authority path data model.
  • Why it matters: An analyst verifying the identity binding would see incorrect protocol information, eroding trust in the evidence.
  • Recommended fix: Source the protocol from the identity entity's properties (e.g., auth_type or credential_state). If not available, show "Client credentials" or "Unknown" instead of hardcoding OIDC.

[D11] Scope drift condition text uses API-generated explanation instead of spec template -- MINOR​

  • Category: PRD deviation
  • Location: ui/src/pages/AuthorityPathDetailPage.tsx:336-339 (FindingTile)
  • Problem: The drift UX spec requires a specific condition text: "This authority path gained an additional role. The automation now executes with broader privileges than previously observed on this authority path." The UI shows finding.deterministic_explanation from the API, which reads: "Authority path from workload 'Agent Ascribe_Summarizer' to '5040e08461239710995a9ebe' gained 'sql_clinical_reader' (1 -> 2 roles) since baseline..."
  • Why it matters: The API-generated text includes entity IDs and technical language. The spec template is more CISO-friendly.
  • Recommended fix: For drift finding types, render the spec-prescribed template text as the primary condition, with the API deterministic_explanation available on expansion. The structured drift breakdown components already provide the specific evidence.

[D12] Cluster Section C does not show drift path counts -- MINOR​

  • Category: PRD mismatch
  • Location: ui/src/pages/RiskClusterDetailPage.tsx:119-186 (GovernanceChecklist)
  • Problem: The drift UX spec for cluster-level says: "It only displays the presence of drift as a governance driver (e.g., 'Scope drift present across 3 authority paths')." The current UI shows a binary icon (warning triangle or minus circle) with a label. No path count is shown.
  • Why it matters: "Scope drift present" is less informative than "Scope drift present across 3 authority paths" -- the count conveys scale.
  • Recommended fix: Count the number of paths in the cluster that have each drift finding type and display: "Scope drift (3 paths)", "Ownership decay (5 paths)".

[D13] Nav items missing Execution Chains and Exposures pages -- MINOR​

  • Category: UX gap
  • Location: ui/src/components/Layout.tsx:33-40 (NAV_ITEMS)
  • Problem: The sidebar only shows 6 items: Overview, Risk Clusters, Authority Paths, Identities, Data Domains, Graph Explorer. The Execution Chains and Exposures pages exist in the router but are not in the primary navigation. They can only be reached via direct URL.
  • Why it matters: These pages contain analyst-relevant data that is unreachable through normal navigation.
  • Recommended fix: Consider adding these as secondary nav items (perhaps in a collapsible "Analyst" section) or as links from the Overview page.

[D14] Findings list still shows hash IDs in descriptions -- MINOR​

  • Category: UX
  • Location: ui/src/pages/FindingsList.tsx:96-103
  • Problem: Finding descriptions show entity IDs (hex hashes) in the deterministic_explanation text, e.g., "reaches '5040e08461239710995a9ebe'". The entity_name field is used for the Workload column (good), but descriptions still contain raw IDs.
  • Why it matters: Flagged in 03-03 review. Production use with hundreds of findings would make this page unusable for CISOs.
  • Recommended fix: Pre-process deterministic_explanation to replace entity IDs with display names. The backend already has access to entity names during evaluation -- embed them in the explanation text at generation time.

Suggested Improvements​

  1. Role aggregation badge on authority path rows: When expanding a path row, show "Identity total: 5 roles across 5 paths" with a link to filter by that identity. This directly addresses the "collapsing" concern.

  2. Remediation applies_to enrichment: The backend remediation generator should resolve entity IDs to display names. Transform applies_to: "execution path" into applies_to: "Role: sql_admin_reader on Identity: svc-foundry-ascribe-prod". The spec examples are explicit about this.

  3. Evidence grade badges: Start with a simple badge (A/B/C) derived from execution_30d > 0 vs dormant. Display on path table rows and path detail headers. This is the highest-impact differentiator.

  4. Cluster governance condition counts: Transform "Scope drift" into "Scope drift (3 paths)" by counting finding occurrences across cluster paths.

  5. Findings table improvements: Add a "Workload" column (already present), group by finding type, add a summary chart at top. Replace hash IDs in descriptions with entity names.

Verified Complete​

These features fully match spec and should be preserved:

  1. Functional cluster names -- "Unowned Sensitive Access", "LLM Data Egress", "Unbound Sensitive Access", "Unowned External Egress", "Dormant External Access"
  2. Verdict sentences on cluster cards -- Composable, execution-determined, uses API-served action_phrase + governance_clause
  3. Dashboard title and subtitle -- "Observed Autonomous Execution (30d)" with deterministic framing
  4. Hero tiles: execution count + active paths -- Big numbers with delta badges
  5. Authority Exposure Brief sections A-D -- Structured narrative, exposure grid, governance checklist, remediation guidance
  6. Authority Path Detail: graph first -- Diagram is the primary visual surface, above risk conditions
  7. Active Governance Conditions label -- Renamed from "Active risk conditions" per drift UX spec
  8. Drift breakdown components -- Scope drift, reachability drift, ownership drift all have inline breakdowns with specific evidence
  9. Standing Authority panel -- Collapsed by default, shows dormant paths for the same workload
  10. Top Risk Reducers section -- Present on both path detail and cluster detail
  11. Collapsible path table in cluster detail -- "View Authority Paths (N)" button with expand/collapse
  12. Cluster-level remediation aggregation -- Cluster remediation shows targets with identity names and links to specific paths
  13. Navigation sidebar -- "SecurityV0" branding (not "SV0 Platform"), "Risk Clusters" label
  14. Progressive disclosure flow -- Overview -> Cluster Detail -> Path Table -> Path Detail
  15. Ownership section: 2-row layout -- Automation owner + Runtime identity
  16. Identity binding card -- Relationship, Protocol, Target system
  17. Authority state card -- Execution model, Auth type, Human session required

2026-03-03 CISO Readability Review: Gap Status​

GapStatusDetail
1. Missing verdict sentences on cluster cardsFIXEDbuildVerdictSentence() in PathRiskClusterCard.tsx composes sentences from action_phrase + governance_clause
2. Missing evidence grades (A/B/C)NOT FIXEDStill not present anywhere in the UI
3. Dashboard title framingFIXEDChanged to "Observed Autonomous Execution (30d)"
4. Hero metric: execution count not path countFIXEDCard A now shows "Observed Executions (30d)" = 769
5. Missing trend deltas on hero metricsFIXEDDeltaBadge renders +838% and +81%
6. Ownership decomposition by boundaryPARTIALLY FIXEDShows 2 rows (Automation owner, Runtime identity) but does not decompose to 3 boundaries (automation owner, SP owner, app registration owner)
7. Hash IDs in breadcrumbsNOT FIXEDStill shows truncated hex hashes

Release Readiness​

  • Not ready
  • Ready for internal demo
  • Ready for design partner demo
  • Ready for broader pilot

Justification: The platform is functionally solid and most spec features are implemented. However, three issues prevent design partner readiness:

  1. Remediation applies_to missing object names (D1) -- A CISO demo would expose that remediation guidance doesn't tell the operator which specific object to change. This would undermine the "prescriptive" positioning.

  2. Authority path collapsing (D2) -- A demo with a security-savvy audience would reveal that the role count per path underrepresents the true privilege scope. This would be caught immediately.

  3. Impact score inversion (D3) -- The most important action showing impact=0 would be noticed and would erode trust in the guidance system.

Fixing D1, D2, and D3 would move the product to "Ready for design partner demo." Evidence grades (D6) and breadcrumb names (D8) can follow as polish items.