Automation Persistence — Team Synthesis Report

Date: 2026-02-13 (Round 3) Team: automation-analysis (5 agents) Core Question: Does the platform need a separate collection (or first-class entity concept) to track autonomous execution chains over time? If so, what form should it take?

---

Team Participants

Role	Model	Lines	Key Contribution
Product Owner	opus	976	7 user stories, scoring matrix, UI mockups, "automation as virtual entity" advocacy
Architect	opus	1338	Chain builder algorithm, fingerprint stability contract, Ship of Theseus analysis, execution_chains schema
CISO	opus	736	Compliance control mapping (SOC2/ISO/SOX), incident response walkthrough, chain-level zombie NHI analysis
Integrator	sonnet	1279	Platform vs connector responsibility, cross-connector stitching, incremental sync chain updates
Developer	sonnet	1431	Implementation matrix (4 options), effort estimates, testing strategy, concrete implementation plan

---

1. Unanimous Agreement: The Founder Is Right

All 5 roles confirm: The current data model cannot express an "automation chain" as a durable, trackable, listable concept. The data to reconstruct chains exists (entities, edges, temporal history), but three things are missing:

Gap	Description
Stable identity	No persistent ID for "this automation" that survives entity rotation
Chain-level diff	Cannot answer "what changed in this automation since last scan?"
Listable object	CISO cannot bookmark, filter, or search for an automation

Role	Position
Product Owner	"The current model cannot express 'this automation' as a durable, trackable concept"
Architect	"An automation chain is a higher-order concept — a named subgraph — that the current data model cannot address"
CISO	"The platform needs a lightweight execution_chains collection. This is not optional for audit readiness."
Integrator	"Chains are derived, not source entities. The platform must own assembly and stability."
Developer	"Option A (computed view) has a fatal temporal query performance trap — N queries per chain per temporal request"

---

2. Unanimous Agreement: Option A (Status Quo) Is Insufficient

All 5 roles reject keeping the current model with only computed views (no persistence).

Role	Reason for Rejection
Product Owner	"Can't list automations; can't bookmark; can't show history"
Architect	"Cannot list, track, or diff chains. No stable ID."
CISO	"Fails audit readiness. Cannot answer 'chain state at time T' without reconstructing ALL entities. Never tested, never validated."
Integrator	"Storage doesn't solve the identity problem — but NOT storing creates a query problem"
Developer	"Temporal queries require N point-in-time lookups (one per entity in chain). Performance unacceptable."

---

3. The Key Disagreement: Option B vs Option D

The team split on the implementation approach:

Option B: New execution_chains Collection (3 advocates)

Architect, CISO, Developer recommend a dedicated collection:

// execution_chains collection
{
  _id: "chain-uuid",
  tenant_id: "...",
  name: "AzureGraphRouter Incident Routing",
  anchor_entity_id: "uuid-of-business-rule",
  entity_refs: [
    { entity_id: "uuid-br", role: "entry_point" },
    { entity_id: "uuid-si", role: "executor" },
    { entity_id: "uuid-rest", role: "outbound_target" },
    { entity_id: "uuid-oauth", role: "auth_credential" },
    { entity_id: "uuid-sp", role: "destination_identity" }
  ],
  summary: {
    trigger: "incident table insert",
    destination: "graph.microsoft.com",
    egress_category: "external",
    blast_radius_domains: ["identity_platform"],
    ownership_status: "orphaned",
    total_roles: 4,
    max_sensitivity: "confidential"
  },
  composition_hash: "sha256:abc...",  // Fingerprint for change detection
  first_detected_at: ISODate("2026-02-12"),
  last_seen_at: ISODate("2026-02-13"),
  sync_version: 42
}

Why they prefer it:

• Architect: "Projection safety — wrong chain definition can be dropped and rebuilt. Zero risk to core data model."
• CISO: "Separate collection makes chains invisible to entity queries by default. Every new developer who queries entities must remember to filter chains in Option D. They won't."
• Developer: "Option B has the best effort-to-value ratio. 94 hours for Phase 1, clean separation, easy rollback (drop collection)."

Option D: Virtual Entity (entity_type: "execution_chain") (1 advocate)

Product Owner recommends adding chains to the existing entities collection:

// In entities collection
{
  _id: "chain-uuid",
  entity_type: "execution_chain",  // New type
  source_system: "sv0_platform",
  relationships: [
    { type: "CONTAINS", target_id: "uuid-br", properties: { role: "entry_point" } },
    { type: "CONTAINS", target_id: "uuid-si", properties: { role: "executor" } },
    ...
  ]
}

Why PO prefers it:

