Execution Flow Analysis — Team Synthesis Report
Date: 2026-02-12 (Round 2) Team: automation-analysis (5 agents) Core Question: How should the platform display the full execution flow of automations, and how should it handle the identity vs. automation labeling confusion?
Team Participants
| Role | Model | Key Contribution |
|---|---|---|
| Product Owner | opus | Layered disclosure model (3 levels), 5 user stories, P0/P1/P2 phasing |
| Architect | opus | CALLS edge semantics, 9-layer graph layout, path materializer impact, "keep entity_type: identity" decision |
| CISO | opus | 6 security blind spots mapped to SOC2/ISO controls, setWorkflow(false) threat models, 7 display principles |
| Integrator | sonnet | CALLS edge emission code, trigger record modeling, MODIFIES edge for mutations, "automation_disabled" ground truth |
| Developer | sonnet | Full stack code changes (28h estimate), component specs, testing strategy, rollout plan |
1. Unanimous Agreements (All 5 Roles Aligned)
A. Keep entity_type: identity — Fix Labels in UI Only
All 5 roles agree: Do NOT add a new entity_type: "automation". The existing identitySubtype system already provides the taxonomy. The fix is display-only — show subtype-specific labels instead of the generic "identity" badge.
| Role | Position |
|---|---|
| Product Owner | "Replace 'identity' badge with subtype-specific labels (BR, Flow, SI, Job, SP)" |
| Architect | "entity_type is a storage-level discriminator, identitySubtype is semantic. Use each at the right layer" |
| CISO | "A script include labeled 'identity' causes the wrong review framework to be applied — but the fix is UI, not schema" |
| Integrator | "Script includes are autonomous_identity in the data model. The label confusion is presentation-only" |
| Developer | "Derive display label from identitySubtype in EntityBadge.tsx — 2 hours, zero schema risk" |
Action: Update EntityBadge.tsx to show identitySubtype-derived labels. Effort: 2 hours. P0.
B. Add CALLS Relationship Type for BR→SI Invocation
All 5 roles agree: The connector already builds BR→SI CALLS edges internally. They must be emitted in the NormalizedGraph and traversed by the platform.
| Role | Position |
|---|---|
| Product Owner | "CALLS is a forward execution edge, distinct from EXECUTES_ON (targets a resource) and RUNS_AS (delegates identity)" |
| Architect | "Add CALLS to the 15th relationship type. Emit from connector. Follow in path materializer like RUNS_AS" |
| CISO | "Without explicit invocation edges, you cannot assess the entry-point-to-code chain" |
| Integrator | "correlator.py already builds CALLS edges at line 545-557. transformer.py needs ~6 lines to emit them" |
| Developer | "Stack-wide change: types.ts + relationship-types.ts + connector + layout.ts. Total: 3 hours" |
Action: Add CALLS to all type definitions, emit from connector, add to graph layout. Effort: 3 hours. P0.
C. Layered Disclosure — Not Simplification
All 5 roles agree: The UI should show a simplified summary by default AND the full chain on demand. Never hide data permanently.
| Level | What | Who | PO | Architect | CISO |
|---|---|---|---|---|---|
| L1: Summary | 4-5 cards: Trigger→Automation→Auth→Destination→Data Domain | CISO, demo, executive | Default | Default | "Dashboard view" |
| L2: Full Chain | All entities grouped by type (BR, SI, REST, OAuth, SP, effects) | Security analyst | Toggle | Toggle | "Audit view" |
| L3: Graph | Interactive ReactFlow visualization | Power user | Tab | Tab | "Investigation view" |
Action: L1 exists (AutomationFlowDiagram). Fix trigger card + add toggle for L2. Effort: 3-5 hours. P0.
D. Business Rules MUST Be Visible
All 5 roles agree: The business rules are the autonomous entry points — they must appear in the flow when viewing a Script Include.
| Role | Position |
|---|---|
| Product Owner | "TRIGGER card says 'Unknown' for SIs — must show the BRs that call this SI and their trigger tables" |
| Architect | "The BFS should return BRs via reverse CALLS traversal from SI seed" |
| CISO | "Cannot assess an execution chain without knowing its entry points. P1 CRITICAL." |
| Integrator | "Both BRs are already in graph.json. The platform just needs to query them and the UI needs to display them" |
| Developer | "AutomationFlowDiagram needs to follow CALLS edges backward to find the BR, then show BR's TRIGGERS_ON" |
Action: Fix AutomationFlowDiagram to resolve trigger from upstream BRs. Effort: 3-4 hours. P0.
2. Key Agreements with Nuance
E. setWorkflow(false) Is a Security Signal
CISO and Integrator agree strongly. Developer and Architect agree it should be surfaced. Product Owner wants it in L2, not L1.
- CISO: "This is a detection evasion signal. It suppresses all downstream business rules, approval workflows, and notifications for the record update. SOC monitoring assumptions are violated."
- Integrator: "The connector already detects this via
_RE_WORKFLOW_SUPPRESSEDregex inanalyze_script_mutations(). It just doesn't propagate to the NormalizedGraph." - Product Owner: "Show as a warning badge on the EFFECTS card in L1 summary, full detail in L2."
- Architect: "Store as property on automation node for now (MVP). MODIFIES edge with
workflow_suppressed: truefor production."
Action: Propagate workflow_suppression from connector to node properties. Add warning badge. Effort: 2 hours. P1.
F. Record Changes / Mutations Need Visibility
All 5 agree on need, but differ on modeling:
| Approach | Advocate | Pros | Cons |
|---|---|---|---|
| Node properties (MVP) | Integrator, Developer | Zero schema changes, fast | Not queryable as relationships |
| MODIFIES edge (production) | Architect, Integrator | First-class queryable, blast radius analysis | Needs new edge type |
| Effects tab (UI) | Developer, PO | Clean UX, grouped by table | Doesn't affect graph |
| Finding rule | CISO | Fires when suppression + orphaned SP detected | Requires evaluator changes |
Consensus: Phase 1 = node properties + Effects tab. Phase 2 = MODIFIES edge + finding rule.
Action: P1: Emit local_mutations as node properties. P2: Add MODIFIES edge + evaluator rule. Effort: 4 hours P1, 7 hours P2.
G. Trigger Records — Properties, Not Nodes
All 5 agree: Trigger records should NOT become graph nodes (would create hundreds of ephemeral nodes). Store as properties on the BR node.
Integrator caveat: "Trigger evidence is inferred, not proven. The connector queries recent records from the trigger table but doesn't verify they actually triggered the BR. Should set evidence_type: 'inferred_trigger_record'."
Action: Emit trigger_examples as BR node properties. Display in UI. Effort: 3 hours. P1.
3. The "automation_disabled" Finding
CISO flagged this as security-significant. Integrator confirmed it's NOT a standard ServiceNow system account.
- CISO: "An active business rule processing identity incidents, created by an account whose name contains 'disabled,' is itself a finding — regardless of the account's actual status."
- Integrator: "The connector defaults to
status: disabledwhen it can't find the user record. But the account might actually be active. Need to query sys_user for ground truth." - Product Owner: "New finding type: SUSPICIOUS_CREATOR_ACCOUNT. Fires when creator username matches suspicious patterns (disabled, test, temp, demo) AND the automation is in production."
Action: Enhance connector to fetch sys_user details for creators. Add finding rule. Effort: 4.5 hours. P2.
4. Graph Layout: 9-Layer Execution Model
Architect proposed, Developer implemented:
| Layer | Entity Types | Description |
|---|---|---|
| 0 | Trigger resources, owners | Tables/events that start the chain |
| 1 | Business Rules, Flows, Jobs | Trigger automations (fire on events) |
| 2 | Script Includes | Code artifacts (invoked by BRs) |
| 3 | REST Messages | Outbound call targets |
| 4 | OAuth apps, credentials | Authentication infrastructure |
| 5 | Service Principals | Cloud identities |
| 6 | Roles | Authority groupings |
| 7 | Permissions | Individual capabilities |
| 8 | Target resources | API endpoints, cloud resources |
AzureGraphRouter chain in new layout:
Layer 0 Layer 1 Layer 2 Layer 3 Layer 4 Layer 5
incident → BR: Auto-route → SI: Azure → REST: Graph → OAuth ← SP: sn-ticket-
(table) tickets via Entra GraphRouter sn-ticket-rou Client router
[TRIGGERS_ON] [CALLS] [EXECUTES_ON] [AUTH_VIA] [AUTH_TO]
Action: Update layout.ts with 9-layer model. Effort: 3 hours. P1.
5. Prioritized Action Items (Team Consensus)
P0: Before Next Demo (8-12 hours)
| # | Action | Effort | Owner |
|---|---|---|---|
| 1 | Fix entity labels — show identitySubtype instead of "identity" | 2h | Developer |
| 2 | Add CALLS relationship type (all stack layers) | 3h | Developer + Integrator |
| 3 | Fix flow diagram trigger card — resolve from upstream BRs | 3-4h | Developer |
| 4 | Add "Show full chain" toggle (Level 2 view) | 3-5h | Developer |
P1: This Sprint (10-14 hours)
| # | Action | Effort | Owner |
|---|---|---|---|
| 5 | Propagate setWorkflow(false) to node properties + warning badge | 2h | Integrator + Developer |
| 6 | Emit local_mutations as node properties + Effects tab | 4h | Integrator + Developer |
| 7 | Emit trigger_examples as BR properties + display section | 3h | Integrator + Developer |
| 8 | Update graph layout to 9-layer model | 3h | Developer |
| 9 | Data domain badges on graph nodes (Sergey feedback) | 1-2h | Developer |
P2: Next Sprint (12-16 hours)
| # | Action | Effort | Owner |
|---|---|---|---|
| 10 | Add MODIFIES edge type for mutation modeling | 7h | Architect + Integrator |
| 11 | suspicious_creator_account finding rule | 4.5h | Integrator + Developer |
| 12 | HTTP method details on REST message nodes | 4.5h | Integrator |
| 13 | Graph complexity budget (50-node cap with expand) | 2-3h | Developer |
| 14 | execution_data_availability property | 2h | Integrator |
Total: P0 = 11-14h, P1 = 13-17h, P2 = 20-26h
6. Compliance Impact (CISO Assessment)
The current display fails 5 of 5 assessed SOC2 controls for the AzureGraphRouter chain:
| Control | Status | Gap |
|---|---|---|
| CC6.1 (Access Controls) | CANNOT ATTEST | Entry points and record mutations invisible |
| CC6.3 (Access Revocation) | PARTIAL | Ownership visible but urgency not assessable |
| CC7.1 (Monitoring) | CANNOT ATTEST | setWorkflow(false) creates undetectable monitoring gap |
| CC7.2 (Incident Detection) | CANNOT ATTEST | Silent record changes bypass detection rules |
| CC8.1 (Change Management) | CANNOT ATTEST | BR creators and approval chain invisible |
After P0+P1 changes: All 5 controls become attestable through the layered disclosure model.
7. Key Design Principles (From CISO, Endorsed by All)
- Show the full chain, not just the forward path — if a step modifies state, it MUST be visible
- Show entry points, not just the called code — the BR is the security-relevant trigger, not the SI
- Flag detection-evasion patterns — setWorkflow(false), skip_hooks, audit suppression are first-class signals
- Data flow direction matters — read-only vs read-write changes the risk profile fundamentally
- Ownership provenance at every layer — creator of the BR, owner of the SP, each can decay independently
- Parallel paths must be visible — 2 BRs calling 2 SIs = 4 paths, not 1
- What you hide, you cannot govern — progressive disclosure (summary→detail), NEVER omission
8. Files Produced (Round 2)
| File | Role | Key Topics |
|---|---|---|
| 02-execution-flow-product-owner.md | Product Owner | Layered disclosure, user stories, Sergey feedback integration |
| 02-execution-flow-architect.md | Architect | CALLS semantics, 9-layer layout, path materializer, schema migration |
| 02-execution-flow-ciso.md | CISO | Security blind spots, compliance matrix, setWorkflow threats, 7 principles |
| 02-execution-flow-integrator.md | Integrator | CALLS emission code, trigger modeling, MODIFIES edge, backward compat |
| 02-execution-flow-developer.md | Developer | Stack-wide code specs, component designs, testing, 28h estimate |
| 02-execution-flow-synthesis.md | Lead | This document — team consensus and action items |
9. Answer to the Core Question
"How should AzureGraphRouter's full execution flow be shown?"
Before (current UI):
TRIGGER: Unknown → AUTOMATION: AzureGraphRouter (identity, SI) → CALLS: graph.microsoft.com → RUNS AS: sn-ticket-router → CAN ACCESS: 1 resource
After (P0 changes):
Level 1 (default):
TRIGGER: incident table (on insert, 2 BRs) → AUTOMATION: AzureGraphRouter (Script Include) → REST: graph.microsoft.com (External) → AUTH: sn-ticket-router (SP, Orphaned) → DATA: identity_platform
Level 2 (toggle):
[incident table] → [BR: Auto-route via Entra (admin)] → [SI: AzureGraphRouter] → [REST: graph.microsoft.com] → [OAuth Client] → [SP: sn-ticket-router (ORPHANED)]
→ [BR: Auto-route-Enta-no-own (automation_disabled⚠)] → [SI: AzureGraphRouterNoOwner]
EFFECTS: assignment_group, work_notes modified | setWorkflow(false) ⚠
Level 3 (graph tab):
Full 9-layer interactive visualization with CALLS edges, all nodes, execution flow layout
The platform shows everything the connector discovers. The default view is simple. The full chain is one click away. Nothing is hidden.
Round 2 analysis complete. 5 perspectives, ~185K tokens of research, synthesized into 14 prioritized actions across 3 sprints.