Vision vs. Delivered — Deep Gap Analysis & Architecture Evolution Plan

Date: 2026-02-10 Status: Draft — pending team review

Executive Summary

The platform has strong technical foundations: full ingestion pipeline, 5 evaluator rules, evidence packs, graph visualization with focus modes, and enterprise data tables. Track 1 (pilot-critical requirements) is complete at the connector level.

However, there are four structural misalignments between the product vision and what the platform actually delivers to a user:

#	Gap	Severity	Core Problem
1	UI is findings-centric, not automation-centric	High	PRD says "detect automation first" — UI starts with findings dashboard, not automations
2	Graph doesn't clearly show execution flow	High	Execution chains are hard to trace; no source-to-egress visual narrative
3	Ingestion model is batch-correlated, not entity-first	Medium	Connector pre-correlates; platform can't do incremental updates or cross-connector correlation
4	No separation of business process from technical identity	Medium	Client_id rotation breaks execution chain continuity; no stable business-level concept

These gaps don't require starting over — they require targeted architectural evolution on top of what exists.

Part 1: What the Vision Says

Core Mission (from `0 vision summary.md`)

"Who (or what) is executing actions inside the enterprise, on what authority, and why is that execution still allowed — especially after human responsibility has changed or disappeared?"

Six Value Pillars

Execution graph reconstruction — Build a cross-system graph from human request → agent → auth → data
Structural risk & ownership decay — Detect when accountability weakens
Scope drift — Detect when permissions/data access expands without approval
Intent drift — Detect semantic hijacking (valid identity, shifted behavior)
Blast radius — Show reachable attack paths before exploitation
Audit-grade evidence — Deterministic, tamper-proof, explainable

PRD Phase 1 Requirements (7 items)

Static automation inventory (BR, SI, Flow, Job)
Identity binding (automation → SP via OAuth chain)
Execution detection (proof of actual execution)
Data egress classification (where data goes)
Data origin classification (what data is touched)
Ownership validation (who is accountable)
Risk-based grouping (RG1-RG5 triage)

Key insight: The PRD puts automation as the primary object. Requirements 1-7 are all "per automation" outputs. The automation IS the unit of analysis.

Part 2: What's Actually Delivered

Platform (sv0-platform)

Component	Status	Notes
Ingestion pipeline	Complete	NormalizedGraph → entities + evidence
Path materializer	Complete	BFS traversal, cross-system auth chains
Evaluator (5 rules)	Complete	orphaned_ownership, dormant_authority, scope_drift, privilege_justification_gap, unresolved_cross_system_auth
Evidence packs	Complete	9 sections, SHA256 sealed, Markdown export
API (20+ endpoints)	Complete	Findings, entities, paths, graph subgraph, syncs
Worker pipeline	Complete	Async sync_ingestion, evaluate_findings, build_evidence_pack
Storage (MongoDB)	Complete	12 collections, 40+ indexes

UI (7 screens)

Screen	Status	Focus
Dashboard	Complete	Finding severity cards
Findings List	Complete	Finding-centric table with filters
Finding Detail	Complete	Evidence pack viewer
Graph Explorer	Complete	Browse + Focus modes (Neighborhood + Execution Flow)
Entity Detail	Complete	5 tabs (Properties, Graph, Timeline, Ownership, Findings)
Entities List	Complete	Generic entity table
Temporal Compare	Complete	Side-by-side diff
Syncs	Complete	Connector sync history

Connector (entra-servicenow)

Feature	Status	Notes
BR/SI/Job discovery	Complete	All three automation types
Flow Designer	Complete	T1-A addition
ExecutionChain correlation	Complete	BR→REST→OAuth→SP
T1-D Egress classification	Complete	LLM/external/internal/unknown
T1-E Origin classification	Complete	First-party table references
T1-F Ownership validation	Complete	valid/invalid/ambiguous
T1-G Risk grouping	Complete	RG1-RG5 matrix
NormalizedGraph submission	Complete	POST to platform API