• "Respects ADR-002 (single entities collection)"
• "Uses existing temporal machinery (entity_versions, events, baselines) — zero new infrastructure"
• "Chains appear naturally in the graph with CONTAINS edges"
• "Best Neo4j compatibility — chains become nodes in the graph"

Integrator Position: Neutral, Leans B

The Integrator focused on connector architecture and recommends platform-side chain assembly regardless of storage choice. Leans toward Option B because "chains are derived, not source entities."

Resolution: Team Recommends Option B

Vote: 3 for B, 1 for D, 1 neutral-leaning-B.

The deciding factors:

Factor	Option B	Option D
Rollback safety	Drop collection (15 min)	Must remove entity_type from core types (risky)
Query isolation	Chain queries isolated to own collection	Must filter entity_type !== execution_chain everywhere
SCIM/OAA export risk	No risk (chains not in entities)	High risk (chain entities leak into standards-based exports)
Neo4j portability	Good (map to labeled nodes)	Better (already nodes)
ADR-002 compliance	Introduces new collection (deviation)	Stays in single collection (respects ADR)
Effort	~94h (Developer estimate)	~62h (Developer estimate)

The ADR-002 concern (PO's main argument) is addressed by the Architect: "ADR-002 says all source system entities go in one collection. Execution chains are platform-computed composites, not source entities. A new collection for a new concept is architecturally correct."

---

4. Unanimous Agreement: Phased Implementation

All 5 roles agree on phasing, even if they disagree on the storage mechanism:

Phase 1: Chain Identity + Listing (Ship First)

Deliverable	Description
Chain discovery	BFS from entry points (BR, Flow, Job) following TRIGGERS_ON → CALLS → EXECUTES_ON → AUTHENTICATES_TO → RUNS_AS
Stable chain ID	Derived from anchor entity (entry point source_id)
Chain composition	Ordered list of entity references with roles
Aggregate summary	Trigger, destination, egress, blast radius, ownership status
Composition fingerprint	SHA256 of sorted entity_id:role pairs — detects structural changes
API endpoints	GET /execution-chains, GET /execution-chains/:id
UI pages	Execution Chains list page + detail page

Effort estimates:

Role	Estimate
Architect	15 hours
Developer	94 hours (includes UI, tests, migration)
Integrator	2-3 days for connector chain hints
CISO	"2-3 days engineering, the compliance cost of NOT doing it is an audit finding"

Phase 2: Temporal Chain Tracking (Ship Within 30 Days)

Deliverable	Description
Chain versions	Snapshot created when composition or blast radius changes
Chain diff API	Compare chain state between two timestamps
Chain-level events	chain_created, chain_entity_added, chain_blast_radius_changed
Temporal UI	Compare chain state over time

Incremental effort: +9-48 hours (Architect: 9h, Developer: 48h)

Phase 3: Chain-Level Findings (Post-MVP)

Deliverable	Description
Chain-level zombie detection	"83% of this chain has orphaned ownership"
Chain blast radius expansion finding	"Chain gained access to PII"
Chain-level evidence packs	Full chain temporal context in sealed artifact
Cross-chain impact analysis	"SP X participates in 3 chains"

---

5. Unanimous Agreement: Platform Owns Chain Assembly

All 5 roles agree: Chains should be assembled by the platform, not by connectors.

Role	Position
Product Owner	"The connector discovers entities; the platform assembles chains"
Architect	"Chain assembly belongs in the sync pipeline, after entity upsert + path materialization"
CISO	"Chains are computed by the platform, not created by users or connectors"
Integrator	"Platform sees all connectors, handles partial graphs, handles timing differences"
Developer	"New step in sync-ingestion.ts, after path materialization, before finding evaluation"

Key reasons:

1. Partial graphs: ServiceNow connector runs Monday, Entra runs Tuesday. Only the platform sees both.
2. Cross-system stitching: OAuth → SP matching via AUTHENTICATES_TO already happens at platform level.
3. Chain stability: Platform has temporal view; connector sees one snapshot.
4. Future multi-connector chains: GitHub → AWS → Slack requires platform-level assembly.

Connector contribution: Optional chainMembership hints on nodes (Integrator proposal):

properties["chainMembership"] = {
    "role": "entry_point",
    "anchorEntityId": br_sys_id,
    "chainSemanticHash": "trigger-incident-dest-graph"
}

These hints are optional, non-breaking, and help the platform optimize chain assembly.

---

6. Chain Identity: The Ship of Theseus Solution

All 5 roles agree on how to give chains stable identity:

What Defines "The Same Automation"

The anchor entity (the trigger/entry point — typically a Business Rule or Flow) is the stable root. The chain's identity is derived from the anchor's source_id:

const chainId = sha256(`${tenantId}:${anchorEntitySourceId}`).slice(0, 24);

When Entity Changes Don't Break Chain Identity

Change	Same Chain?	Why
OAuth client_id rotated (new credential)	Yes	Anchor unchanged; composition may change but chain persists
SP gets new role (permission escalation)	Yes	Entity properties changed, not chain composition
New SI added to chain (code change in BR)	Yes*	Same anchor, composition changed — new chain version
BR deleted entirely	Chain "broken"	Anchor gone — chain marked deleted, retained for history
New BR created calling same SI	New chain	Different anchor = different chain

*The Architect's fingerprint mechanism detects structural changes (entity added/removed) vs. property changes (role added to existing entity). Structural changes create a new chain version; property changes are tracked via existing entity_versions.

The Git Analogy (Architect)

"A git branch is a stable name for a changing pointer. Commits change, the branch name persists. An execution chain is a stable name for a changing subgraph. Entities rotate, credentials expire, roles expand — the chain persists."

---

7. Compliance Impact (CISO Assessment)

Current State: NOT Audit-Ready for Chains

Control	Status	Gap
CC6.1 (Access Controls)	PARTIAL	Can show entity access at T; cannot show chain access at T
CC7.1 (Monitoring)	PARTIAL	Entity-level findings fire; chain-level expansion undetectable
CC8.1 (Change Management)	PARTIAL	Entity changes auditable; chain composition changes not tracked
ISO 27001 A.5.9 (Asset Lifecycle)	NOT MET	Chains are not identifiable, classifiable, or reviewable as assets
SOX ITGC	NOT MET	Cannot reconstruct chain-level access at any past date

After Phase 1 (Lightweight Chains): Partially Ready

Control	Status
CC6.1	PARTIAL (current state attestable, not temporal)
CC7.1	IMPROVED (chain-level ownership monitoring)
CC8.1	PARTIAL (composition hash comparison)
A.5.9	MET (chains identifiable, classifiable, reviewable)
SOX ITGC	PARTIAL (current inventory, not historical)

After Phase 2 (Chain Versions): Fully Ready

Control	Status
CC6.1	MET
CC7.1	MET
CC8.1	MET
A.5.9	MET
SOX ITGC	MET

---

8. The Incident Response Scenario

CISO walked through this scenario step by step:

• Day 0: Automation runs normally — reads incidents, updates assignment groups
• Day 30: Someone adds hr_admin role to the SP in the chain
• Day 60: Automation now reads HR cases (PII) via expanded role
• Day 90: Data breach discovered — HR data exfiltrated
• Day 91: CISO opens SecurityV0

Question	Current Model	With Chain Tracking
"What automation was involved?"	Must manually trace entities	Direct lookup: Automations page
"When did its access change?"	Query entity_versions for SP, manually reconstruct	Chain version diff: "blast radius expanded Day 30"
"Who approved the role change?"	Query events for SP, find actor	Same (entity-level), but chain timeline aggregates all member events
"What data was accessible after?"	Compute execution_paths for SP at Day 30	Chain blast radius snapshot at Day 30 (pre-computed)
"Was it actively executing?"	Query execution_evidence for SP	Same, but chain summary shows aggregate execution count

CISO verdict: "Without chain tracking, forensic investigation takes hours of manual entity correlation. With chain tracking, it's seconds."

---

9. Implementation Comparison (Developer Assessment)

Metric	Option A (Computed)	Option B (Lightweight)	Option C (Temporal)	Option D (Virtual Entity)
New files	3	5	+2 (7 total)	2
Modified files	3	5	+4 (9 total)	8
New LOC	~770	~1,710	~2,340	~505
New tests	~330	~640	~820	~510
Collections added	0	1	2	0
Effort (hours)	62	94	142	62
Temporal query perf	Poor (N queries)	N/A	Excellent (1 query)	Good
Neo4j portability	High	Moderate	Low	High
Architectural purity	Clean	Clean	Clean	Polluted
Rollback risk	N/A	Negligible	Negligible	High

---

10. Prioritized Action Items (Team Consensus)

Phase 1: Chain Identity + Listing (~94 hours, 2-3 weeks)

#	Action	Effort	Owner
1	Define chain types: ExecutionChainDoc, ChainEntityRef, ChainSummary	4h	Developer
2	Implement chain builder: anchor discovery + BFS assembly + fingerprint	16h	Developer + Architect
3	Add execution_chains collection + indexes to StorageAdapter	12h	Developer
4	Integrate chain assembly into sync pipeline (after path materialization)	8h	Developer
5	API routes: GET /execution-chains, GET /execution-chains/:id	10h	Developer
6	UI: ExecutionChainsPage (list) + ExecutionChainDetailPage (detail)	20h	Developer
7	Add connector chain hints (optional chainMembership property)	8h	Integrator
8	Unit + integration tests for chain assembly	12h	Developer
9	Migration script + data backfill	4h	Developer

Phase 2: Temporal Chain Tracking (+24-48 hours, 1-2 weeks)

#	Action	Effort	Owner
10	Add execution_chain_versions collection	8h	Developer
11	Chain versioning: create version when composition/blast radius changes	12h	Developer + Architect
12	Chain diff API: compare two chain versions	6h	Developer
13	Chain-level events (chain_created, chain_blast_radius_changed)	4h	Developer
14	UI: Chain temporal comparison tab	8h	Developer
15	Chain-level findings (aggregate ownership, blast radius expansion)	10h	Developer + CISO

Phase 3: Post-MVP Enhancements (deferred)

#	Action
16	Cross-chain impact analysis ("SP X participates in 3 chains")
17	Chain-level evidence packs (sealed artifacts)
18	Chain validation workflow (CISO approves chains)
19	Cross-tenant chain tracking
20	Chain complexity budget (cap + expand for large chains)

---

11. Answer to the Core Question

"Does the platform need a separate collection to track automation chains?"

Team Answer: Yes.

All 5 roles agree that the current model cannot express automation chains as listable, trackable, temporal entities. The team recommends:

1. New execution_chains collection — lightweight reference documents with stable chain IDs, entity composition, and aggregate summaries
2. Platform-side assembly — chains computed from entity relationships during sync, not emitted by connectors
3. Phased delivery — Phase 1 (identity + listing) in 2-3 weeks; Phase 2 (temporal versions) in +1-2 weeks
4. Chain identity anchored to entry point — the trigger automation entity is the stable root; entity rotation within the chain doesn't break identity

What About the Founder's Concern?

The founder said: "if at one point we find an automation with certain list of entities and connections... then some entities change... from end user/CISO perspective everything remains the same."

This is exactly what the execution_chains collection delivers. The chain has a stable ID derived from its anchor entity. When the OAuth client rotates, the chain persists — the entity_refs list is updated, a new composition_hash is computed, and if the structure actually changed, a new chain version is created. The CISO sees the same automation with a timeline of changes.

Neo4j Portability

The execution_chains collection maps naturally to Neo4j:

• Each chain becomes an :ExecutionChain node
• Entity membership becomes CONTAINS edges
• Chain versions become temporal properties (Neo4j bi-temporal)
• Chain assembly BFS translates directly to Cypher path queries

The separate collection is application-level metadata that Neo4j supplements, not replaces.

---

12. Dissenting Position (Documented for Founder Review)

Product Owner disagrees with the majority and recommends Option D (virtual entity) instead of Option B (new collection).

PO argument: "ADR-002 says single collection. A new collection for chains is a deviation. entity_type: 'execution_chain' in the existing collection uses all existing temporal machinery — entity_versions, events, baselines. Zero new infrastructure."

Counter-arguments from majority:

• Architect: "ADR-002 covers source-system entities. Chains are platform-computed composites — a new concept."
• CISO: "Semantic confusion risk. Every query against entities must now filter out chains. Missing the filter in one SCIM/OAA export is a compliance issue."
• Developer: "Option D breaks path materializer, graph layout, entity filters. 8 files must be modified defensively."

This disagreement should be resolved by the founder/CEO before implementation begins. Both approaches deliver the core value. The trade-off is:

• Option B: Safer, cleaner, slightly more effort, one more collection
• Option D: Respects ADR-002, uses existing machinery, higher ongoing maintenance risk

---

13. Files Produced (Round 3)

File	Role	Lines	Key Topics
03-automation-persistence-product-owner.md	Product Owner	976	7 user stories, scoring matrix, Option D advocacy, UI mockups
03-automation-persistence-architect.md	Architect	1338	Chain builder algorithm, fingerprint contract, schema design, Option B+C recommendation
03-automation-persistence-ciso.md	CISO	736	SOC2/ISO/SOX mapping, incident response scenario, zombie NHI chain analysis
03-automation-persistence-integrator.md	Integrator	1279	Platform vs connector assembly, cross-connector stitching, incremental sync updates
03-automation-persistence-developer.md	Developer	1431	Implementation matrix, effort estimates, testing strategy, concrete phase plan
03-automation-persistence-synthesis.md	Lead	This document — team consensus and action items

---

Round 3 analysis complete. 5 perspectives, ~5,760 lines of research. Consensus: new execution_chains collection with phased delivery. One dissent (PO: virtual entity). Total estimated effort: Phase 1 ~94h (2-3 weeks), Phase 2 +24-48h (1-2 weeks).