Codex 5.3 Research — Automation Definition vs Runtime Execution Separation Synthesis

Date: 2026-02-17 Scope: Clarify and separate configuration-level automations from verified runtime executions. Prompt context: The platform now has automation as a first-class entity and dashboard visibility, but users report persistent confusion between "automation entity", "execution chain configuration", and "actual execution".

---

1. Executive Conclusion

The confusion is caused by three different concepts being described with overlapping "execution" language:

1. Automation Definition (automation entity): what code/config is intended to run.
2. Automation Topology (today: execution_chains): a derived, sync-time structural path through graph relationships.
3. Runtime Execution (today represented only indirectly through execution_evidence): what verifiably ran in reality.

Current naming makes (2) and (3) look equivalent when they are not.

---

2. Evidence From Current Implementation

2.1 execution_chains are structural and sync-derived, not runtime instances

• Chain assembly is BFS from entry-point automations and edge traversal:
  • /Users/lucky/dev/securityv0/sv0-platform/src/ingestion/chain-builder.ts:57
  • /Users/lucky/dev/securityv0/sv0-platform/src/ingestion/chain-builder.ts:158
• Chain timestamps (first_detected_at, last_seen_at) are updated at sync ingestion time, not run time:
  • /Users/lucky/dev/securityv0/sv0-platform/src/ingestion/chain-builder.ts:93
  • /Users/lucky/dev/securityv0/sv0-platform/src/storage/mongo/adapter.ts:626
• API exposes these as "Execution Chains":
  • /Users/lucky/dev/securityv0/sv0-platform/src/api/routes/chains.ts:7

2.2 Runtime proof exists in execution evidence, separate from chains

• Runtime records are returned by /api/v1/entities/:id/execution-evidence:
  • /Users/lucky/dev/securityv0/sv0-platform/src/api/routes/evidence.ts:36
• Evidence records include source timestamps and evidence types (api_call, flow_execution, scheduled_job, sign_in):
  • /Users/lucky/dev/securityv0/sv0-platform/src/domain/evidence/types.ts:1
• Automation detail page already uses direct evidence + RUNS_AS identity evidence:
  • /Users/lucky/dev/securityv0/sv0-platform/ui/src/pages/AutomationDetailPage.tsx:101
  • /Users/lucky/dev/securityv0/sv0-platform/ui/src/pages/AutomationDetailPage.tsx:119

2.3 UI language amplifies ambiguity

• Automations table uses "Execution" column for observed counts:
  • /Users/lucky/dev/securityv0/sv0-platform/ui/src/pages/AutomationsPage.tsx:113
• Separate page called "Execution Chains" appears operational/runtime to users:
  • /Users/lucky/dev/securityv0/sv0-platform/ui/src/pages/ExecutionChainsPage.tsx:143
  • /Users/lucky/dev/securityv0/sv0-platform/ui/src/pages/ExecutionChainsPage.tsx:99

2.4 Documentation has drift and mixed semantics

• Data model correctly defines execution chains as ordered topology/provenance:
  • /Users/lucky/dev/securityv0/sv0-documentation/docs/architecture/01-data-model.md:819
• Data model correctly defines execution evidence as proof of actual execution:
  • /Users/lucky/dev/securityv0/sv0-documentation/docs/architecture/01-data-model.md:437
• API-layer doc still contains stale migration note about automations stored as identities:
  • /Users/lucky/dev/securityv0/sv0-documentation/docs/architecture/04-api-layer.md:140

---

3. Founder Vision and W1 Alignment

The founder vision and W1 docs materially change implementation priority for this research.

3.1 Vision constraints that apply directly

• System-of-record goal is execution authority visibility, deterministically linked from automation to identity, authority, reachability, egress, and accountability:
  • docs/product/strategy/vision.md:24
• Unit of concern is autonomous execution path, not static identity:
  • docs/product/strategy/vision.md:73
• Unknown must be explicit when proof is absent:
  • docs/product/strategy/vision.md:69