Part 3: Gap Analysis — Where Vision and Delivery Diverge

GAP 1: UI is Findings-Centric, Not Automation-Centric

The problem: The PRD says "detect automation" is Requirement #1 — automation is the primary object. But the UI starts with a Findings Dashboard (severity cards), not an Automations View. A user's first question is "show me my automations and their risk" — the current UI answers "here are governance gaps grouped by severity."

What a CISO wants to see first:

┌──────────────────────────────────────────────────────────────────┐
│  AUTOMATIONS OVERVIEW                                             │
│                                                                   │
│  47 automations discovered across 2 systems                       │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐            │
│  │ 12 BRs  │  │  8 SIs  │  │ 15 Flows│  │ 12 Jobs │            │
│  └─────────┘  └─────────┘  └─────────┘  └─────────┘            │
│                                                                   │
│  Risk Summary:  3 RG1 (P0)  │  5 RG2 (P1)  │  12 RG3  │  27 RG4│
│                                                                   │
│  ┌─────────────────────────────────────────────────────────────┐  │
│  │ Name          │ Type │ Bound? │ Egress  │ Origin │ Owner │ RG│
│  │───────────────┼──────┼────────┼─────────┼────────┼───────┼───│
│  │ HR Onboarding │ Flow │ bound  │ external│ HR     │ ⚠ inv │RG2│
│  │ Ticket Router │ BR   │ bound  │ external│ IT     │ ⚠ inv │RG2│
│  │ CMDB Sync     │ Job  │ bound  │ internal│ IT     │ ✓ val │RG4│
│  │ Notify Oncall │ SI   │ unlink │ unknown │ unknwn │ ✓ val │RG5│
│  └─────────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────┘

What exists today: The entities list shows ALL entity types (identity, owner, role, permission, resource, credential). To see "automations" you'd filter to entity_type=identity and then try to figure out which ones are automations from their subtypes. There's no aggregated automation view, no per-automation PRD output summary.

What's missing:

Automations Page — a dedicated view showing only automation entities (BR, SI, Flow, Job) with columns for all 7 PRD requirement outputs
Automation Detail Page — a combined view for one automation showing: identity binding chain, execution evidence, egress/origin/ownership status, risk group, and associated findings
Dashboard redesign — The first screen should orient around automations and their risk distribution, not just finding counts

Proposed changes:

Change	Scope	Priority
New `AutomationsPage` with PRD-aligned columns	UI	Must-have
New `AutomationDetailPage` combining evidence across all 7 requirements	UI	Must-have
Dashboard redesign: automation count cards + risk group distribution	UI	Should-have
Filter Entities page to default to automation subtypes	UI	Quick win

GAP 2: Graph Doesn't Clearly Show Execution Flow

The problem: The graph uses a generic hierarchical DAG layout (Identity → Role → Permission → Resource). While Execution Flow mode exists, it has several issues:

No visual narrative from trigger to egress — The user wants to see: "This BR fires on incident insert → calls REST Message → authenticates via OAuth → reaches Azure Graph API." The current graph shows this as disconnected node types in columns, not as a directed story.
Two parallel paths rendered identically — Each automation has TWO paths:
- Authority path (what can it do): Automation → RUNS_AS → SP → HAS_ROLE → Role → GRANTS → Permission → APPLIES_TO → Resource
- Provenance path (how does it get there): Automation → EXECUTES_ON → REST Message → AUTHENTICATES_VIA → OAuth
Both are shown as the same kind of edge in the same graph. Users can't distinguish "what can it access" from "how does it authenticate."
Order of events is unclear — The left-to-right Dagre layout sorts by graph topology, not by temporal or causal sequence. The trigger (what starts the automation) should be on the far left, the egress endpoint on the far right. Currently, the column assignment is by entity type, not by position in the execution chain.
No source-to-egress view — Users want to trace: "data enters from THIS table, flows through THIS automation, exits to THIS endpoint." This is the PRD's origin (#5) → automation (#1) → egress (#4) pipeline. No view shows this end-to-end.

