Workload Rename — Implementation Plan

Date: 2026-02-17 Status: Superseded by doc 12 — W1 Unified Implementation Plan (which incorporates this rename as Phase 0) Decision: Rename entity_type: "automation" to entity_type: "workload" across all layers.

---

1. Decision Summary

The naming collision

The word "automation" referred to two scopes:

• Narrow (entity): A single code artifact (Business Rule, Script Include, Flow, Scheduled Job)
• Broad (concept): "Automation Definition" — the full configured behavior chain

5-agent analysis result

Agent	Recommendation	Key reasoning
CISO	execution_surface	Risk-native, self-documenting, board-ready
Developer	Keep automation	Fix collision at concept layer, zero migration
Product Owner	Keep automation + subtypes	Use subtypes in UI, no new vocabulary needed
Target Analyst	workload	Industry standard (Wiz, Orca, Defender), zero learning curve
Architect	workload	Active noun for active entity, clean taxonomy, natural code ergonomics

Why workload wins

1. The "IS a" test passes: "A Business Rule IS a workload" — natural and correct
2. No vocabulary collision: Unlike "surface" vs "attack surface", "workload" has no competing security meaning
3. Industry standard: Wiz, Orca, Microsoft Defender for Cloud, GCP Security Command Center all use "workload" for compute artifacts
4. Market positioning: "We show you the automation workloads that cloud security tools miss"
5. Code ergonomics: WORKLOAD_SUBTYPES, workloadSubtype, entity_type: "workload" all read naturally
6. Active noun: Workloads execute, call, invoke — matches the entity's behavior

Final vocabulary

Concept	Name	Where
Atomic code artifact entity	Workload (entity_type: "workload")	Data model, code, API, graph
Full configured behavior	Automation Definition	Page titles, docs, UX
Derived structural path	Authority Path	Docs, internal/debug UI
Runtime instance (W2)	Automation Run	Glossary as planned
Raw proof event	Execution Evidence	Everywhere
W1 finding row	Exposure	W1 UX
W1 surface grouping	Risk Cluster	W1 UX
W1 governance assertion	Standing Authority	W1 UX

---

2. Scope — All Changes by File

Phase 1: Platform Core (sv0-platform/src)

File	Line(s)	Change
src/domain/entities/types.ts	3	"automation" → "workload" in ENTITY_TYPES array
src/domain/graph/identity-subtypes.ts	11, 38, 44	AUTOMATION_SUBTYPES → WORKLOAD_SUBTYPES, AutomationSubtype → WorkloadSubtype
src/ingestion/types.ts	3, 5	"automation" → "workload" in NormalizedNodeType; update deprecation comment
src/ingestion/graph-transformer.ts	14, 39, 55, 60	Import rename, case "workload", property access workloadSubtype, reclassify return "workload"
src/ingestion/path-materializer.ts	14	PATH_MATERIALIZABLE_TYPES: "automation" → "workload"
src/ingestion/chain-builder.ts	136, 139	Comment + entityType: "workload"
src/storage/mongo/adapter.ts	12, 102, 179, 792, 805	Import rename, workloadSubtype property checks, WORKLOAD_SUBTYPE_SET
src/evaluator/rules/dormant-authority.ts	48, 68	=== "workload", label "Workload"
src/evaluator/rules/privilege-justification-gap.ts	64, 118	Same pattern
src/evaluator/rules/scope-drift.ts	19, 45	Same pattern
src/evaluator/rules/orphaned-ownership.ts	65	"workload" label
src/evaluator/rules/unresolved-auth.ts	51	workloadSubtype property access
src/api/routes/ingest.ts	12, 14	"workload" in valid types; update deprecation comment
src/api/routes/paths.ts	8	BLAST_RADIUS_TYPES: "automation" → "workload"

Backward compatibility in ingestion: Accept "automation" as deprecated alias in NormalizedNodeType and remap to "workload" in mapNodeType() — same pattern as existing "autonomous_identity" handling.

Phase 2: Platform Tests (sv0-platform/test)

