Skip to main content

SecOps Analyst Review — Round 2: W1 Demo (demo-w1 tenant)

Verdict: NEEDS WORK​

Score: 74% (up from 70% Round 1). Direction is positive but not yet at the 80% acceptance target.

The platform has made measurable progress since Round 1. The sidebar navigation is cleaner — Identities, Data Domains, and Graph Explorer are now first-class citizens in the left nav. The cluster detail pages render well with named entities in path tables, data domain badges, and egress/ownership tags. The new Execution Chains page and the Data Domains page are strong additions that did not exist (or were not visible) at Round 1. However, the three Round 1 blockers — no "what changed" filter, generic remediation on some finding types, and empty execution evidence target_resource — remain unresolved. Two new issues surfaced: a broken cluster page (scope_drift_sensitive shows "Risk cluster is disabled") and an exposure detail page returning "Entity not found." These regressions partially offset the navigation and data model improvements.

First Impression (60-second test)​

What I understood immediately:

  • The Overview page is the same structure as Round 1: "Observed Autonomous Execution (30d)" header, 769 total executions, 29 active authority paths. The stat cards show 5 Active Autonomy, 2 Suspended, 7 Authority Paths, 3 (possibly another metric). The four Top Risk Clusters are visible below: Orphaned + Sensitive (13 paths), Orphaned + Sensitive + LLM (9 paths), Unbound + Sensitive (4 paths), LLM Egress (17 paths).
  • The sidebar now has a cleaner structure: Overview, Risk Clusters, Authority Paths, Identities, Data Domains, Graph Explorer. The previous "Findings" / "Exposures" / "Chains" / "Syncs" / "Temporal" pages are still accessible via breadcrumb navigation but are no longer top-level sidebar items. This is a mixed change — it reduces clutter but makes Findings harder to reach.
  • The Risk Clusters page lists 7 clusters: Orphaned + Sensitive (13 paths), Orphaned + Sensitive + LLM (9 paths), Unbound + Sensitive (4 paths), LLM Egress (17 paths), Orphaned + External Egress (4 paths), Dormant + External (2 paths), and Scope Drift + Sensitive (not loadable). This is up from 6 clusters in Round 1.

What confused me:

  • The Overview still shows percentage deltas without baseline context. I see "769 TOTAL" executions but no period comparison explanation. The Round 1 concern about 838% delta without a reference period remains.
  • The breadcrumb on the cluster detail pages still shows the cluster slug (e.g., "orphaned_sensitive") rather than the display name "Orphaned + Sensitive." This was flagged in Round 1 and is planned in Phase 2.3 but not yet fixed.
  • The scope_drift_sensitive cluster returns a red error banner: "Risk cluster is disabled: scope_drift_sensitive" with a Retry button. This is a regression — in Round 1, scope_drift was one of the strongest finding types with concrete remediation. A broken cluster page is a demo-blocking bug.
  • The exposure detail page for EXP-322c2c81 shows "Entity not found" with a red error banner. This is a dead end — clicking into an exposure from the Exposures list leads nowhere. Another regression.

What I'd click first:

  • Same as Round 1: the "Orphaned + Sensitive" cluster (critical, 13 paths). The visual hierarchy on Overview correctly makes this the obvious starting point.

