Vision Alignment Analysis — Developer Perspective

Date: 2026-02-17 Scope: Developer analysis of docs 06 and 07 in context of Sergey's W1 product vision and UX specification, with codebase evidence.

---

1. Code-to-Vision Gap Analysis

1.1 Current UI Page Inventory vs W1 UX Spec

The current platform has 8 navigable pages defined in ui/src/components/Layout.tsx:6-15 and routed in ui/src/App.tsx:29-43. The W1 UX spec defines exactly 3 views. Here is the mapping:

Current Page	Route	W1 UX Equivalent	Status
Dashboard	/	Homepage (partially)	Needs redesign — current shows stat cards (RG1/RG2/ownership counts), bar charts by type/risk group, priority automations list; W1 needs Posture Summary + Top 5 Risk Clusters + Since Last Refresh delta
Automations	/automations	No direct equivalent	Superseded — W1 enters via risk clusters, not automation inventory
Automation Detail	/automations/:id	Finding Detail (partially)	Some concepts reusable — Overview tab, ExecutionFlowDiagram, Evidence tab contain data W1 needs
Chains	/chains	None	Not needed in W1 — chains explicitly out of W1 scope (scope.md:63)
Chain Detail	/chains/:id	None	Not needed in W1
Findings	/findings	Findings View	Needs redesign — current is flat table by severity/type/description; W1 needs grouping by Risk Cluster with path-row format
Finding Detail	/findings/:id	Finding Detail	Needs augmentation — current has evidence pack viewer (9 sections); W1 needs deterministic path diagram, standing authority block, linkage proof card, structured 4-section evidence panel
Graph Explorer	/graph	None	Explicitly excluded — W1 UX says "No graph browsing mode" (ux.md:307)
Entities	/entities	None	Not in W1 flow
Entity Detail	/entities/:id	None	Not in W1 flow
Syncs	/syncs	None	Not in W1 flow (but refresh timestamp needed on Homepage)
Temporal	/temporal	None	Explicitly excluded — no drift detection in W1 (definition.md:160)

1.2 What is Currently Built That W1 Does Not Need

These pages/features are functional but outside W1 scope. They should remain in the codebase for developer/debug use but not appear in W1 primary navigation.

1. Execution Chains page and detail (ui/src/pages/ExecutionChainsPage.tsx, ui/src/pages/ExecutionChainDetailPage.tsx) — W1 scope doc explicitly excludes chain persistence, fingerprinting, versioning
2. Graph Explorer (ui/src/pages/GraphExplorerPage.tsx) — W1 UX: "No alternate navigation. No graph browsing mode."
3. Entities list and detail (ui/src/pages/EntitiesListPage.tsx, ui/src/pages/EntityDetailPage.tsx) — generic entity browser not part of W1 investigation flow
4. Temporal Comparison (ui/src/pages/TemporalComparePage.tsx) — drift detection is out of W1 scope
5. Automations table as primary entry point (ui/src/pages/AutomationsPage.tsx) — W1 enters via Risk Clusters, not an automation inventory

1.3 What W1 UX Demands That Does Not Exist Yet

W1 UX Requirement	Exists?	Notes
Posture Summary (Active NHI Execution Identities, Dormant Authority Identities, Operator-Assisted, Human-Triggered)	No	Current Dashboard (ui/src/pages/Dashboard.tsx:140-159) has stat cards for total automations, RG1, RG2, ownership issues — but NOT the execution-model breakdown W1 specifies
Since Last Refresh delta line (+X new, +Y ownership invalidations, -Z removed)	No	No sync-to-sync diff infrastructure exists
Top 5 Autonomous Authority Risk Clusters (compound condition prioritization)	No	Dashboard has RG1-RG5 bar charts (Dashboard.tsx:178-192) but NOT compound-condition clusters like "Sensitive + LLM + Active + Invalid Owner"
Findings View grouped by Risk Cluster with deterministic path rows	No	FindingsList.tsx is a flat table with severity/type/description columns
Finding row as deterministic path (Automation -> Identity -> Destination -> Data Domain)	No	FindingsList.tsx rows show severity badge, finding type, deterministic explanation text
Inline Expand on finding row (ownership breakdown, evidence completeness strip, linkage proof indicator)	No	EvidenceCompletenessBar component exists at ui/src/components/findings/EvidenceCompletenessBar.tsx for Finding Detail but not inline
Finding Detail: Standing Authority Section (Execution Model: Autonomous, Authentication Type: Client Credentials, Human Session Required: No)	No	Auth type data exists on entity properties; no dedicated UI section
Finding Detail: Structured Evidence Panel (4 sections)	Partial	Current EvidencePackViewer at ui/src/components/findings/EvidencePackViewer.tsx has 9 sections per evidence pack schema; W1 needs simpler 4-section panel
Finding Detail: Linkage Proof Card	No	Cross-system linkage data exists in evidence packs; no dedicated card
Finding Detail: Sensitive Domain Summary	Partial	Domain data on execution_paths; no dedicated summary component
Finding Detail: Remediation Placeholder (disabled button)	No	Trivial to add
Execution Model labels ("Autonomous (Client Credentials)", "Human Session Required: No")	Partial	execution_mode property exists; ExecutionModeBadge exists at ui/src/components/AutomationBadges.tsx; need to add auth protocol detail