3.2 W1 scope constraints that affect this synthesis

• W1 is discovery and assessment only (no remediation, no drift/monitoring):
  • docs/product/wedges/w1-exposure/definition.md:154
• W1 does not require execution_chains persistence, fingerprinting, or versioning:
  • docs/product/wedges/w1-exposure/scope.md:63
• W1 logic is bounded to first provable boundary and explicitly avoids inference:
  • docs/product/wedges/w1-exposure/scope.md:118
  • docs/product/wedges/w1-exposure/logic.md:67
• W1 UX expects deterministic path presentation as:
  • Automation -> Identity -> Destination -> Data Domain
  • docs/product/wedges/w1-exposure/ux.md:123
• W1 UX de-emphasizes chain internals (no chain depth/hop emphasis):
  • docs/product/wedges/w1-exposure/ux.md:136

3.3 Impact on prior recommendation

My prior recommendation to add first-class automation_runs remains architecturally valid, but it is not required to deliver W1.

W1-aligned correction:

• Keep separation semantics now.
• Implement W1 via deterministic derived exposure views from existing entities + evidence.
• Defer new persistence (automation_runs, chain drift/versioning) to W2.

---

4. Role-Based Research Synthesis (W1-Aligned)

4.1 Architect

Recommendation: formalize four distinct bounded concepts:

1. AutomationDefinition (current automation entities)
2. AutomationTopology (current execution_chains, renamed conceptually)
3. AutomationRun (new first-class runtime instance)
4. ExecutionEvidenceEvent (current evidence records)

Architectural rule:

• Topology answers "can this path exist?"
• Run answers "did this path execute at time T?"

This keeps deterministic, explainable modeling while preserving temporal truth.

W1-specific architect decision:

• In W1, AutomationTopology can remain internal/secondary.
• Primary user-facing unit should be a deterministic Exposure Unit projection.

4.2 CSO/CISO

Control and governance implications:

• Compliance and risk attestations must separate:
  • standing authority exposure (configured topology)
  • active exercised risk (verified runs/evidence)
• Without this split:
  • dormant-authority vs active-risk classification becomes ambiguous
  • audit narratives become disputable ("chain existed" interpreted as "chain executed")

Governance framing:

• Govern identities/credentials and automation definitions.
• Monitor topologies for exposure.
• Investigate runs/evidence for incident and control effectiveness.

W1-specific CSO/CISO interpretation:

• The CISO-facing narrative should be "proven autonomous authority exposure," not "chain mechanics."
• Unknown/unproven must be first-class output, not hidden.

4.3 Developer

Implementation recommendation:

• Keep execution_chains as derived topology projection.
• Do not make new run persistence mandatory for W1.
• Build deterministic W1 exposure projection from existing graph + evidence.
• Maintain backward-compatible APIs while introducing explicit naming.

Immediate consistency fixes:

• Align chain roles between ADR and code (data_resource vs authorized_role/authorized_permission/target_resource naming mismatch):
  • /Users/lucky/dev/securityv0/sv0-platform/src/domain/chains/types.ts:3
  • /Users/lucky/dev/securityv0/sv0-documentation/docs/architecture/decisions/adr-008-execution-chains-collection.md:83

4.4 Integrator

Connector-facing guidance:

• Emit strongest possible runtime identity for each evidence record:
  • source_run_id when platform supports it
  • stable references to automation, connection, credential, identity where available
• When exact run IDs are unavailable, preserve provenance needed for deterministic correlation confidence.

Priority:

• Do not force connectors to emit topology; platform continues deriving topology centrally.
• Improve evidence linkage quality before broadening connector complexity.
• Keep heuristic-free linkage bar for W1 (unproven when deterministic linkage is missing).

4.5 Product Owner

UX language change is mandatory and can ship first:

• "Execution Chains" -> "Automation Topologies (Configured)"
• "Last Seen" (chain) -> "Last Computed"
• "Execution (30d)" -> "Observed Runs (30d)"
• Add badges on detail pages:
  • Configured for topology
  • Observed for runtime