Proposed visualization options:

Option A: Swimlane Layout (Recommended)

┌─────────────────┐  ┌─────────────────┐  ┌──────────────────┐
│   DATA SOURCE   │  │   AUTOMATION    │  │   EGRESS TARGET  │
│   (ServiceNow)  │  │   (Processing)  │  │   (Destination)  │
│─────────────────│  │─────────────────│  │──────────────────│
│                 │  │                 │  │                  │
│  ┌───────────┐  │  │  ┌───────────┐  │  │  ┌────────────┐ │
│  │ incident  │──┼──┼─▸│ BR: notif │──┼──┼─▸│ graph.ms   │ │
│  │ table     │  │  │  │ on-call   │  │  │  │ .com/v1.0  │ │
│  │ (trigger) │  │  │  └─────┬─────┘  │  │  │ (external) │ │
│  └───────────┘  │  │        │        │  │  └────────────┘ │
│                 │  │   RUNS_AS       │  │                  │
│                 │  │        │        │  │                  │
│                 │  │  ┌─────▼─────┐  │  │                  │
│                 │  │  │ SP: sn-   │  │  │                  │
│                 │  │  │ integratn │  │  │                  │
│                 │  │  │ (Entra)   │  │  │                  │
│                 │  │  └───────────┘  │  │                  │
└─────────────────┘  └─────────────────┘  └──────────────────┘
         │                                         │
    DATA ORIGIN                              DATA EGRESS
    domain: it_ops                      category: external
    sensitivity: internal               host: graph.microsoft.com

Pros: Matches the mental model of "data flows from source through automation to destination." Maps directly to PRD requirements #5 (origin), #1 (automation), #4 (egress). Clear visual narrative.

Cons: Requires custom layout logic beyond Dagre. More complex to implement.

Option B: Annotated Dagre with Path Highlighting

Keep the current Dagre layout but add:

Path highlighting: Click an automation → highlight the complete chain from trigger table to egress endpoint
Edge labels: Show relationship type on edges (TRIGGERS_ON, RUNS_AS, AUTHENTICATES_TO, etc.)
Lane annotations: Light background bands labeling sections: "Data Source", "Automation", "Identity", "Authority", "Target"
Provenance vs. Authority edge styling: Dashed lines for provenance (EXECUTES_ON, AUTHENTICATES_VIA), solid for authority (HAS_ROLE, GRANTS)

Pros: Minimal layout changes. Leverages existing Dagre infrastructure.

Cons: Still column-by-type, not column-by-flow-position. Less intuitive.

Option C: Dual-Pane View

Split the screen:

Left pane: Simplified automation flow diagram (trigger → automation → egress), always showing the "business story"
Right pane: Full authority graph (current Dagre layout) for the selected automation

Pros: Separates the two mental models (business flow vs. technical authority). Each pane can be optimized independently.

Cons: Screen real estate. Mobile unfriendly. Two graphs to maintain.

Option D: Automation Flow Diagram (non-graph)

For the automation detail page, render a simple step-by-step flow diagram instead of a graph:

┌──────────┐    ┌───────────┐    ┌──────────────┐    ┌─────────────┐    ┌──────────────┐
│ TRIGGER  │──▸│ AUTOMATION│──▸│ CALLS        │──▸│ AUTH AS     │──▸│ CAN ACCESS   │
│          │    │           │    │              │    │            │    │              │
│ incident │    │ BR: notif │    │ REST: Azure  │    │ SP: sn-int │    │ 12 resources │
│ (insert) │    │ oncall    │    │ Graph Query  │    │ (Entra)    │    │ 4 sensitive  │
│          │    │           │    │              │    │            │    │              │
│ Origin:  │    │ Execution:│    │ Egress:      │    │ Owner:     │    │ Blast radius:│
│ it_ops   │    │ 142/30d   │    │ external     │    │ ⚠ invalid  │    │ HR, IT, User │
└──────────┘    └───────────┘    └──────────────┘    └─────────────┘    └──────────────┘