1.4 Backend Data Readiness

Most W1 data requirements are already met by existing backend:

W1 Data Need	Backend State	Gap
Automation inventory	Implemented (entity_type: "automation" entities)	None
RUNS_AS identity binding	Implemented (entity relationships + identity_binding_status property)	None
Execution evidence with proven/unproven	execution_evidence collection exists; evaluator rules check evidence via getEvidenceWithRunsAs() in src/evaluator/rules/dormant-authority.ts:9-33	Need explicit proven/unproven status derivation
Data reachability (domain classification)	Implemented via execution_paths with business_domain and sensitivity on entities	None
Egress classification	Implemented (egress_category: llm/external/internal/unknown on entity properties)	None
Ownership validation	Implemented (ownership_status: valid/invalid/ambiguous); orphanedOwnershipRule at src/evaluator/rules/orphaned-ownership.ts:38-136	Need unknown state surfaced explicitly
Risk cluster computation	Not implemented	New aggregation layer needed
Since-last-refresh delta	Not implemented	Sync snapshot diffing needed

---

2. Naming Impact Assessment

2.1 Doc 07 Phase 1 Changes — File Location Map

Doc 07 Change	File	Current Code	W1 Relevance
Nav "Chains" -> resolved name	ui/src/components/Layout.tsx:9	{ to: "/chains", label: "Chains", icon: Link2 }	Low — W1 may remove this nav item entirely
Page title "Execution Chains" -> resolved	ui/src/pages/ExecutionChainsPage.tsx:143	<h1>Execution Chains</h1>	Low — page not in W1 flow
"Last Seen" -> "Last Computed"	ui/src/pages/ExecutionChainDetailPage.tsx:81	Last seen: {timeAgo(chain.last_seen_at)}	Low — page not in W1 flow
"Execution" column -> resolved	ui/src/pages/AutomationsPage.tsx:114	header: "Execution"	Medium — if Automations page persists as secondary view
Glossary update	sv0-documentation/docs/glossary.md	Disambiguation section	Medium — documentation clarity regardless of UI

2.2 Does W1 UX Use "Execution Chains"?

No. The term "Execution Chains" does not appear anywhere in Sergey's W1 documents (vision.md, definition.md, scope.md, ux.md).

W1 scope explicitly states (scope.md:63-66):

W1 does not require: execution_chains persistence, Chain fingerprinting, Drift detection, Temporal versioning

The W1 investigation flow is Homepage -> Risk Cluster -> Findings View -> Finding Detail. There is no chains page.

2.3 Is "Automation -> Identity -> Destination -> Data Domain" the Same as an Execution Chain?

No. They are fundamentally different concepts.

Aspect	W1 Path Row	Execution Chain
Shape	4-node linear projection	N-node BFS tree (typically 5-20+ entity refs)
Source	Derived at render time from finding + entity + execution_paths	BFS traversal in src/ingestion/chain-builder.ts:62-125, stored in execution_chains collection
Persistence	None required — computed on demand	Stored with composition_hash, first_detected_at, last_seen_at (see src/domain/chains/types.ts:28-39)
Granularity	Summary nodes only: what automation, what identity, what destination, what data	All intermediate entities: entry_point, code_component, outbound_target, auth_credential, destination_identity, trigger_resource, data_resource (see src/domain/chains/types.ts:3-10)
Semantic	"What risk does this expose?" (CISO-facing)	"What structural path exists?" (topology)

The W1 path is doc 06's ExposureUnit concept — a deterministic CISO-facing projection. The data to construct it already exists:

• Automation: finding's entity_id -> entity record
• Identity: entity's RUNS_AS relationship target
• Destination: entity's egress_host or INVOKES/AUTHENTICATES_TO target
• Data Domain: entity's execution_paths[].business_domain and sensitivity