Actionability Assessment​

  • Finding clarity: CLEAR (unchanged)

    • The finding detail page for "Dormant Authority" (eval:05d2c303...) shows a clear explanation: "Authority path from workload 'Compliance Audit Exporter' to '811083c85861f79d0f25d96b' has been active for 120 days but shows 0 executions in the last 30 days (threshold: 90 days)." The type, severity (high), status (active), and source (evaluator) are all visible as colored badges.
    • However, the finding description still contains a raw hex ID ("811083c85861f79d0f25d96b") instead of the entity display name. This was flagged in the action plan as Phase 2.4 but is not yet fixed. An analyst reading this finding cannot tell what "811083c85861f79d0f25d96b" refers to without opening another page.
    • The finding detail page now has "Acknowledge" and "Mark False Positive" buttons. This is new since Round 1 and addresses the workflow gap around finding triage actions. Good addition.

  • Remediation specificity: IMPROVED but still MIXED

    • The authority path detail page (path-active-detail) now shows a "Top Risk Reducers" section with prioritized remediation actions. I can see 5 actions listed in order:
      1. "Assign owner and revoke/re-evaluate expanded scope" — with a named entity reference
      2. "Remove role granting LLM endpoint access" — with a named entity reference (Scope drift / LLM scope)
      3. "Assign owner and restrict LLM egress" — with entity reference
      4. "Restrict scope to sanctioned authority only" — with a named entity (Scope drift)
      5. "Assign a valid owner to this workload" — with entity reference (Invalid owner)
    • The remediation actions now include named entities in the "applies_to" context visible alongside each action. This is a concrete improvement from Round 1 where some remediations lacked entity context.
    • Still missing: System-specific instructions. "Remove role granting LLM endpoint access" is better than "Restrict LLM endpoint access" (Round 1), but it still does not say "In Entra ID > Enterprise Applications > svc-foundry-ascribe-prod > App roles, remove 'ai_clinical_reader'." The action plan's Phase 0.1 requirement — remediation must name specific objects — is partially addressed (entities are named) but the "where to go and what to click" gap persists.

  • Ticket-ready: PARTIAL (unchanged)

    • The finding detail now has "Acknowledge" and "Mark False Positive" workflow buttons, which is progress.
    • The "Create Ticket" button status is not visible in the current screenshots, but based on the action plan (Phase 5.2), it remains disabled/unimplemented.
    • I could copy the finding explanation into a ticket, but I'd need to manually resolve the hex ID, look up the system-specific remediation steps, and identify the Entra ID object. That is 10-15 minutes of manual work per finding.

  • Engineer handoff quality: NEEDS CONTEXT (unchanged)

    • The Ownership section on the path detail page now shows named owners: "Maria Lopez" as the named owner with status visible (appears as "Not assigned" for the current state). The "Automation model" and "Identity binding" sections show the identity source (RUNS_AS), protocol (OIDC/Federated), and source system (Foundry). This is richer context than Round 1.
    • The entity detail page (entity-detail.png) shows a Permission entity ("Incident Write") with clear metadata: type (Permission), source (ServiceNow), normalized action (write), scope (incident). This is useful for an engineer who needs to understand what the permission does.
    • Still missing: Entra ID object IDs, deep links to source admin consoles, and blast radius of the specific fix (not just the entity's current reach).

Validation Workflow​

  • Evidence chain: PARTIAL (unchanged)

    • Identity to Permissions: YES. The authority path visualization on path-active-detail clearly shows Agent Ascribe_Summarizer -> svc-foundry-ascribe-prod -> Billing_Payment_Methods with "via roles: rai_clinical_reader, rai_admin_reader" displayed on the path edges. The visual rendering of the path as a horizontal flow diagram with colored nodes (workload = blue, identity = green/teal, resource = red/coral) and labeled edges is a genuine improvement in readability.
    • Permissions to Execution: PARTIAL. The path row in the cluster detail table shows "Exec 30d" counts (e.g., 127, 119, 110, 117) and "Last Exec" timestamps. However, the underlying execution evidence target_resource issue from Round 1 is still listed as Phase 3.3 in the action plan — not yet fixed.
    • The Evidence Completeness section on the finding detail page shows "Current Roles: N/A" and "Role History: N/A" for the Dormant Authority finding. This is honest about data gaps but it means evidence validation for this specific finding type is incomplete.

  • Manual verification possible: PARTIAL (unchanged)

    • The entity detail pages now show more metadata (source system, normalized action, scope), but the entity detail breadcrumb still shows truncated hex IDs (e.g., "01c9ad87...") instead of the entity name. An analyst navigating to an entity from a finding would see the hex ID in the breadcrumb and URL, which makes cross-referencing with source systems harder.
    • The Identities page is a strong addition — it lists all 10 identities with Name, Type, Source (ServiceNow/Entra colored badges), Status, Sensitive Domains (colored tags like "engineering," "identity," "it_operations"), and Last Updated. This table alone gives me enough to cross-reference with Entra ID.

  • False positive distinguishable: YES (unchanged)

    • The "Mark False Positive" button on the finding detail page is new. This is a concrete workflow improvement — I can now flag false positives without external tools.

Remediation Safety​

  • Fix specificity: IMPROVED but still MIXED

    • The "Top Risk Reducers" section on the path detail page is a significant addition. Actions are prioritized and each references named entities. The tiered urgency labels on the finding detail page (Immediate / Short-term / Ongoing) are well-designed: "Immediate: Revoke unused execution paths", "Short-term: Disable identity if no longer needed", "Ongoing: Rotate credentials associated with this identity." This graduated approach is exactly what an analyst needs.
    • The Dormant Authority finding's "Recommended Actions" section is structured well: "dormant standing authority: dormant workload with 2 execution path(s) reaching 1 sensitive domain(s)" followed by three tiered actions. This is actionable.
    • Still weak: Generic remediations for some types persist. "Restrict scope to sanctioned authority only" does not name the specific scope to restrict.

  • Blast radius of fix explained: PARTIAL (unchanged)

    • The Data Domains page is a strong new visual. It shows 7 domains (Finance: 4 resources/restricted, Customer: 8 resources/restricted, HR: 3 resources/restricted, IT Operations: 5 resources/confidential, Engineering: 2 resources/confidential, Security: 3 resources/confidential, Identity: 2 resources/confidential) with resource names listed in each card. This tells me the blast radius of the environment at a glance.
    • Within the authority path detail, the risk conditions show badges for "Scope drift," "Invalid owner," "Sensitive data domain," "LLM egress." These badges communicate which risk factors are active.
    • Still missing: "If I remove this role, what breaks?" analysis. The blast radius shows what the workload can currently reach, not what happens when I change it.

  • Would execute in production: WITH CAVEATS (unchanged)

    • For Dormant Authority with "Revoke unused execution paths" at Immediate priority: yes, I'd revoke.
    • For orphaned ownership with "Assign a valid owner": yes, with the named departed owner visible.
    • For scope drift with named roles and Top Risk Reducers giving me the specific action: yes, with verification.
    • For LLM egress without system-specific instructions: no, still too vague.

Closure & Drift​

  • Post-remediation verification: AVAILABLE (structurally, unchanged)

    • Finding statuses exist (active is visible on finding detail). The "Acknowledge" button suggests status transitions are now functional.
    • The Sync History page shows 3 completed syncs (entra_servicenow connector, 3/2/2026) with entity and event counts. This tells me the pipeline is functional but the data is 16+ days old. In production, I'd want to see recent syncs to trust closure verification.

  • Drift detection: REGRESSION

    • The scope_drift_sensitive cluster returns "Risk cluster is disabled" — meaning I cannot view the very cluster type that demonstrates drift detection. In Round 1, scope drift was the strongest finding type. This is a regression that directly impacts the drift detection assessment.
    • Other cluster types (orphaned, unbound, LLM egress, dormant) load correctly.

  • Closure demonstration: CAN PROVE (unchanged, structurally)

    • The "Acknowledge" and "Mark False Positive" buttons on the finding detail page add triage state tracking that did not exist in Round 1. This is a step toward demonstrating closure.

Triage Workflow​

  • Steps to find critical findings: 1 click (Overview page surfaces top clusters immediately)

    • The Overview -> cluster card -> cluster detail workflow is unchanged and still effective.

  • Clicks from dashboard to actionable context: 3 (unchanged)

    • Overview -> Cluster Detail -> Authority Path Detail. The path detail page now has the "Top Risk Reducers" section, which means I reach actionable remediation in exactly 3 clicks. This is good.

  • Filter/sort to my area: PARTIAL (improved)

    • The Authority Paths page now has filter tabs: "Active", "All ownership", "All Statuses." This is new. I can filter paths by status and ownership validity.
    • The Findings page shows severity, type, workload, and description filters. I can see dropdown filters for "All severities," "All types," "All statuses," "All sources." This is an improvement.
    • The Exposures page has an "All severities" filter dropdown.
    • The Execution Chains page has filters for egress type and ownership status ("All egress," "All ownership").
    • Still missing: No team/domain/responsibility-area filter. I cannot filter to "show me only findings that affect the HR domain" or "show me findings owned by my team." This was flagged as Gap #5 in Round 1 and remains unaddressed.

  • "What's new since yesterday": MISSING (unchanged, still the #1 blocker)

    • No ?changed_since= filter visible anywhere. No "New since last visit" section on Overview. The action plan lists this as Phase 1.7 with medium effort. Still not implemented.
    • This remains the single biggest blocker for daily operational use. Without it, I open the tool every morning and have to remember where I left off.

Investigation Quality​

  • Authority path trace: COMPLETE (improved)

    • The authority path detail pages render a clear horizontal flow diagram: Agent Ascribe_Summarizer (workload, blue) -> svc-foundry-ascribe-prod (identity, teal) -> Billing_Payment_Methods (resource, coral). The via_roles are displayed as labels on the edges. The data domain (shown as a terminal node or badge) indicates sensitivity classification.
    • A second path detail (authority-path-detail.png) shows AI Assist Flow (workload) -> OpenAI API Gateway (connection) -> it_operations (domain). This demonstrates cross-system path rendering.
    • The "Active risk conditions" section below the path diagram shows badge-style indicators: Scope drift (with count), Invalid owner, Sensitive data domain, LLM egress, and also "Unknown identity" where applicable. This is a clear at-a-glance risk summary.

  • Blast radius clarity: IMPROVED

    • The Data Domains page provides a domain-level blast radius view with 27 total resources across 7 domains, each showing sensitivity classification (restricted/confidential) and resource names.
    • The Execution Chains page shows chain-level blast radius: entity counts (5-16 per chain), sensitive domains, and max sensitivity. The "Compliance Audit Exporter" chain, for example, shows 7 entities across the security domain at confidential sensitivity.
    • The chain detail page (chain-detail.png) lists all chain entities with their types, roles, and names — including Compliance Audit Exporter, svc-audit-export, Audit Log Reader, Audit Trail Store, SIEM Feed. This is full entity decomposition for blast radius analysis.

  • Temporal comparison: PARTIAL (unchanged)

    • The Temporal Comparison page exists but shows only a search box ("Search for an entity...") with no pre-populated content. An analyst would not know what to search for or what to expect. This page needs a guided starting point.
    • Scope drift evidence in the path detail still shows baseline vs. current comparison badges, but the dedicated temporal view adds no value in its current state.

  • Cross-reference navigation: MOSTLY LINKED (regression in some areas)

    • Cluster -> path table rows -> authority path detail: WORKS. Each row in the cluster detail table is clickable.
    • Authority path detail -> entity detail: WORKS. The entity detail page (entity-detail.png) renders correctly with tabs for Properties, Graph, Timeline, Ownership, Findings.
    • Exposure list -> exposure detail: BROKEN. The exposure detail for EXP-322c2c81 returns "Entity not found." This is a dead end.
    • Finding list -> finding detail: WORKS. The finding detail for the Dormant Authority finding renders correctly with explanation, recommended actions, and evidence completeness.
    • The Graph Explorer page shows a visual graph with entity nodes (color-coded by type: Workload, Identity, Role, Permission, Resource, Connection, Execution Evidence) and filter controls. This is a powerful investigation tool, though the graph is dense and would benefit from zoom/focus capabilities.

Reporting Capability​

  • CISO summary producible: PARTIAL (unchanged)

    • The Overview page provides top-level stats and risk cluster cards suitable for a CISO summary.
    • The cluster narrative sentences on the clusters page are readable: "13 autonomous paths exercised customer/finance/hr/identity/it_operations accessed authority and invoked endpoints 681 times in the last 30 days — all under orphaned ownership."
    • Still missing: No export functionality visible. No "Export Report" button observed in the current screenshots.

  • Trend views: MISSING (unchanged)

    • No time-series charts or trend data visible. The Overview does not show period-over-period comparison in a visual format.
    • The action plan defers this to Phase 5.5 (Posture Trend Chart).

  • Export: MISSING (unchanged)

    • No export buttons visible in the screenshots. The Report Service is planned for Phase 4 (next sprint).

Partner / Services Delivery​

  • Repeatable assessment workflow: PARTIAL

    • The navigation flow (Overview -> Clusters -> Path Detail -> Finding Detail) is a coherent assessment path. A partner could walk through this in a demo or client meeting.
    • The Execution Chains page provides chain-level analysis useful for partner assessments — it groups related entities and shows cross-system relationships.
    • The Data Domains page is excellent for partner presentations — it shows which sensitive domains are reachable with resource names and sensitivity classifications. This is immediately understandable by a client's CISO.
    • Regression risk: The broken scope_drift_sensitive cluster and the exposure detail "Entity not found" error would embarrass a partner in a live demo. These must be fixed before any client-facing use.

  • Terminology for client-facing reports: IMPROVED

    • The cluster names are functional and readable: "Orphaned + Sensitive," "LLM Egress," "Dormant + External." These pass the "can I explain this to a customer's app owner" test.
    • The tiered remediation labels (Immediate / Short-term / Ongoing) on finding detail are professional and client-appropriate.
    • Still problematic: "Authority path" is still the primary term. The action plan notes Sergey's question about whether this is immediately understood by SIs and CISOs (Pending Decision #2). For partner delivery, "access path" or "execution path" would be more intuitive.

  • Findings as deliverables: NOT YET

    • Without export, findings cannot be turned into deliverable documents. The evidence pack markdown renderer exists in the backend but is not surfaced in the UI.

Delta vs Round 1​

AreaRound 1Round 2Change
Sidebar navigationBasic (listed all pages)Cleaner hierarchy (6 items)Improved
Identities pageNot visible in reviewFull table with 10 identities, sources, domainsNew
Data Domains pageNot visible in review7 domains, 27 resources, sensitivity badgesNew
Execution Chains pageNot visible6 chains with entity counts and filtersNew
Graph ExplorerNot visibleFull graph visualization with filtersNew
Finding triage buttonsNot availableAcknowledge + Mark False PositiveNew
Remediation on path detailBasic list"Top Risk Reducers" with prioritized, named actionsImproved
Finding detailBasic explanationTiered actions (Immediate/Short-term/Ongoing)Improved
Cluster detail tablesPresentRicher: data domain, egress, ownership badges per rowImproved
Impact score displayMisleading bar chartRemoved (PR #89)Fixed
"What changed" filterMissingMissingNo change
System-specific remediationMissingPartially addressed (entities named, no system instructions)Partial
Execution evidence target_resourceEmptyNot visually testable but action plan says not fixedNo change
Scope drift clusterWorkingBROKEN ("cluster is disabled")Regression
Exposure detailNot testedBROKEN ("Entity not found")Regression
Finding description hex IDsPresentStill present (Phase 2.4 not done)No change
Breadcrumb entity namesHash IDsStill hash IDsNo change
Create Ticket buttonDisabledStill not implementedNo change
ExportDisabledNot visibleNo change

Per-Metric Scoring​

#AreaMetricScoreNotes
1ActionabilityFinding clarityCLEARDeterministic explanations remain strong; hex IDs in descriptions still unresolved
1ActionabilityRemediation specificityMIXEDTop Risk Reducers with named entities is progress; system-specific "where to click" still missing
1ActionabilityTicket-readyPARTIALAcknowledge/FP buttons are new; Create Ticket still not wired
1ActionabilityEngineer handoffNEEDS CONTEXTOwnership section shows names; no Entra object IDs or admin console links
2ValidationEvidence chainPARTIALPath visualization excellent; target_resource still empty per action plan
2ValidationManual verificationPARTIALIdentities page helps cross-reference; entity breadcrumbs still hex IDs
2ValidationFalse positive distinguishableYESMark False Positive button is new
3Remediation SafetyFix specificityMIXEDTiered actions (Immediate/Short-term/Ongoing) are strong; some types still generic
3Remediation SafetyBlast radius of fixPARTIALData Domains + Chain detail improve understanding; no "what breaks if I fix" analysis
3Remediation SafetyExecute in productionWITH CAVEATSWould act on dormant/orphaned; would not act on LLM egress without more detail
4Closure & DriftPost-remediation verificationAVAILABLEAcknowledge button adds triage state
4Closure & DriftDrift detectionREGRESSIONscope_drift_sensitive cluster is broken
4Closure & DriftClosure demonstrationCAN PROVEStructurally sound; needs production data to validate
5Triage WorkflowSteps to critical findings1Overview surfaces clusters directly
5Triage WorkflowClicks to context3Overview -> Cluster -> Path Detail with Top Risk Reducers
5Triage WorkflowFilter to my areaPARTIALNew filters on paths/findings; no domain/team filter
5Triage WorkflowWhat's newMISSING#1 daily workflow blocker remains
6InvestigationAuthority path traceCOMPLETEVisual flow diagram with named edges and role labels
6InvestigationBlast radius clarityIMPROVEDData Domains + Chains provide multi-level blast radius view
6InvestigationTemporal comparisonPARTIALPage exists but empty/unusable without guidance
6InvestigationCross-reference navigationMOSTLY LINKEDExposure detail broken; rest works
7ReportingCISO summaryPARTIALCluster narratives are good; no export
7ReportingTrend viewsMISSINGNo time-series data
7ReportingExportMISSINGPhase 4, not yet started
8HandoffEngineer self-sufficiencyNEEDS CONTEXTBetter ownership/metadata; still no source system links
9Partner DeliveryAssessment workflowPARTIALStrong nav flow; broken pages are demo-blocking

Top Workflow Gaps​

1. "What changed since yesterday" — MISSING (Round 1 Gap #1, still the #1 blocker)​

This is the same gap as Round 1 and remains the single most important missing feature for daily operational use. Without it, every morning starts with "where did I leave off?" The action plan (Phase 1.7) acknowledges this as high priority but it has not been implemented. No filter, no section, no badge indicating new/changed findings.

2. Broken pages — scope_drift_sensitive cluster and exposure detail are dead ends​

The scope_drift_sensitive cluster shows "Risk cluster is disabled" and the exposure detail for EXP-322c2c81 shows "Entity not found." These are regressions from Round 1. In a partner demo or daily analyst session, hitting a red error banner destroys confidence. Scope drift was previously one of the strongest finding types — disabling this cluster removes one of the platform's best proof points. This must be fixed before any demo.

3. Remediation still does not tell me which system to go to​

Phase 0.1 from the action plan requires "remediation must name specific objects." The current state is partway there — entities are named in the Top Risk Reducers section, and the path diagram shows source systems as labels. But the gap between "Remove role granting LLM endpoint access" and "In Entra ID > Enterprise Applications > svc-foundry-ascribe-prod, remove the ai_clinical_reader role assignment" is still the difference between "I need to investigate" and "I can create a ticket now."

4. Finding descriptions still contain hex IDs instead of entity names​

"Authority path from workload 'Compliance Audit Exporter' to '811083c85861f79d0f25d96b'" — the hex ID breaks readability for the one field that should be copy-paste-ready for tickets. Phase 2.4 in the action plan.

5. No export or report generation​

Findings, clusters, and evidence packs cannot be exported from the UI. For partner delivery, this means everything must be manually screenshotted. Phase 4 is next sprint.

What Works Well​

  1. The authority path visualization is now genuinely good. The horizontal flow diagram with color-coded nodes (blue workload -> teal identity -> coral resource), labeled edges showing via_roles, and terminal data domain badges is immediately readable. An analyst can trace the full path in one glance. This is a measurable improvement from Round 1's text-only path description.

  2. Data Domains page is excellent for both analysts and partners. The card-based layout showing 7 domains with sensitivity classifications (restricted/confidential), resource counts, and named resources is exactly what I need for blast radius assessment. "Customer: 8 resources, restricted — Oncology_Patient_Histories, GP_Clinical_Notes, Customer PII Store..." This is the "so what" materialized at the data layer.

  3. Execution Chains page provides a new investigation dimension. Grouping entities into chains with destination, egress type, ownership status, max sensitivity, and sensitive domains gives me a cross-cutting view that clusters alone do not. "ServiceNow HR Sync — external egress — orphaned — restricted — hr domain — 9 entities" tells me a complete risk story in one row.

  4. Top Risk Reducers on path detail are well-prioritized. The ordered list of remediation actions with entity references and finding-type context (scope drift, invalid owner, LLM scope) is a genuine improvement. I can now see "here are 5 things you could do, in priority order, and here is what each addresses." This is closer to a real triage workflow.

  5. Finding triage buttons (Acknowledge / Mark False Positive) are a workflow unlock. This was completely absent in Round 1. Being able to acknowledge a finding or flag it as a false positive from within the finding detail page means I can track my triage progress without external tools.

  6. Identities table is a strong operational view. Showing all 10 identities with source system badges (ServiceNow green, Entra purple), sensitive domain tags, and status in one table gives me a quick scan of the identity landscape. I can spot "svc-foundry-agent701 touches engineering, identity, and it_operations" at a glance.

  7. Cluster detail tables now show richer context per row. Each authority path row displays data domain, sensitivity, egress type, ownership status, execution count, and last execution date. I can scan 13 paths in the Orphaned + Sensitive cluster and immediately identify the highest-execution paths without clicking into each one.

Bottom Line​

The platform moved from 70% to roughly 74%. The new pages (Data Domains, Execution Chains, Graph Explorer, Identities), the path visualization improvements, the Top Risk Reducers section, and the finding triage buttons are all genuine progress. But three Round 1 blockers remain unresolved (what-changed filter, system-specific remediation, execution evidence target_resource), and two regressions surfaced (broken scope_drift cluster, broken exposure detail). The regressions are particularly concerning because they hit areas that were previously working.

To reach 80%: (1) fix the broken pages immediately, (2) implement the "what changed since yesterday" filter, and (3) replace hex IDs in finding descriptions with entity names. These three changes would move the score to the target. System-specific remediation and export are important but can follow.

A SOC team could not adopt this today for daily triage — the "what changed" gap and the broken pages make that impossible. A partner could use the current state for point-in-time assessments if the broken pages are fixed first, but would need to do manual work to turn findings into deliverables without export. The direction is right; execution needs to catch up to the action plan.