User-question mapping:

• "What can run?" -> topology views.
• "What actually ran?" -> runs/evidence views.

W1-specific product guidance:

• Primary flow should be risk clusters and deterministic exposure rows, not graph-first navigation:
  • docs/product/wedges/w1-exposure/ux.md:85
  • docs/product/wedges/w1-exposure/ux.md:297

---

5. W1-Aligned Canonical Model and Terminology

Concept	Current artifact	Proposed canonical term	W1 use	Time semantics
Automation code/config	entity_type: automation	AutomationDefinition	Required	relatively stable
Deterministic CISO unit	derived (not named)	ExposureUnit	Required (primary)	as-of refresh
Derived path composition	execution_chains	AutomationTopology	Optional/secondary	recomputed per sync
Runtime instance	not first-class	AutomationRun	Deferred (W2)	event/time-bound
Raw proof event	execution_evidence	ExecutionEvidenceEvent	Required	immutable evidence event

ExposureUnit shape for W1 (projection, not mandatory persistence):

• automation_id
• execution_identity_id (or unknown)
• execution_status (proven | unproven)
• data_domains[] with sensitivity (or unknown)
• egress_category (llm | external | internal | unknown | none_observed)
• ownership_status (valid | invalid | ambiguous | unknown)
• deterministic explanation + evidence declaration

Decision statement:

• Keep existing storage shape for W1.
• Surface W1 through deterministic exposure projection and UX labeling.
• Defer run persistence and topology drift features to W2.

---

6. Implementability Matrix (Vision/W1 vs Current Platform)

Capability	Founder/W1 expectation	Current state	W1 feasibility
Deterministic automation inventory	Required	Implemented (automation entities)	High
RUNS_AS identity binding	Required	Implemented in graph + UI	High
Proven/unproven execution status	Required	Evidence exists; explicit unproven UX/finding not standardized	Medium (small changes)
First-boundary data reachability	Required	Implemented via materialized paths	High
First-boundary egress class	Required	Implemented (egress_category)	High
Ownership validity states	Required	Implemented (ownership_status)	High
Deterministic risk clusters	Required by W1 UX	Not implemented as explicit cluster product primitive	Medium
Evidence completeness declaration	Required	Implemented in finding model/evidence packs	High
Chain persistence/versioning	Not required in W1	Partially implemented (execution_chains)	Keep internal/secondary
Drift monitoring/versioning analytics	Out of scope in W1	Not fully implemented	Defer to W2

---

7. W1-First Phased Plan

Phase W1-A (now, lowest risk, highest alignment)

1. Update UI labels and page titles.
2. Introduce explicit proven/unproven execution status derived from deterministic evidence linkage.
3. Add W1 Exposure view/projection (automation -> identity -> destination -> domain) using existing data.
4. Keep execution_chains available but not primary in W1 flow.
5. Resolve stale docs and chain-role naming drift.

Phase W1-B (pilot hardening)

1. Implement deterministic Top 5 risk clusters per W1 UX logic.
2. Add "Since Last Refresh" delta line using sync snapshots.
3. Standardize evidence declaration fields on all W1 findings.

Phase W2 (deferred, post-wedge expansion)

1. Add first-class AutomationRun persistence if/when needed for deeper runtime analysis.
2. Add topology/run correlation history.
3. Add drift/version analytics and broader blast-radius expansion.

---

8. External Pattern Validation (Primary References)

The definition-vs-instance split is the standard pattern across workflow/orchestration systems:

• Camunda: process definition vs process instance
  • https://docs.camunda.io/docs/reference/glossary/
• AWS Step Functions: state machine vs execution
  • https://docs.aws.amazon.com/step-functions/latest/dg/concepts-statemachines.html
• Apache Airflow: DAG vs DAG Run vs Task Instance
  • https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dags.html
  • https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dag-run.html
  • https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/tasks.html
• Kubernetes: CronJob vs Job
  • https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/
  • https://kubernetes.io/docs/concepts/workloads/controllers/job/