The existing ExecutionFlowDiagram.tsx renders 5 steps (TRIGGER -> ENTRY POINT -> CALLS -> RUNS AS -> CAN ACCESS) which is structurally close but needs simplification to the 4-node W1 format. The extractFlowSteps() function at ui/src/components/ExecutionFlowDiagram.tsx:16-93 already extracts the necessary data from entity relationships and properties.

---

3. Implementation Feasibility

3.1 Which Doc 07 Changes Are Still Valid Under W1?

Doc 07 Proposal	Still Valid?	Reasoning
Phase 0a (completed): Evaluator text "Automation has..." + RUNS_AS note	Yes	Finding explanations are used in W1 Finding Detail
Phase 0b (completed): ExecutionFlowDiagram rename + "ENTRY POINT" label	Yes	Flow diagram concept survives (adapted for W1 path)
Phase 0c (completed): Glossary disambiguation	Yes	Documentation accuracy always valid
Phase 1: "Execution" column rename on AutomationsPage	Partially relevant	AutomationsPage not in W1 flow, but naming fix is good hygiene
Phase 1: "Last Seen" rename on ChainDetailPage	Irrelevant to W1	Chain detail not in W1 flow
Phase 1: Nav label "Chains" rename	Irrelevant to W1	W1 has no chains nav item
Phase 1: Page title "Execution Chains" rename	Irrelevant to W1	W1 has no chains page
Phase 1: Glossary 3-vs-4 concept update	Yes	Conceptual clarity helps regardless
Phase 2: AutomationRun infrastructure	Deferred to W2	Doc 06 already deferred; W1 confirms
Phase 3: Topology/Run correlation	Deferred to W2+	Explicitly out of W1 scope

3.2 What Becomes Irrelevant Because W1 Redesigns Page Structure

The entire chains page family is not part of W1 flow. Renaming Q1 (what to call "Execution Chains"), Q3 (timestamp label), and Q5 (nav item) are low-priority because:

1. W1 users will never navigate to these pages.
2. Pages can remain as internal/debug views.
3. If W2 brings chain-related features, rename then.

3.3 New Components/Pages W1 UX Requires

New pages (or major refactors of existing):

1. W1 Homepage (refactor Dashboard.tsx)
2. W1 Findings View (refactor FindingsList.tsx)
3. W1 Finding Detail (refactor FindingDetail.tsx)

New components:

1. PostureSummary — Active NHI count, Dormant count, Operator-Assisted, Human-Triggered
2. RefreshDelta — "+X new, +Y invalidations, -Z removed" single line
3. RiskClusterCard — compound condition title, identity count, executions (30d), domains, ownership invalid count
4. FindingPathRow — Automation -> Identity -> Destination -> Data Domain with W1 columns
5. FindingInlineExpand — ownership breakdown, evidence summary, completeness strip, linkage proof
6. StandingAuthorityBlock — Execution Model, Auth Type, Human Session Required
7. StructuredEvidencePanel — 4 sections (Automation Metadata, Identity Binding, Execution Evidence, Egress Config)
8. LinkageProofCard — issuing tenant, target instance, matching field/value
9. SensitiveDomainSummary — reached domains with sensitivity classification
10. W1PathDiagram — 4-node linear path (adapt from ExecutionFlowDiagram)

---

4. Concrete Recommendations for Q1-Q5

Q1: What should we call Concept 2 (currently "Execution Chains")?

Recommendation: Keep "Execution Chains" internally; do not prioritize renaming.

Rationale:

• W1 UX does not surface chains to users at all.
• Renaming touches many files: src/domain/chains/types.ts (ChainEntityRole, ChainEntityRef, ChainSummary, ExecutionChainDoc, ChainQuery, ChainAssemblyResult), src/ingestion/chain-builder.ts (assembleExecutionChains), src/api/routes/chains.ts (3 routes), ui/src/hooks/use-execution-chains.ts, ui/src/pages/ExecutionChainsPage.tsx, ui/src/pages/ExecutionChainDetailPage.tsx, plus storage adapter methods. This is significant churn for zero W1 user impact.
• If a rename is desired later for codebase clarity: "Authority Chains" best captures security meaning and avoids runtime confusion. But this is a W2 concern.

Q2: Column header for observed execution count?

Recommendation: "Executions (30d)"

Rationale:

• W1 UX uses exactly "Executions (30d)" in the Finding Row collapsed state (ux.md:129) and risk cluster cards (ux.md:105).
• Aligns the AutomationsPage vocabulary with W1, reducing cognitive dissonance.
• Implementation: change header: "Execution" to header: "Executions (30d)" in ui/src/pages/AutomationsPage.tsx:114.

Q3: Timestamp label on chain detail pages?

Recommendation: "Last Computed" (low priority)

Rationale:

• Chain detail page not in W1 scope.
• "Last Computed" is technically correct — chains are recomputed at sync time by chain-builder.ts, not observed at runtime.
• Only implement if touching chain detail for other reasons.

Q4: Glossary 3-concept vs 4-concept?

Recommendation: (B) Add the 4th concept now as "planned."

Rationale:

• Doc 06 establishes the 4-concept model clearly.
• W1 effectively adds a 5th concept: ExposureUnit (the deterministic CISO-facing projection).
• Mark AutomationRun as "planned/W2" and ExposureUnit as "W1 projection" to set expectations without promising unbuilt infrastructure.

Q5: Nav item for chains page?

Recommendation: Remove from W1 primary nav. Keep accessible via direct URL.

Rationale:

• W1 navigation should be: Homepage, Findings (2-3 items total).
• Chains, Graph Explorer, Entities, Syncs, Temporal are developer/debug tools.
• Restructure Layout.tsx nav into:
  • W1 nav: Homepage, Findings
  • Developer/debug nav (collapsed or secondary section): Automations, Chains, Graph, Entities, Syncs, Temporal
• This avoids the naming debate entirely for W1 by removing chains from primary navigation.

---

5. Implementation Effort Estimate

5.1 Backend API Changes

Change	Files	Size	Notes
Risk cluster aggregation endpoint	New: src/api/routes/exposure.ts, modify src/api/index.ts to mount	Large	New query that groups entities by compound conditions (sensitivity + egress + execution status + ownership), computes counts/aggregates. No existing analog.
Posture summary endpoint	Could be part of exposure routes above	Medium	Aggregation query grouping automations by execution_mode + evidence status. Could use existing queryEntities with filters.
Refresh delta computation	New logic in sync worker or new query endpoint	Medium	Compare current entity set to previous sync snapshot. Need to track entity count per sync.
Finding enrichment for path display	Modify src/api/routes/findings.ts to join entity path data	Medium	Each finding needs: automation name, identity name, destination, data domains. Currently GET /api/v1/findings/:id returns entity_name and affected_resources but not full path. Options: enrich list response, or use batch entity lookup client-side.

5.2 Frontend Changes

Change	Files	Size	Notes
W1 Homepage	Refactor ui/src/pages/Dashboard.tsx	Large	Replace stat cards + RG breakdown + priority list with Posture Summary + Since Last Refresh + Top 5 Risk Clusters
PostureSummary	New: ui/src/components/w1/PostureSummary.tsx	Small	4 cards with active/dormant/operator/human counts
RefreshDelta	New: ui/src/components/w1/RefreshDelta.tsx	Small	Single delta line display
RiskClusterCard	New: ui/src/components/w1/RiskClusterCard.tsx	Medium	Compound condition title, identity count, executions 30d, sensitive domains, ownership invalid count
W1 Findings View	Refactor ui/src/pages/FindingsList.tsx	Large	Cluster-grouped layout, path row format, inline expand
FindingPathRow	New: ui/src/components/w1/FindingPathRow.tsx	Medium	4-node path display + W1 columns
FindingInlineExpand	New: ui/src/components/w1/FindingInlineExpand.tsx	Medium	Ownership breakdown, evidence summary, completeness strip, linkage proof
W1 Finding Detail	Refactor ui/src/pages/FindingDetail.tsx	Large	Standing authority block, 4-section evidence panel, linkage proof card, path diagram, domain summary
W1PathDiagram	Adapt ui/src/components/ExecutionFlowDiagram.tsx or new component	Small	Simplify from 5 steps to 4 nodes
StandingAuthorityBlock	New: ui/src/components/w1/StandingAuthorityBlock.tsx	Small	Execution Model, Auth Type, Human Session Required
StructuredEvidencePanel	New: ui/src/components/w1/StructuredEvidencePanel.tsx	Medium	4 sections vs current 9-section evidence pack
LinkageProofCard	New: ui/src/components/w1/LinkageProofCard.tsx	Small	Cross-system matching proof display
SensitiveDomainSummary	New: ui/src/components/w1/SensitiveDomainSummary.tsx	Small	Domain list with sensitivity
Navigation restructure	Modify ui/src/components/Layout.tsx	Small	W1 primary nav (2-3 items) vs developer tools section