Pros: Most readable. Non-technical users understand immediately. Maps 1:1 to PRD flow. Can be rendered as a simple React component without ReactFlow.

Cons: Doesn't show the full graph complexity. Complementary to graph, not a replacement.

Recommendation: Implement Option D (flow diagram) on the Automation Detail Page for clarity, and Option B (annotated Dagre with path highlighting) on the Graph Explorer for investigation depth. Consider Option A as a future evolution.

GAP 3: Ingestion Model — Batch-Correlated, Not Entity-First

The problem: The current ingestion model has the connector do all correlation:

CURRENT:
  Connector discovers → Connector correlates (ExecutionChain) → Connector transforms (NormalizedGraph) → Platform ingests batch

DESIRED:
  Connector discovers → Platform receives individual entities → Platform correlates → Platform re-evaluates on any change

Why this matters:

No incremental updates — If one BR changes, the connector must re-run the full discovery and submit the entire NormalizedGraph. There's no way to update just one entity.
No cross-connector correlation — If Entra and ServiceNow are separate connectors in the future, who correlates SP → OAuth? Currently it's the "entra-servicenow" combined connector. With entity-first ingestion, the platform would correlate entities from different connectors by matching fields (client_id).
No webhook-driven updates — ServiceNow and Azure both support webhooks for change notifications. Entity-first ingestion would allow receiving a webhook saying "BR xyz changed" and updating just that entity, then re-computing affected paths.
Connector coupling — The connector has to know about ALL entity types it discovers and their relationships. Adding a new automation type requires changing the correlator + transformer. With entity-first, adding a new type means just discovering it and submitting it — the platform handles correlation.

Current architecture (batch-correlated):

ServiceNow API ──→ servicenow_client.py ──→ correlator.py ──→ transformer.py ──→ NormalizedGraph
Azure API ─────→ azure_client.py ────────┘                                         │
                                                                                    ▼
                                                                          POST /ingest/normalized-graph
                                                                                    │
                                                                                    ▼
                                                                          platform: ingest → diff → store → evaluate

Target architecture (entity-first):

ServiceNow API ──→ Entity Discovery ──→ POST /ingest/entities (BR, SI, Flow, Job, REST Message, OAuth Entity, Users)
                                                    │
Azure API ──→ Entity Discovery ──→ POST /ingest/entities (SP, App Registration, Owners, Roles)
                                                    │
                                                    ▼
                                          Platform: Store entities by source_system + source_id
                                                    │
                                                    ▼
                                          Platform: Correlate (client_id match → AUTHENTICATES_TO)
                                                    │
                                                    ▼
                                          Platform: Materialize execution paths
                                                    │
                                                    ▼
                                          Platform: Evaluate findings

Migration path:

This is already planned as Track 2 in the Phase 1 Deltas Plan. The correlator.py already has DiscoveredEntities + EdgeResolver framework for this. The question is: should Track 2 be pulled forward, or should it remain post-pilot?

Recommendation: Keep Track 2 timing (after pilot) but design the platform-side correlation API now so Track 2 implementation is smooth. Specifically:

Design Now	Implement Track 2
Entity correlation matching rules (client_id → AUTHENTICATES_TO)	Platform correlator service
Incremental entity update API contract	POST /ingest/entity (single entity)
Webhook receiver contract	Webhook adapter per source system
Cross-connector correlation logic	Platform-side edge resolution

GAP 4: No Separation of Business Process from Technical Identity