File	Changes
test/evaluator/automation-evaluation.test.ts	entity_type: "automation" → "workload", automationSubtype → workloadSubtype
test/evaluator/dormant-authority.test.ts	entity_type values
test/evaluator/privilege-justification-gap.test.ts	entity_type values
test/ingestion/graph-transformer.test.ts	nodeType: "automation" → "workload", automationSubtype → workloadSubtype
test/ingestion/chain-builder.test.ts	entity_type + automationSubtype → workloadSubtype (~20 locations)
test/ingestion/path-materializer.test.ts	entity_type + automationSubtype → workloadSubtype (~6 locations)
test/api/paths.test.ts	entity fixtures
test/integration/helpers/mock-data.ts	entity factories
test/integration/storage/entity-crud.test.ts	entity_type + property names (~10 locations)
test/integration/storage/subgraph.test.ts	entity_type + property names (~5 locations)

Note: Consider renaming automation-evaluation.test.ts → workload-evaluation.test.ts for consistency.

Phase 3: UI (sv0-platform/ui/src)

File	Changes
ui/src/api/api-types.ts	EntityType union: "automation" → "workload"
ui/src/hooks/use-automations.ts	Rename to use-workloads.ts, useAutomations → useWorkloads, AUTOMATION_SUBTYPES → WORKLOAD_SUBTYPES, entity_type: "workload"
ui/src/components/AutomationBadges.tsx	Rename to WorkloadBadges.tsx, AutomationTypeBadge → WorkloadTypeBadge
ui/src/components/ExecutionFlowDiagram.tsx	Import rename, workloadSubtype property access
ui/src/components/graph/GraphLegend.tsx	label: "Automation" → label: "Workload"
ui/src/components/graph/GraphFilterSidebar.tsx	"automation" → "workload" in types and color map
ui/src/components/graph/EntityNode.tsx	automation: → workload: in color map
ui/src/components/graph/layout.ts	AUTOMATION_SUBTYPES → WORKLOAD_SUBTYPES, "automation" → "workload"
ui/src/components/graph/GraphNodeDetailsDrawer.tsx	"automation" → "workload" in BLAST_RADIUS_TYPES and EXEC_ENTITY_TYPES
ui/src/components/shared/EntityBadge.tsx	automation: → workload: in color map
ui/src/pages/AutomationsPage.tsx	Rename to WorkloadsPage.tsx, update imports, labels, page title
ui/src/pages/AutomationDetailPage.tsx	Rename to WorkloadDetailPage.tsx, update imports, labels
ui/src/pages/Dashboard.tsx	Import rename, useWorkloads, UI labels
ui/src/pages/EntitiesListPage.tsx	"automation" → "workload" in type options
ui/src/pages/GraphExplorerPage.tsx	"automation" → "workload" in ALL_ENTITY_TYPES
ui/src/components/Layout.tsx	Nav: "/automations" → "/workloads", label "Workloads"
ui/src/App.tsx	Routes: automations → workloads, import renames

Phase 4: Connectors (sv0-connectors)

File	Changes
integrations/entra-servicenow/src/.../transformer.py	node_type="automation" → node_type="workload", automationSubtype → workloadSubtype, _enrich_automation_properties → _enrich_workload_properties
integrations/entra-servicenow/src/.../correlator.py	Variable names, comments
integrations/entra-servicenow/src/.../origin_classifier.py	Comments/docstrings
integrations/entra-servicenow/src/.../egress_classifier.py	Comments/docstrings
integrations/entra-servicenow/src/.../risk_grouper.py	Comments/docstrings
integrations/entra-servicenow/src/.../ownership_validator.py	Comments/docstrings
integrations/entra-servicenow/tests/unit/test_transformer.py	node_type assertions, property names
integrations/entra-servicenow/tests/unit/test_transform_entities.py	Same

Backward compatibility in connector: The connector should emit workloadSubtype as the property name. The platform ingestion layer should also accept automationSubtype (remap to workloadSubtype) for any older connector payloads in the pipeline.

Phase 5: Database Migration

// MongoDB migration script
db.entities.updateMany(
  { entity_type: "automation" },
  [{ $set: {
    entity_type: "workload",
    "properties.workloadSubtype": "$properties.automationSubtype"
  }}]
);

// Also update entity_versions collection
db.entity_versions.updateMany(
  { entity_type: "automation" },
  [{ $set: {
    entity_type: "workload",
    "properties.workloadSubtype": "$properties.automationSubtype"
  }}]
);