5.3 What Can Be Reused Directly

Existing Asset	File	Reuse in W1
EvidenceCompletenessBar	ui/src/components/findings/EvidenceCompletenessBar.tsx	Reuse in inline expand and finding detail
SeverityBadge	ui/src/components/SeverityBadge.tsx	Reuse in findings rows
EgressBadge, OwnershipBadge, ExecutionModeBadge	ui/src/components/AutomationBadges.tsx	Reuse in path rows and detail
StatusWorkflow	ui/src/components/findings/StatusWorkflow.tsx	Reuse in finding detail (if W1 adds status transitions)
extractFlowSteps() logic	ui/src/components/ExecutionFlowDiagram.tsx:16-93	Adapt for W1PathDiagram
useFindings hook	ui/src/hooks/use-findings.ts	Extend for cluster filtering
useAutomations hook	ui/src/hooks/use-automations.ts	Use for posture summary aggregation
useExecutionEvidence hook	ui/src/hooks/use-execution-evidence.ts	Use in evidence panel
useBlastRadius hook	ui/src/hooks/use-blast-radius.ts	Use for domain summary data
All 4 evaluator rules	src/evaluator/rules/*.ts	No changes needed — finding types align with W1 exposure conditions
Evidence API	src/api/routes/evidence.ts	No changes needed
execution_paths on entities	Entity model	Provides data domain and sensitivity for W1 path

5.4 Summary

Category	Effort
Homepage redesign	Medium-Large (1 page refactor + 3 new components + 1-2 API endpoints)
Findings View redesign	Large (1 page refactor + 3 new components + possible API enrichment)
Finding Detail redesign	Large (1 page refactor + 5 new components)
Nav restructure	Small (1 file change)
Backend API additions	Medium-Large (1-2 new endpoints, 1 response enrichment)
Evaluator rule changes	None
Storage changes	None
Ingestion changes	None

Total new UI components: ~10-12 Total modified pages: 3 (Dashboard, FindingsList, FindingDetail) Total modified infrastructure files: 2-3 (Layout, App router, API routes) Backend schema changes: None New backend endpoints: 1-2

5.5 Recommended Phasing

Phase A (immediate, highest W1 alignment):

1. Navigation restructure — reduce primary nav to W1 flow
2. Posture summary component + API aggregation
3. W1 homepage with posture summary (risk clusters can come later)
4. Finding enrichment (path data in finding response)
5. W1 Findings View with deterministic path rows

Phase B (risk clusters + detail):

1. Risk cluster aggregation endpoint
2. Risk cluster cards on homepage
3. Cluster-based filtering on Findings View
4. W1 Finding Detail redesign (standing authority, path diagram, structured evidence panel)
5. Inline expand on findings rows

Phase C (polish):

1. Since Last Refresh delta
2. Linkage proof card
3. Sensitive domain summary
4. Remediation placeholder
5. W1-specific finding types in evaluator (if needed beyond current 4 rules)

---

6. Key Takeaways

1. W1 UX is a fundamental reframe, not a label change. Doc 07's Phase 1 (UI label fixes) is useful hygiene but does not move the platform toward W1. The W1 UX requires new pages, new components, new backend endpoints, and a new information architecture.

2. Execution Chains are internal infrastructure for W1, not user-facing. The chain-builder (src/ingestion/chain-builder.ts) and chains collection can serve as data sources for W1 views, but the chains page/detail should not appear in W1 navigation.

3. The W1 path (Automation -> Identity -> Destination -> Data Domain) is a new concept — the ExposureUnit. It is not an execution chain. It is a deterministic, CISO-facing projection derived from entities, execution paths, and evidence. It should be computed on-demand, not stored as a new collection.

4. Risk clusters are the biggest new concept. Neither the codebase nor the data model has compound-condition risk grouping. The existing risk_group (RG1-RG5) is a per-entity classification, not a cross-entity cluster. W1 risk clusters require a new aggregation layer.

5. Most existing code is reusable. The 4 evaluator rules, entity model, execution paths, evidence collection, evidence packs, and badge components all feed into W1. The gap is primarily in presentation (new page layouts, path-row format, inline expand) and aggregation (risk clusters, posture summary), not in core data infrastructure.

6. Naming decisions (Q1-Q5) are secondary to structural changes. The highest-impact work is building the W1 homepage, findings view, and finding detail. The execution chain naming question is moot for W1 because chains are not user-facing in this wedge.