The problem (user's exact concern):

"If client_id changes in Azure, from technical perspective it will be completely new execution, but from business perspective — nothing really changes. How to solve this."

Why this happens: The current model ties execution chains to technical identifiers:

Automation = BR sys_id (stable within ServiceNow)
Identity binding = OAuth client_id match (breaks on rotation)
SP identity = Azure object_id (breaks on SP recreation)

When any link in the chain breaks (client_id rotated, SP recreated, OAuth app replaced), the entire execution chain appears as a "new" one — even though the business process hasn't changed.

Analysis of what changes at each level:

Change	Technical Impact	Business Impact	Current Handling
OAuth client_secret rotates	None (same client_id)	None	Handled — same entity
OAuth client_id changes	New AUTHENTICATES_TO edge	None — same BR, same purpose	Breaks — old chain dead, new chain created
SP recreated in Azure	New SP entity	None — same integration	Breaks — new SP, orphaned old SP
BR replaced by Flow	New automation entity	None — same business process	Breaks — no linkage between old BR and new Flow
BR table changes	New TRIGGERS_ON edge	Business flow changed	Correctly detected as change
REST Message endpoint changes	New egress target	Egress changed	Correctly detected as change

Proposed solution: Business Automation concept

Introduce a Business Automation as a stable, user-facing concept that groups technical artifacts:

┌─────────────────────────────────────────────┐
│ Business Automation: "HR Onboarding Sync"   │
│ (stable identifier, user-defined or auto)   │
│                                             │
│ Current Implementation:                     │
│   ├── Flow: HR_Onboarding_v3 (active)       │
│   ├── Runs as: SP sp-hr-onboarding          │
│   └── Egress: graph.microsoft.com           │
│                                             │
│ Previous Implementations:                   │
│   ├── BR: hr_sync_br (replaced 2025-09)     │
│   └── SP: sp-hr-old (rotated 2025-11)       │
│                                             │
│ Continuity: Same table (incident), same     │
│ destination, owner lineage preserved        │
└─────────────────────────────────────────────┘

How Business Automations would be established:

Method	Deterministic?	Phase
Manual grouping — User groups technical artifacts into a business automation	Yes	Phase 1 — simplest
Same-table + same-endpoint matching — Automations triggering on the same table and calling the same REST Message are candidates for grouping	Deterministic (same config fields)	Phase 2
Credential lineage — When a credential rotates (same oauth_entity sys_id, new client_id), the old and new chains are the same business automation	Deterministic (same sys_id)	Phase 2
Naming heuristic — "HR_Onboarding_v1" and "HR_Onboarding_v2" are likely the same	Heuristic — out of scope	Never (violates deterministic constraint)

Key insight for credential rotation: The ServiceNow oauth_entity record has a stable sys_id even when client_id changes. If the platform tracks oauth_entity.sys_id as the stable binding point (not just client_id), credential rotation becomes a property update rather than a chain break.

Implementation approach:

Near-term (Phase 1): Track oauth_entity.sys_id as an additional matching field alongside client_id. When client_id changes but sys_id is the same, treat as credential rotation event, not new chain.
Mid-term (Track 2): Add Business Automation entity type. Allow manual grouping via UI. Auto-suggest groups based on table + endpoint matching.
Long-term: Build business automation continuity tracking — show the lineage of how a business process's technical implementation evolved over time.

Part 4: Architectural Improvement Proposals

Proposal 1: Platform-Side Correlation Engine

Current: Connector correlates → Platform stores. Target: Connector discovers → Platform correlates + stores.

// New: Platform correlation rules (deterministic)
interface CorrelationRule {
  name: string;
  sourceEntityType: string;
  targetEntityType: string;
  matchFields: Array<{
    sourceField: string;   // path in source entity properties
    targetField: string;   // path in target entity properties
    matchType: 'exact' | 'case_insensitive';
  }>;
  producesEdge: NormalizedEdgeType;
  edgeProperties?: Record<string, unknown>;
}

// Example: client_id matching
const oauthCorrelation: CorrelationRule = {
  name: 'azure_sp_to_sn_oauth',
  sourceEntityType: 'service_principal',
  targetEntityType: 'oauth_app',
  matchFields: [{
    sourceField: 'properties.appId',
    targetField: 'properties.client_id',
    matchType: 'case_insensitive'
  }],
  producesEdge: 'AUTHENTICATES_TO',
  edgeProperties: { auth_protocol: 'oauth2' }
};

Benefits:

Connectors become simpler (pure discovery)
Cross-connector correlation becomes possible
Incremental entity updates automatically trigger re-correlation
New correlation rules can be added without changing connectors

Proposal 2: Incremental Entity API

// New endpoint: submit individual entities
POST /api/v1/ingest/entity
{
  connectorId: string;
  tenantId: string;
  entity: NormalizedNode;
  relationships: NormalizedEdge[];  // known edges from this connector
}

// New endpoint: webhook-style entity update
POST /api/v1/ingest/entity-update
{
  connectorId: string;
  tenantId: string;
  sourceSystem: string;
  sourceId: string;
  changes: {
    properties?: Partial<Record<string, unknown>>;
    status?: NodeStatus;
    relationships?: {
      added?: NormalizedEdge[];
      removed?: string[];  // edge IDs to remove
    };
  };
}

Benefits:

Enables webhook-driven updates
Reduces connector sync time (only changed entities)
Supports rate-limit-friendly continuous scanning

Proposal 3: Automation-First UI Architecture

New page hierarchy:

Dashboard (automation-centric)
├── Automations List (primary view — PRD requirements as columns)
│   └── Automation Detail (flow diagram + PRD outputs + findings + graph)
├── Findings List (secondary — governance gaps)
│   └── Finding Detail (evidence pack)
├── Graph Explorer (investigation tool)
├── Entities List (technical explorer — for power users)
│   └── Entity Detail
├── Syncs
└── Temporal Compare

Dashboard redesign:

┌─────────────────────────────────────────────────────────────────┐
│ AUTOMATION RISK OVERVIEW                                         │
│                                                                  │
│ ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐        │
│ │ 47 Total │  │ 3 RG1/P0 │  │ 5 RG2/P1 │  │ 8 Issues │        │
│ │ automtns │  │ Critical │  │ High     │  │ No Owner │        │
│ └──────────┘  └──────────┘  └──────────┘  └──────────┘        │
│                                                                  │
│ ┌──────────────────────┐  ┌──────────────────────────────────┐  │
│ │ By Type              │  │ By Risk Group                    │  │
│ │ ████ 12 BR           │  │ ███ RG1 Sensitive→LLM (3)       │  │
│ │ ███ 8 SI             │  │ █████ RG2 Sensitive→Ext (5)     │  │
│ │ █████ 15 Flow        │  │ ████████ RG3 Non-sens→Ext (12)  │  │
│ │ ████ 12 Job          │  │ ████████████████ RG4 Internal    │  │
│ └──────────────────────┘  └──────────────────────────────────┘  │
│                                                                  │
│ PRIORITY AUTOMATIONS (RG1 + RG2 with findings)                  │
│ ┌───────────────────────────────────────────────────────────┐   │
│ │ Automation    │ Type │ Egress  │ Origin │ Owner │ Findngs │   │
│ │ HR Onboarding │ Flow │ extern │ HR     │ ⚠ inv │ 3 crit  │   │
│ │ ...           │      │        │        │       │         │   │
│ └───────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

Proposal 4: Change Detection Model for Execution Continuity

Problem: How to decide if two different technical configurations represent the "same" automation.

Decision model (deterministic):

Level 1: Same automation artifact (same sys_id)
  → Always same automation. Property changes are updates.
  → Credential rotation, role changes = events, not new chain.

Level 2: Same OAuth entity (same oauth_entity.sys_id, different client_id)
  → Same integration binding. Client_id change = credential rotation event.
  → Preserve AUTHENTICATES_TO edge, update properties.

Level 3: Same SP (same Azure object_id, different credentials)
  → Same identity. Secret/cert rotation = credential event.
  → Preserve HAS_ROLE relationships.

Level 4: Different SP (new Azure object_id, same business intent)
  → THIS is where "Business Automation" grouping is needed.
  → Without grouping: treated as new chain (correct technically).
  → With grouping: shown as "implementation change" on same business automation.

Implementation:

// Track stable identifiers at each level
interface AutomationContinuityKeys {
  // Level 1: Automation artifact
  automation_sys_id: string;         // BR/Flow/Job sys_id — most stable

  // Level 2: OAuth binding
  oauth_entity_sys_id?: string;      // SN oauth_entity sys_id — survives client_id rotation

  // Level 3: Identity
  azure_sp_object_id?: string;       // Azure SP object_id

  // Level 4: Business grouping (user-defined or auto-suggested)
  business_automation_id?: string;   // Stable cross-artifact identifier
}

Part 5: Execution Plan

Phase A: Automation-Centric UI (2-3 days)

Priority: Must-have for pilot demo

Task	File	Effort
New `AutomationsPage` with PRD-aligned columns	`ui/src/pages/AutomationsPage.tsx`	1 day
New `AutomationDetailPage` with flow diagram	`ui/src/pages/AutomationDetailPage.tsx`	1 day
Dashboard redesign (automation cards + risk groups)	`ui/src/pages/Dashboard.tsx`	0.5 day
API: filter entities by identity subtypes	`src/api/routes/entities.ts`	0.5 day
Navigation update (Automations as primary nav item)	`ui/src/App.tsx`	Quick

Key API query for Automations page:

GET /api/v1/entities?entity_type=identity&identity_subtype=business_rule,script_include,flow_designer_flow,scheduled_job

This uses the existing entities endpoint with a new filter for identity_subtype. Each automation entity already has egress_category, data_domains, risk_group, ownership_status, identity_binding_status, execution_count_30d in its properties (from Track 1 work).

Phase B: Graph Visualization Improvements (2-3 days)

Task	File	Effort
Automation flow diagram component (Option D)	`ui/src/components/AutomationFlowDiagram.tsx`	1 day
Edge type styling (solid=authority, dashed=provenance)	`ui/src/components/graph/GraphCanvas.tsx`	0.5 day
Path highlighting on automation select	`ui/src/components/graph/GraphCanvas.tsx`	0.5 day
Lane background annotations	`ui/src/components/graph/layout.ts`	0.5 day
Edge labels for relationship types	`ui/src/components/graph/GraphCanvas.tsx`	0.5 day

Phase C: Ingestion Architecture Design (1-2 days, design only)

Task	Output	Effort
ADR: Platform-Side Correlation Engine	`docs/architecture/decisions/adr-NNN-platform-correlation.md`	0.5 day
ADR: Incremental Entity API	`docs/architecture/decisions/adr-NNN-incremental-ingestion.md`	0.5 day
Design: Webhook receiver contract	`docs/architecture/08-webhook-ingestion.md`	0.5 day

Note: Implementation is Track 2. Design now to unblock Track 2 execution.

Phase D: Continuity Model (1 day, design + partial implementation)

Task	Output	Effort
Track `oauth_entity.sys_id` as stable binding key	Connector change	0.5 day
ADR: Business Automation concept	`docs/architecture/decisions/adr-NNN-business-automation.md`	0.5 day
Design: manual grouping UI (for future)	Design doc	Deferred

Part 6: Prioritization Matrix

Change	Impact on Pilot	Effort	Priority
Automations page (UI)	Critical — directly shows PRD outputs	Medium	P0
Automation detail with flow diagram (UI)	High — visual story for CISO	Medium	P0
Dashboard redesign (UI)	High — first impression	Low	P1
Graph path highlighting	Medium — investigation quality	Low	P1
Graph edge styling (authority vs provenance)	Medium — readability	Low	P2
ADRs for architecture evolution	Low — planning	Low	P2
Incremental entity API	Low — post-pilot	Medium	Track 2
Platform correlation engine	Low — post-pilot	High	Track 2
Business Automation grouping	Low — post-pilot	High	Track 2
oauth_entity.sys_id tracking	Medium — prevents false chain breaks	Low	P1

Part 7: Summary of Must-Change vs. Should-Change vs. Future

Must Change (for pilot)

Add Automations page — Direct PRD alignment. Shows all 7 requirement outputs per automation.
Add Automation detail page — Visual flow from trigger → automation → egress → resources.
Reframe Dashboard — Automation-centric, not just finding-centric.

Should Change (before design partner demo)

Graph: edge type styling — Distinguish authority from provenance paths.
Graph: path highlighting — Click automation → see full chain highlighted.
Track oauth_entity.sys_id — Prevent false chain breaks on credential rotation.
Automation flow diagram component — Simple, non-graph visual for non-technical users.

Future (Track 2 / post-pilot)

Platform-side correlation engine — Decouple connector from correlation logic.
Incremental entity API — Enable webhook-driven updates.
Business Automation concept — Stable grouping across technical changes.
Swimlane graph layout — Source → Processing → Destination visual model.
Cross-connector correlation — Enable separate Entra + ServiceNow connectors.

Appendix: PRD Requirement Coverage Mapping

PRD Req	Vision Pillar	Connector	Platform Storage	Evaluator	UI Display	Gap
#1 Automation inventory	Execution graph	✅ All 4 types	✅ Stored as identity subtypes	N/A	⚠️ No dedicated view	Automations page needed
#2 Identity binding	Execution graph	✅ SP matching	✅ AUTHENTICATES_TO edges	N/A	⚠️ Only in graph	Show on automation detail
#3 Execution detection	Execution graph	✅ Bound/unlinked	✅ Execution evidence collection	✅ dormant_authority	⚠️ No per-automation view	Show on automation detail
#4 Egress classification	Blast radius	✅ LLM/ext/int/unk	✅ Entity properties	N/A	⚠️ Only in entity properties tab	Show as column + badge
#5 Origin classification	Blast radius	✅ Table→domain	✅ Entity properties	N/A	⚠️ Only in entity properties tab	Show as column + badge
#6 Ownership validation	Ownership decay	✅ valid/invalid/ambiguous	✅ Entity properties	✅ orphaned_ownership	⚠️ Only via findings	Show as column + badge
#7 Risk grouping	Blast radius	✅ RG1-RG5	✅ Entity properties	N/A	⚠️ Not visible anywhere	Show as column + badge + dashboard

Key finding: All 7 requirements are satisfied at the connector and storage level. The gap is entirely in UI presentation — the data exists but isn't surfaced in an automation-centric way.

Executive Summary​

Part 1: What the Vision Says​

Core Mission (from 0 vision summary.md)​

Six Value Pillars​

PRD Phase 1 Requirements (7 items)​

Part 2: What's Actually Delivered​

Platform (sv0-platform)​

UI (7 screens)​

Connector (entra-servicenow)​

Part 3: Gap Analysis — Where Vision and Delivery Diverge​

GAP 1: UI is Findings-Centric, Not Automation-Centric​

GAP 2: Graph Doesn't Clearly Show Execution Flow​

Option A: Swimlane Layout (Recommended)​

Option B: Annotated Dagre with Path Highlighting​

Option C: Dual-Pane View​

Option D: Automation Flow Diagram (non-graph)​

GAP 3: Ingestion Model — Batch-Correlated, Not Entity-First​

GAP 4: No Separation of Business Process from Technical Identity​

Part 4: Architectural Improvement Proposals​

Proposal 1: Platform-Side Correlation Engine​

Proposal 2: Incremental Entity API​

Proposal 3: Automation-First UI Architecture​

Proposal 4: Change Detection Model for Execution Continuity​

Part 5: Execution Plan​

Phase A: Automation-Centric UI (2-3 days)​

Phase B: Graph Visualization Improvements (2-3 days)​

Phase C: Ingestion Architecture Design (1-2 days, design only)​

Phase D: Continuity Model (1 day, design + partial implementation)​

Part 6: Prioritization Matrix​

Part 7: Summary of Must-Change vs. Should-Change vs. Future​

Must Change (for pilot)​

Should Change (before design partner demo)​

Future (Track 2 / post-pilot)​

Appendix: PRD Requirement Coverage Mapping​