Enterprise Executive Review: Round 2 -- SecurityV0 Partner Handout Assessment
Round 2 of 2. Evaluating the March 19 demo-w1 snapshot against the Partner Handout Test framework. Baseline: Round 1 scored 1.8/5 on March 15. Target: 3.5/5. This review evaluates what a Fortune 2000 CISO would see if Deloitte walked in today with this platform's output.
Partner Handout Test: NEEDS REWRITE
Could Deloitte hand this directly to a CISO/CIO? No. Not yet.
Estimated rewrite percentage: 50-60%
This is an improvement from Round 1's 60-70%, but the gap remains substantial. The platform has made meaningful progress in two areas: the Overview page now tells a clearer quantitative story, and the cluster detail pages show real authority path data with named entities. However, the three core executive gaps identified in Round 1 remain fundamentally unaddressed:
- Compliance mapping is still absent from every customer-facing surface
- Cost of inaction framing is still absent
- Remediation language still drops into analyst-speak the moment you leave the cluster verdict level
What has improved: the visual hierarchy is cleaner, the authority path detail pages now show a useful execution-derived path diagram, risk condition badges on path details provide at-a-glance severity context, and the "Top Risk Reducers" section on path detail pages represents a genuine step toward actionable choke-point analysis. These are good moves. They make the analyst experience stronger. They do not yet make the executive deliverable possible without major partner rewriting.
One-Page Problem Statement Test
Can I compose a one-page executive summary from the platform output alone?
Partially -- same verdict as Round 1, with modestly better raw material.
What the platform provides (from the screenshots):
- Total autonomous execution volume: 769 executions observed in 30 days
- Total active authority paths: 29
- Active autonomous identities: 5
- Autonomous workloads: 7
- Ownership failures: visible via cluster-level "X lack valid ownership" labels
- Risk clusters: 7 clusters visible (Orphaned + Sensitive, Orphaned + Sensitive + LLM, LLM Egress, Unbound + Sensitive, Orphaned + External Egress, Dormant + External, and scope_drift_sensitive -- though this last one errors out with "Risk cluster is disabled")
- Data domains touched: Finance (restricted), Customer (restricted), HR (restricted), IT Operations (confidential), Engineering (confidential), Security (confidential), Identity (confidential) -- the Data Domains page is genuinely well-organized with sensitivity classifications
- Named paths: "Agent Ascribe_Summarizer via svc-foundry-ascribe-prod to Billing_Payment_Methods," "Foundry Agent701 via svc-foundry-agent701 to Customer Azure Function," etc.
- Path detail: execution-derived path diagram, risk condition badges (scope drift, invalid owner, sensitive data, LLM egress), Top Risk Reducers with named actions
- Execution Chains page: 6 chains with named workloads, destinations, egress type, ownership status, sensitivity classification
What I would still have to fabricate or look up elsewhere:
- Any compliance framework citation (OWASP, NIST, SOX, HIPAA) -- zero present
- Any regulatory fine exposure or audit severity classification
- Any business cost of inaction framing
- Industry benchmarks
- Business unit or application owner mapping beyond individual identity owners
- Translation of "orphaned" / "ambiguous" / "scope drift" into plain business English
The executive summary as it SHOULD read:
Autonomous AI & Automation Risk Assessment: Executive Summary
Assessment Period: February 13 -- March 13, 2026 | Assessment Partner: [Partner Name]
Bottom Line: Your organization has 29 automated processes actively running across sensitive business systems. The majority have no accountable human owner. Activity volume is high -- 769 autonomous executions observed in the last 30 days -- and governance has not kept pace with this growth.
What We Found:
- 7 automated workflows discovered operating across your environment, using 5 machine-to-machine credentials
- 13 access paths to sensitive data have no valid human owner -- the individuals who configured them have departed or been reassigned
- 17 automated processes are routing data through AI services (large language models) without human oversight, accounting for the majority of observed activity
- An AI document summarization tool expanded its access to billing records, clinical notes, patient histories, and psychiatric consultation records -- running autonomously with no owner and no approval for the expanded scope
- 4 automated processes are sending data outside the organization with no active owner monitoring them
- HR data synchronization processes are operating with orphaned ownership and external data transfer, touching restricted employee records
Why You Should Care:
- HIPAA: An ownerless AI agent is accessing patient health records and routing them to an AI service. A single breach carries $50K--$1.5M per violation in fines.
- SOX: Automated processes with expanded financial access (Billing_Payment_Methods, AP/AR Ledger) lack change management approval -- a segregation of duties failure.
- OWASP ASI-03 (Identity Abuse) / ASI-10 (Rogue Agents): Departed employees' automated accounts continue operating autonomously, accessing sensitive data with no oversight.
- NIST AC-2 / AC-6: The majority of automated accounts have no valid owner, violating account management and least-privilege requirements.
What We Recommend (in priority order):
- Reassign ownership of all orphaned automated accounts to accountable teams (Platform Security, IAM)
- Restrict AI service access for the clinical data summarizer until data classification and monitoring controls are in place
- Review and roll back expanded financial access on billing and payment automation to its original, approved scope
- Implement quarterly automated access review for all machine-to-machine credentials (ongoing governance)
- Decommission dormant automated accounts that retain external access with no recent activity
Verdict on the test: I could write this summary, but roughly 50-60% of it -- the compliance mapping, cost framing, and business narrative -- came from my head, not from the platform. The platform provided better quantitative material this round (the cluster verdicts, the path names, the data domain sensitivity classifications), but the "so what" and "now what" in compliance and business-risk terms remain entirely absent. This is a modest improvement from Round 1's 60-70% rewrite estimate.
Business Language Test: FAIL
The platform has made some progress on business language at the top level, but significant issues remain at every layer below the overview.
Improvements since Round 1:
- The Overview page stat cards (769 Total Executions, 29 Active Authority Paths, 5 Active Autonomous Identities, 7 Autonomous Workloads, 3 Active Authority) are reasonably clear -- the numbers are prominent, the labels mostly parseable
- Cluster verdict sentences remain strong: "13 autonomous paths exercised customer/finance/engineering/hr/it_operations/identity/security-scoped authority and invoked endpoints 881 times in the last 30 days -- all lack valid ownership" -- this communicates the problem effectively
- The Data Domains page with sensitivity classifications (restricted, confidential) is genuinely useful for business context
- Execution Chains page uses human-readable workload names and clear ownership/egress columns
- Path detail pages now show named entities in the execution-derived path diagram (e.g., "Agent Ascribe_Summarizer -> svc-foundry-ascribe-prod -> Billing_Payment_Methods")
Technical terms still found that need translation:
| Term in Platform Output | CIO Would Say | Where It Appears |
|---|---|---|
authority_path / "Authority Paths" | "access chain" or "how the automation reaches our data" | Sidebar nav, breadcrumbs, page titles, everywhere |
autonomous_identity | "automated account" or "bot account" | Stat cards, cluster descriptions |
egress (external, llm, internal) | "where data goes" / "sends data to AI services" / "sends data outside" | Cluster names, path badges, chain table |
scope_drift | "access expanded beyond original approval" | Risk condition badges, findings |
reachability_drift | "gained access to systems it couldn't reach before" | Findings page |
orphaned (ownership) | "no active owner" | Cluster descriptions, path details |
ambiguous (ownership) | "team-owned but no individual accountable" | Chain table, path details |
svc-foundry-ascribe-prod | "the document summarization service account" | Authority paths, path details |
svc-foundry-agent701 | "the AI platform service account" | Authority paths, path details |
Foundry | "AI platform" or "Microsoft AI Foundry" | Source badges, path names |
Entra | "identity provider" or "Microsoft directory service" | Source badges, identity table |
eval:05d2c303428d60df3a7c9e9d61f8fae9 | Should not be visible to any human | Finding detail breadcrumb -- this is a hard fail |
01c9ad87... | Should not be visible | Entity detail breadcrumb |
EXP-322c2c81 | Should not be visible | Exposure detail breadcrumb |
perm-incident-write | "ticket system write permission" | Entity detail page |
execution_mode: autonomous | "runs without human involvement" | Path metadata |
identity_binding / "Identity binding" | "how the automation authenticates" | Path detail bottom section |
OIDC (Federated) | Completely opaque to a CIO | Path detail bottom section |
sql_clinical_reader, foundry_ai_executor | Technical role names that need business context | Via roles on path details |
Critical red flags -- hash IDs visible in the UI:
The Finding Detail page shows eval:05d2c303428d60df3a7c9e9d61f8fae9 in the breadcrumb. The Entity Detail page shows 01c9ad87... in the breadcrumb. The Exposure Detail page shows EXP-322c2c81 in the breadcrumb. These are internal system identifiers that should never appear on any screen a partner or executive might see. Round 1 flagged this exact issue. It persists.
What the platform does well in business language:
The cluster verdict sentences remain the strongest executive-language element. The risk condition badges on path detail pages ("scope drift", "invalid owner", "sensitive data", "LLM egress") communicate conditions quickly even if the terms are still slightly technical. The "Top Risk Reducers" section on path detail pages uses action-oriented language that is closer to executive-ready than the Round 1 remediation output.
The Execution Chains page is a new positive: it lists workloads by human-readable name with clear columns for destination, egress type, ownership, sensitivity, and entity count. A partner could use this table directly with minimal rewriting.
Compliance Mapping: ABSENT
This is unchanged from Round 1. Zero compliance framework references appear anywhere in the platform output visible in the screenshots.
OWASP coverage:
- Not present on any screen, cluster card, finding detail, or path detail
- The internal OWASP mapping exists in documentation but is not surfaced in the UI or API output
NIST CSF coverage:
- Not referenced anywhere
SOX / HIPAA / GDPR:
- Not referenced anywhere
- The Data Domains page classifies domains as "restricted" or "confidential" -- this is the closest the platform comes to regulatory context, but it does not map to specific regulatory requirements
What should exist:
The consolidated action plan (Phase 1.3, Phase 4.1) calls for adding OWASP/NIST tags as deterministic mappings. This work has not shipped. The mapping is straightforward -- orphaned_ownership maps to OWASP ASI-03, NIST AC-2; scope_drift maps to OWASP ASI-10, NIST AC-6, CM-3; llm_egress maps to OWASP ASI-02, NIST SC-7. This should be a static lookup table, not an AI inference problem.
This remains the single largest gap for the partner handout use case. A partner cannot deliver an executive assessment to a regulated-industry CISO without compliance framework references. Full stop.
Cost of Inaction: ABSENT
Unchanged from Round 1. The platform provides zero cost-of-inaction framing.
- No regulatory fine exposure estimates
- No audit finding severity classification (material weakness, significant deficiency, control deficiency)
- No incident likelihood framing
- No insurance or liability implications
The platform does provide some building blocks that were present in Round 1: data domain sensitivity classifications (restricted/confidential), execution counts, ownership status breakdowns, and the cluster-level path counts. These give a partner raw material to construct their own cost framing, but the platform does not connect the dots.
Acknowledged: Per the consolidated action plan, cost-of-inaction framing is planned for Phase 4 (report generator). The platform UI intentionally does not include it. The question for this review is: does the platform provide enough structured data for a partner to build the cost case without starting from scratch? The answer is: partially. The data domain sensitivity classifications and cluster-level aggregation help, but without compliance mapping to anchor the cost discussion, a partner is still doing significant manual work.
Remediation in Executive Terms: FAIL
Can you understand the fix without technical knowledge?
Improved but still mixed.
The "Top Risk Reducers" section on the authority path detail page represents real progress. The actions visible in the screenshots include:
- "Assign owner and invalidate expanded scope" -- references specific entities ("install owner > Scope drift")
- "Remove role granting LLM endpoint access" -- references the scope reduction
- "Assign owner and restrict LLM egress"
- "Restrict scope to exercised authority only"
- "Assign a valid owner to this workload"
These are materially better than Round 1's generic "Reduce execution paths to least-privilege scope." They name what should happen, they reference the specific risk conditions, and they imply priority ordering through their visual position.
The Finding Detail page also shows improved remediation structure with priority labels ("Immediate", "Short-term", "Ongoing") and specific actions:
- Immediate: "Revoke unused execution paths" with supporting context "2 execution path(s) remain active despite no recent activity"
- Short-term: "Disable identity if no longer needed"
- Ongoing: "Rotate credentials associated with this identity"
This priority-tiered structure is closer to what a partner needs.
Responsible role assigned?
NO. No remediation action anywhere in the screenshots names a responsible team or role. "Assign owner" appears as an action but does not specify WHO should be assigned or which team should do the assigning. The consolidated action plan called for this (Phase 0.1: "Remediation must name specific objects" and Sergey's feedback about choke points). Not yet delivered.
Choke point analysis present?
PARTIALLY. The "Top Risk Reducers" section on path detail pages is a step in the right direction -- it implies that some actions have higher impact than others through ordering. However, it does not explicitly state "this one fix reduces N exposures across M clusters" which is the choke-point insight Sergey specifically requested.
Does a partner have enough data to build their own cost case?
PARTIALLY. The combination of named paths, sensitivity classifications, ownership status, and execution counts gives a partner meaningful building blocks. But without compliance mapping or cost-of-inaction framing, the partner still needs to supply the entire regulatory and business-impact layer. This is a heavy lift -- probably 40-50% of the total partner deliverable effort.
Board Slides Test
Can I build 3 board slides from the platform data?
Partially -- same structure as Round 1, with modestly better data quality for Slide 1.
Slide 1: What We Found
Data source: Platform provides 90% (unchanged from Round 1)
Autonomous Automation Risk Assessment Results
An independent 2-week assessment of our automated processes and AI agents revealed:
- 29 active automated access paths discovered across our environment
- 7 automated workflows using 5 machine-to-machine credentials
- 769 autonomous executions observed in the last 30 days
- 7 sensitive data domains exposed: Finance (restricted), Customer (restricted), HR (restricted), IT Operations, Engineering, Security, Identity
- 17 automated processes routing data through AI services (LLM endpoints) -- the largest risk cluster
- 13 access paths to sensitive data have no valid human owner
Highest Risk: An AI document summarizer ("Agent Ascribe_Summarizer") with no owner expanded its access to billing records, clinical notes, patient histories, and psychiatric consultation records -- running 127+ times per day through AI services with zero human oversight.
What I pulled from the platform: All numbers, data domain list with sensitivity classifications, cluster names and path counts, specific path names with named entities.
What I had to add: The framing ("independent 2-week assessment"), the "Highest Risk" callout structure, and the plain-English translation of what Agent Ascribe_Summarizer does.
Delta from Round 1: The Data Domains page now provides sensitivity classifications (restricted/confidential) which strengthen this slide. Execution Chains page provides cleaner workload-level aggregation. Modestly better.
Slide 2: Why It Matters
Data source: Platform provides 20% (unchanged from Round 1)
Compliance & Business Risk Exposure
Risk Area Exposure Framework Patient Health Data AI agent accessing clinical, psychiatric, and oncology records with no owner, routing through external AI services HIPAA 164.312 -- $50K-$1.5M per violation Financial Controls Automated processes with expanded access to billing and payment methods without change approval SOX 404 -- Material weakness Customer PII Data synchronization processes accessing customer PII stores with no verifiable individual owner GDPR Art. 5(2) -- 4% annual revenue AI Data Egress 17 automated processes routing data through AI services, accounting for the majority of execution volume OWASP ASI-02, NIST SC-7 HR Data HR synchronization process with orphaned ownership and external data transfer touching restricted employee records HIPAA / employment law If we do nothing: Our next SOX audit will surface the expanded financial automation access as a segregation-of-duties finding. The clinical data AI agent represents an active HIPAA exposure that grows with every execution.
What I pulled from the platform: The specific findings, data domains and their sensitivity classifications, ownership failures, path names.
What I had to fabricate entirely: Every single compliance framework reference. Every dollar amount. The audit finding classification. The "if we do nothing" narrative. The platform gave me zero help on any of this. This is identical to Round 1.
Slide 3: What We Recommend
Data source: Platform provides 35% (up from 30% in Round 1)
Prioritized Remediation Plan
Priority Action Responsible Team Risk Reduction Immediate Restrict AI service access for the clinical document summarizer until owner assigned and data monitoring deployed Platform Security Eliminates active HIPAA exposure across 9 access paths This Week Reassign ownership of 13+ orphaned automated accounts to accountable team leads IT Security + business unit leads Resolves the majority of governance failures This Week Review and restrict expanded financial access on billing and payment automation to its original scope Finance IT Resolves SOX segregation-of-duties finding This Month Implement data monitoring on all AI service outbound data flows Data Security Controls 17 automated AI data transfer paths This Quarter Stand up quarterly automated access review for all machine-to-machine credentials Security Governance Prevents future ownership decay and access expansion This Quarter Decommission dormant automated accounts with external access and no recent activity IAM team Reduces latent attack surface
What I pulled from the platform: The specific automated processes to fix, the named paths and workloads, the cluster-level risk groupings, and the "Top Risk Reducers" section on path details for directional remediation guidance.
What I had to fabricate: Every responsible team assignment. Every priority classification. The compliance justification for each action. The "risk reduction" column framing. The platform's "Top Risk Reducers" are better this round -- they name specific actions ("Assign owner and invalidate expanded scope") -- but I still had to translate them into executive terms and add the organizational context.
Delta from Round 1: The "Top Risk Reducers" section is new and useful. It gives me directional guidance on which fixes matter most. The priority labels on finding-level remediation (Immediate/Short-term/Ongoing) are also new and helpful. I estimate the platform now provides about 35% of what I need for this slide, up from 30%.
Recommendations
What has been accomplished since Round 1:
- Impact scores removed (PR #89) -- Good. Removes a confusing signal that was not calibrated.
- Path detail pages improved -- The execution-derived path diagram, risk condition badges, and "Top Risk Reducers" section are all meaningful improvements for the analyst experience and provide better raw material for partner extraction.
- Execution Chains page -- New and useful. Provides a workload-level view with clear ownership, egress, and sensitivity columns.
- Data Domains page -- Clean presentation with sensitivity classifications. This is directly useful for executive context.
- Finding detail remediation -- Priority labels (Immediate/Short-term/Ongoing) are new and helpful for guiding partner recommendations.
What remains from Round 1 -- critical gaps:
1. Compliance Mapping (CRITICAL -- was #1 in Round 1, still #1)
This was identified as "pull into this sprint" in the consolidated action plan (Phase 4.1). It has not shipped. The mapping is a static lookup table. Every week it remains absent is a week the platform cannot support a partner deliverable to a regulated-industry CISO.
Priority: Immediate. This is the single highest-value, lowest-effort improvement available.
2. Hash IDs in Breadcrumbs and URLs (CRITICAL -- was flagged in Round 1, persists)
The Finding Detail page shows eval:05d2c303428d60df3a7c9e9d61f8fae9 in the breadcrumb. The Entity Detail page shows 01c9ad87.... The Exposure Detail shows EXP-322c2c81. The scope_drift_sensitive cluster shows a raw slug in the breadcrumb. These are not acceptable in any context where a partner might screen-share or a CISO might see the platform.
Priority: Immediate. Phase 2.3 (breadcrumbs) and Phase 2.4 (finding description hash IDs) in the consolidated action plan cover this.
3. Responsible Role Assignment on Remediation (HIGH)
No remediation action anywhere names a responsible team. The consolidated action plan (Phase 0.1) calls for this. "Assign owner" is an action -- but assign to WHOM? "IAM team," "Platform Security," "Application Owner," "Finance IT" -- these are the words a CISO needs to see next to every recommended action.
4. Broken Pages (HIGH -- demo blocker)
- The scope_drift_sensitive cluster page shows "Risk cluster is disabled: scope_drift_sensitive" with a Retry button. This is a broken page in a demo dataset. Unacceptable for a partner presentation.
- The Exposure Detail page for EXP-322c2c81 shows "Entity not found" with a Retry button. Dead end.
- These errors destroy confidence. If Deloitte is screen-sharing this platform and hits a "not found" error, the assessment credibility drops immediately.
5. Cross-Cluster Choke Point Visibility (MEDIUM)
The "Top Risk Reducers" section is per-path. The insight Sergey requested -- "show where one fix reduces multiple exposures" -- is not yet visible. A CISO wants to hear: "Fixing ownership on the document summarizer resolves findings in 3 of your 7 risk clusters." This cross-cluster choke point view is not present.
6. Report Generator / Export (STRATEGIC -- Phase 4)
The platform UI will never be the executive deliverable. The report generator is the right architectural decision. But until it exists, the partner is manually extracting data from the platform and rewriting it. Every improvement to the platform's structured data (compliance mapping, responsible roles, choke points) reduces the rewrite burden, even before the report generator ships.
New observations not in Round 1:
7. "Autonomous Workloads" vs "Execution Chains" Confusion
The Overview page shows "7 Autonomous Workloads" as a stat card. The Execution Chains page shows 6 chains. The Authority Paths page shows 29 active paths. The Identities page shows 10 identities. A CISO will ask: "How many automated things are running in my environment?" and the answer depends on which page you look at. The relationship between workloads, chains, identities, and paths needs a clear hierarchy or the partner will spend their 30-minute presentation answering "wait, is it 7 or 29 or 10?"
8. Cluster Naming Inconsistency
The Overview page shows "Orphaned + Sensitive" and "Orphaned + Sensitive + LLM" as separate clusters. A CISO will ask: "Why are these two separate things? Aren't the LLM ones also orphaned and sensitive?" The cluster taxonomy needs to be mutually exclusive or clearly explained as overlapping dimensions.
9. "Eleanor Hartwell v0.2-dev" in the Footer
The sidebar footer shows a user name and version badge. This is fine for an analyst tool. But if a partner is screen-sharing, "v0.2-dev" signals early-stage software. For demos, this should either be hidden or show a clean version number.
Score (1-5)
| Dimension | Round 1 | Round 2 | Delta | Rationale |
|---|---|---|---|---|
| Business language clarity | 3/5 | 3/5 | +0 | Cluster verdicts remain strong. Hash IDs still leak through breadcrumbs and entity pages. New pages (Execution Chains, Data Domains) are well-structured. But the overall language issue -- "authority path," "egress," "scope drift," "identity binding," "OIDC (Federated)" -- persists at every layer below the overview. Net: no change. |
| Compliance framework alignment | 1/5 | 1/5 | +0 | Still completely absent from all customer-facing output. The consolidated action plan identifies this as Phase 1.3 / 4.1. It has not shipped. |
| Partner deliverable readiness | 2/5 | 2.5/5 | +0.5 | Execution Chains page, Data Domains with sensitivity classifications, and "Top Risk Reducers" on path details give partners better structured data to extract. Rewrite estimate drops from 60-70% to 50-60%. Still not close to the target. |
| Board presentation readiness | 2/5 | 2/5 | +0 | Slide 1 is modestly better (data domains, chain-level view). Slides 2 and 3 remain entirely dependent on partner-supplied compliance and cost framing. No compliance mapping = no board slide 2. |
| Remediation actionability (role + choke points) | 1/5 | 2/5 | +1.0 | "Top Risk Reducers" section is new and meaningful. Priority labels on finding remediation (Immediate/Short-term/Ongoing) are new. No responsible role assignment. No cross-cluster choke point view. But the direction is clearly correct and the improvement is real. |
Overall: 2.1/5 for executive deliverable readiness
Delta from Round 1: +0.3 (from 1.8 to 2.1)
Delta vs Round 1: Summary
| Round 1 Finding | Status in Round 2 | Assessment |
|---|---|---|
| Compliance mapping absent | Still absent | Critical gap, no change |
| Cost of inaction absent | Still absent | Expected -- planned for Phase 4 report generator |
| Effort/cost estimates absent | Intentionally dropped per Sergey's decision | Correct decision -- evaluate on responsible roles + choke points instead |
| Hash IDs visible in UI | Still present in breadcrumbs (findings, entities, exposures) | Regression risk for demos |
| Remediation in technical language | Improved -- Top Risk Reducers, priority labels | Real progress, not yet sufficient |
| Cluster verdict sentences strong | Still strong | Foundation remains solid |
| Business language evaporates below cluster level | Still true | Structural issue -- platform serves analysts, reports will serve executives |
| Partner rewrite 60-70% | Down to 50-60% | Modest improvement |
| Broken cluster page (scope_drift_sensitive) | New issue -- was not present or not captured in Round 1 | Demo blocker |
| Exposure detail "Entity not found" | New issue | Demo blocker |
Verdict
The platform has moved in the right direction. The architectural decision to keep the platform sharp for analysts and build a separate report generator for executives is correct, and the consolidated action plan reflects sound priorities. The improvements in remediation structure (Top Risk Reducers, priority labels), the Execution Chains page, and the Data Domains page are genuinely useful additions.
However, the overall score of 2.1/5 falls well short of the 3.5/5 target. The gap is almost entirely explained by two items:
-
Compliance mapping (Phase 1.3 / 4.1) has not shipped. This is a static lookup table. It is low effort. It would move the compliance dimension from 1/5 to 3/5 and unlock meaningful improvement across partner deliverable readiness and board presentation readiness. Its absence is the single largest drag on the score.
-
Responsible role assignment on remediation has not shipped. This was Phase 0.1 in the consolidated action plan. Without it, every remediation recommendation requires the partner to figure out who should do the work. Adding role assignment would move remediation actionability from 2/5 to 3/5.
If these two items shipped, the score would move to approximately 2.8-3.0/5. Adding cross-cluster choke point visibility and fixing the hash IDs in breadcrumbs would push it to approximately 3.2-3.5/5.
The broken pages (scope_drift_sensitive cluster, Exposure Detail "Entity not found") are demo blockers that must be fixed before any partner or prospect sees this platform.
The data foundation remains strong. The executive wrapper is still what is missing -- and the two lowest-effort, highest-impact items (compliance mapping, responsible roles) remain unshipped.