// Execution chains reference entity_type in entity_refs (NOT steps — steps field does not exist)
db.execution_chains.updateMany(
  { "entity_refs.entity_type": "automation" },
  { $set: { "entity_refs.$[elem].entity_type": "workload" } },
  { arrayFilters: [{ "elem.entity_type": "automation" }] }
);

Strategy: Run migration AFTER deploying code that accepts both old and new values. The ingestion layer's backward-compat alias means the migration can happen at any point after the code deploy.

Phase 6: Documentation

File	Changes
sv0-documentation/docs/glossary.md	Update entity type table, disambiguation section, all "automation" entity references
sv0-documentation/docs/architecture/01-data-model.md	Entity type definitions
sv0-documentation/docs/architecture/03-database.md	Schema examples
sv0-documentation/docs/architecture/04-api-layer.md	API parameter examples
sv0-documentation/docs/architecture/decisions/adr-006-entity-type-reclassification.md	Update to reference "workload"
sv0-platform/docs/maintenance.md	MongoDB query examples
sv0-platform/CLAUDE.md	Entity type references

---

3. Property Name Decision

The connector currently emits automationSubtype as a property on entities. Two options:

Option A: Rename to workloadSubtype (recommended)

• Connector emits workloadSubtype
• Platform reads workloadSubtype
• Migration renames existing properties.automationSubtype → properties.workloadSubtype
• Backward compat: platform ingestion also accepts automationSubtype and remaps

Option B: Keep automationSubtype property name

• Less migration work
• Creates mismatch: entity_type: "workload" with property automationSubtype
• Every new developer will ask "why does a workload have an automationSubtype?"

Decision: Option A. The migration is a one-line $rename in MongoDB. The mismatch would persist forever.

---

4. Backward Compatibility Strategy

The rename touches a cross-repo contract (NormalizedNodeType). To avoid requiring simultaneous deployment:

1. Platform deploys first with backward-compat alias:

   • NormalizedNodeType accepts both "workload" and "automation"
   • mapNodeType() maps both to "workload"
   • Property remapping: accepts both automationSubtype and workloadSubtype

2. Connector deploys second emitting new names:

   • node_type="workload", workloadSubtype

3. DB migration runs third after both are deployed:

   • Converts existing stored entities

4. Cleanup (optional, later): Remove "automation" from the deprecated alias list in platform.

---

5. URL Route Decision

Current URL paths: /automations, /automations/:id

Option A: Rename routes to /workloads — consistent with data model Option B: Keep /automations routes — avoids breaking bookmarks, external links

Recommendation: Rename to /workloads with a client-side redirect from /automations/* → /workloads/* for bookmark compatibility. The redirect is a single React Router entry.

---

6. Execution Order

Phase 1: Platform core (src/)           — type defs, ingestion, storage, evaluator, API
Phase 2: Platform tests (test/)         — update fixtures and assertions
Phase 3: UI (ui/src/)                   — components, pages, hooks, routes
   → Run: npm test + npx tsc --noEmit + cd ui && npm run build
Phase 4: Connectors (sv0-connectors/)   — transformer, correlator, tests
   → Run: pytest
Phase 5: Database migration             — entities, entity_versions, execution_chains
Phase 6: Documentation                  — glossary, architecture docs, CLAUDE.md

Estimated file count: ~45 files across platform + connectors + docs.

---

7. Verification Checklist

• npm test — all unit tests pass
• npm run test:integration — all integration tests pass (with migrated DB)
• npx tsc --noEmit — typecheck clean
• cd ui && npm run build — UI builds
• pytest (connectors) — all tests pass
• Grep for leftover "automation" (excluding deprecated-alias code and comments)
• Local docker compose up --build — UI displays "Workload" in graph legend, entity list
• Ingest a test payload with node_type: "workload" — entity stored correctly
• Ingest a test payload with node_type: "automation" (deprecated) — backward compat works
• Evaluator findings say "Workload has..." for workload entities

---

8. What Does NOT Change

• "Automation Definition" — the broad concept name stays
• "Automation Run" — the W2 runtime instance name stays
• Page concept — the detail page is still an "Automation Definition" view
• RUNS_AS relationship — unchanged, workloads still delegate to identities
• Finding types — dormant_authority, orphaned_ownership, etc. unchanged
• Execution chains collection — structure unchanged, just entity_type values in steps
• API endpoint paths — /api/v1/entities, /api/v1/findings etc. unchanged (entity_type is a query param)