Automation Naming Separation — Implementation Plan & Open Questions
Date: 2026-02-17 Status: In progress — Phase 0 complete, Phase 1 pending naming decisions
1. Completed Work (Phase 0)
All verified: 258 tests pass, typecheck clean, UI build successful.
Phase 0a: Evaluator finding text (4 rule files)
| File | Change |
|---|---|
src/evaluator/rules/dormant-authority.ts | "Identity has..." → "Automation has..." for automation entities + RUNS_AS note when linked identities were checked |
src/evaluator/rules/privilege-justification-gap.ts | Same label fix + RUNS_AS note |
src/evaluator/rules/scope-drift.ts | Same label fix |
src/evaluator/rules/orphaned-ownership.ts | "identity has no designated owner" → "automation has no designated owner" |
test/evaluator/automation-evaluation.test.ts | entity_type: "automation" (was "identity"), new assertions for labels + RUNS_AS |
Example before/after:
- Before:
Identity has 5 execution path(s) but no execution evidence on record. - After:
Automation has 5 execution path(s) but no execution evidence on record. Evidence was also checked for 1 linked identity(s) via RUNS_AS.
Phase 0b: UI component rename
| Change | Files |
|---|---|
AutomationFlowDiagram → ExecutionFlowDiagram | ui/src/components/ExecutionFlowDiagram.tsx (new file), deleted AutomationFlowDiagram.tsx |
Flow step label "AUTOMATION" → "ENTRY POINT" | ExecutionFlowDiagram.tsx:43 |
| Updated import reference | ui/src/pages/AutomationDetailPage.tsx:22 |
| Added Automation (teal) + Connection (cyan) to graph legend | ui/src/components/graph/GraphLegend.tsx |
Phase 0c: Documentation glossary
Added disambiguation section to sv0-documentation/docs/glossary.md with a 3-concept table (Automation entity, Execution Chain, Execution Path) and key distinction notes.
2. The 4-Concept Model (from synthesis doc 06)
The research synthesis identified four distinct concepts that the platform should cleanly separate:
| # | Concept | Current artifact | Proposed canonical term | Time semantics |
|---|---|---|---|---|
| 1 | Automation code/config | entity_type: "automation" | Automation Definition | Relatively stable |
| 2 | Derived path composition | execution_chains collection | ??? (see open questions) | Recomputed per sync |
| 3 | Runtime instance | Not first-class yet | Automation Run | Event/time-bound |
| 4 | Raw proof event | execution_evidence collection | Execution Evidence | Immutable event |
Decision rule from synthesis §3.1:
- Concept 2 answers: "Can this path exist?" (structural, sync-derived)
- Concept 3 answers: "Did this path execute at time T?" (runtime, evidence-correlated)
3. Open Questions — Naming Decisions Needed
Q1: What should we call Concept 2 (currently "Execution Chains")?
The current name "Execution Chains" implies runtime execution, but these are sync-derived structural paths. Options:
| Option | Pro | Con | Notes |
|---|---|---|---|
| Authority Chains | Captures security meaning — chains of granted authority | New term, users need to learn it | Answers "what authority does this automation chain through?" |
| Configured Chains | Keeps familiar "chains", adds "not runtime" qualifier | "Configured" is vague — configured by whom? | Platform computed, not user-configured |
| Automation Chains | Ties to automation concept, simple | Could still imply runtime | Familiar pattern |
| Topologies | Technically precise, matches synthesis doc | Jargon, sounds like network diagrams | Used in synthesis doc 06 |
| Keep "Chains" + subtitle | Minimal change, add subtitle "Configured paths from automation to resources" | Doesn't fix the root naming issue | Least disruptive |
Current leaning: TBD — user wants to think on this.
Q2: What column header for the observed execution count on automations table?
Current: "Execution" (column header), shows execution_count_30d value.
| Option | Notes |
|---|---|
| Observed Runs (30d) | Clear separation from configured capability, matches synthesis §3.5 |
| Activity (30d) | Shorter, neutral |
| Runs (30d) | Shortest, might be confused with "run configurations" |
Q3: What timestamp label on chain detail pages?
Current: "Last Seen" (on chain detail, set at sync time).
| Option | Notes |
|---|---|
| Last Computed | Prevents "this chain ran at T" misreading |
| Last Synced | Technically accurate — updated at sync ingestion |
| Last Observed | Ambiguous — "observed" could mean runtime |
Q4: Should the glossary disambiguation section upgrade from 3-concept to 4-concept model?
Currently uses 3 concepts (Automation entity, Execution Chain, Execution Path). The synthesis proposes 4 concepts (adding Automation Run). Since AutomationRun doesn't exist yet as infrastructure, should the glossary:
- A) Stay at 3 concepts until the infrastructure lands
- B) Add the 4th concept now as "planned" to set expectations
Q5: Nav item for the chains/topology page
Currently: "Chains" with Link2 icon. Options depend on Q1 resolution.
| If Q1 = | Nav label | Icon suggestion |
|---|---|---|
| Authority Chains | "Authority Chains" | Shield or Lock |
| Configured Chains | "Chains" (unchanged) | Link2 (unchanged) |
| Automation Chains | "Chains" or "Auto Chains" | Link2 or Workflow |
| Topologies | "Topologies" | GitBranch or Network |
4. Proposed Phase 1: UI Label Changes (pending Q1-Q5 resolution)
Once naming decisions are made, the implementation is small (~5-6 UI files, no backend):
| File | Change |
|---|---|
ui/src/components/Layout.tsx | Nav label: "Chains" → resolved name from Q5 |
ui/src/pages/ExecutionChainsPage.tsx | Page title: "Execution Chains" → resolved name from Q1 |
ui/src/pages/ExecutionChainDetailPage.tsx | "Last Seen" → resolved from Q3 |
ui/src/pages/AutomationsPage.tsx | "Execution" column → resolved from Q2 |
sv0-documentation/docs/glossary.md | Update disambiguation table per Q4 |
No backend changes. No storage changes. No API route changes (URL paths stay /chains).
5. Deferred: Phase 2 — AutomationRun Infrastructure
Not yet scoped for implementation. Requires Q1-Q5 resolution first.
From synthesis doc 06, §5 Phase 1:
- Introduce
automation_runscollection as materialized runtime objects built from evidence correlation - Add read endpoints:
GET /api/v1/automations/:id/runsGET /api/v1/runs/:id
- Keep evidence endpoints as source-of-truth event feed
Key design decisions needed before this work:
- Run identity:
source_run_id(platform-native) vs platform-synthesized hash (§7.1) - Minimum evidence confidence for "verified" vs "inferred" classification (§7.2)
- Whether chain-level findings stay topology-centric or add run-centric finding types (§7.3)
- Scope to platforms with native run IDs first (Flow Designer, Scheduled Jobs), defer Business Rules
6. Deferred: Phase 3 — Topology/Run Correlation & Analytics
From synthesis doc 06, §5 Phase 2. Requires Phase 2 to land first.
- Link runs to topology fingerprint/version at execution time
- Analytics: configured-but-never-observed, observed-but-topology-changed, runtime divergence
7. Also Pending (Independent of naming)
Two concrete issues from the synthesis review that can be fixed regardless:
- Stale API doc:
sv0-documentation/docs/architecture/04-api-layer.md:140still contains a migration note about automations stored as identities — should be removed - Chain role naming mismatch:
src/domain/chains/types.ts:3usesdata_resourcevs ADR-008 which usesauthorized_role/authorized_permission/target_resource— should be aligned