• Temporal: workflow definition vs workflow execution
  • https://docs.temporal.io/glossary

Inference: SecurityV0 should use the same separation pattern to avoid semantic overload and operator confusion.

---

9. Gemini Research Comparison (Alignment vs Differences)

Gemini's research strongly supports the same core separation model and specifically recommends using "Topology" for chain-level structure:

• four-concept split and definition/runtime separation:
  • docs/analysis/2026-02-12-automation-classification/07-Gemini-Research-Clarifying Security Automation UI Concepts.md:24
  • docs/analysis/2026-02-12-automation-classification/07-Gemini-Research-Clarifying Security Automation UI Concepts.md:36
• explicit recommendation to rename chain-level concept as "Topology"/"Authority Topology":
  • docs/analysis/2026-02-12-automation-classification/07-Gemini-Research-Clarifying Security Automation UI Concepts.md:54
  • docs/analysis/2026-02-12-automation-classification/07-Gemini-Research-Clarifying Security Automation UI Concepts.md:187

9.1 Where Gemini aligns with this Codex proposal

Area	Gemini	Codex 5.3 synthesis	Alignment
Definition vs runtime separation	Recommends 4-concept model	Recommends 4-concept model	Strong
Topology as chain-level semantics	Recommends "Topology"/"Authority Topology" for concept 2	Uses "AutomationTopology" for internal/secondary semantics	Strong
Deterministic evidence and unknown handling	Requires deterministic linkage; unproven/unknown if no proof	Same W1-aligned rule (proven/unproven, explicit unknown)	Strong
Preserve "automation definition" for static artifact	Recommends reserving automation for static definition	Same	Strong

9.2 Where Gemini conflicts with this Codex proposal (after founder/W1 alignment)

Area	Gemini recommendation	Codex 5.3 W1-aligned proposal	Difference rationale
W1 UX surfacing of topology	Promotes user-facing naming shift to "Topologies"/"Authority Topologies" in navigation and detail framing (:139, :117)	Keep topology internal/secondary in W1; primary surface is risk clusters + deterministic findings flow	W1 UX explicitly avoids alternate graph/topology-first navigation and favors single investigation flow
Execution column label	Suggests "Observed Runs (30d)" or "Recent Activity" (:140)	Keep W1 language "Executions (30d)" from founder UX	Founder W1 UX already defines the label and CISO-facing language register
Temporal analytics ambition	Includes broader dashboard constructs (trend lines/heatmaps) (:167)	W1 bounded to periodic refresh + deterministic delta; drift/trend beyond that deferred	Founder W1 scope excludes drift/continuous monitoring and broad temporal analytics

9.3 Decision from comparison

Adopt Gemini's "Topology" recommendation at the architecture vocabulary level, but keep W1 user-facing language and flow as defined by founder docs:

1. Internal model: AutomationTopology is valid and recommended.
2. W1 UI: prioritize deterministic exposure findings and risk clusters over topology terminology.
3. W2+: topology-focused views/navigation can be introduced when wedge scope expands.

---

10. Open Questions

1. Should W1 exposure grouping be persisted or computed on demand from findings + graph state?
2. What exact deterministic rule set defines "Active Non-Human Execution Identities" in mixed automation/identity scenarios?
3. How strict should linkage be before marking proven vs unproven when only identity-level evidence exists?
4. For W2, should AutomationRun identity be source-native (source_run_id) or platform-synthesized when source IDs are missing?

---

11. Final Recommendation

Adopt explicit separation now, but execute it in a W1-first way:

1. Definition (automation)
2. Exposure Unit (deterministic W1 projection, primary user surface)
3. Topology (execution_chains, secondary/internal for W1)
4. Evidence (execution_evidence, source of runtime proof)
5. Run persistence (AutomationRun) deferred to W2 unless W1 pilots prove it is mandatory.

This aligns founder vision and W1 boundary with what can be delivered from the current platform quickly, while preserving a clean path to deeper runtime and drift capabilities in W2.