Skip to main content

ADR-010: Workload Entity Type Rename

Status​

Accepted (2026-02-17)

Context​

ADR-006 split autonomous_identity into 4 types, creating entity_type: "automation" for executable code artifacts (Business Rules, Script Includes, Flows, Scheduled Jobs). This was semantically correct — those entities define execution logic, not authentication.

However, W1 (Exposure wedge) product documentation introduced the term "Automation Definition" as a broad concept covering the configured behavior of any automation. This created a naming collision:

  1. automation (entity type) — a single executable code artifact (one Business Rule, one Flow)
  2. "Automation Definition" (product concept) — the broad configured behavior that encompasses one or more entity types

The collision manifested in the UI: the "Automations" page card appeared inside the broader "Automation Definition" concept, creating "automation inside Automation" confusion. Phase 0 (commit 3a45ceb) temporarily fixed this by renaming the UI card to "ENTRY POINT", but the underlying entity type remained automation.

Naming analysis​

A 5-agent comparative analysis evaluated three candidates for the entity type rename:

CandidateProsCons
workloadCloud-native vocabulary (K8s, GCP, Azure). Familiar to ops teams. Clear scope: "a unit of work that runs as an identity."Less security-specific than alternatives.
execution_surfaceSecurity-native framing ("the surface where autonomous execution meets sensitive data"). CISO-resonant.Potentially confused with "attack surface". Longer identifier. Not a standard term in any platform.
surfaceShort, clean UI label.Ambiguous without context. "API surface"? "Attack surface"? No established meaning.

A separate external analysis (doc 09, Gemini research) recommended execution_surface. The in-session 5-agent team (CISO, Architect, Developer, Product Owner, Target Analyst) unanimously recommended workload.

Decision factors​

  • Developer familiarity: workload is a standard term in Kubernetes, GCP Cloud Run, Azure Container Apps, and AWS ECS. Developers encountering the SecurityV0 API will immediately understand what a "workload" is.
  • Scope precision: A workload is "a unit of work that runs as an identity" — exactly what our automation entities are.
  • No collision: "Workload" does not collide with "Automation Definition", "Authority Path", "Automation Run", or "Execution Evidence" — the four W1 product concepts.
  • Short, greppable: 8 characters, no underscores needed for UI display.

Decision​

Rename entity_type: "automation" to entity_type: "workload" across the platform.

Backward compatibility​

The platform accepts both "automation" and "workload" as entity_type and NormalizedNodeType values during the migration period:

  1. Ingestion: The normalizer maps incoming "automation" to "workload" before storage.
  2. API responses: Entities are returned with entity_type: "workload". API query filters accept both values.
  3. Connector: The connector will be updated to emit "workload" as the nodeType. During transition, "automation" continues to work.
  4. Database migration: A one-time migration script updates existing documents from entity_type: "automation" to "workload".

The deprecated "automation" alias will be removed in a future version after all connectors and integrations have migrated.

Scope of rename​

LayerWhat changes
Data modelentity_type value: "automation" → "workload"
TypeScript typesAutomationSubtype → WorkloadSubtype (deprecated alias retained)
APIQuery filters, response fields. Entity-level endpoints rename: /automations → /workloads. Note: W1 UX primarily uses the new /api/v1/exposures endpoint (a derived view computed from workload entities), not the entity-level /workloads endpoint directly. Both coexist.
UIPage names, navigation labels, component names
ConnectorNormalizedNodeType: "automation" → "workload"
DocumentationArchitecture docs, product docs, session notes
DatabaseOne-time migration of existing entity_type: "automation" documents

What does NOT change​

  • The entity classification logic (decision tree) is unchanged — the same artifacts are classified as workloads.
  • The subtypes remain: business_rule, script_include, flow_designer_flow, scheduled_job, event_script, transform_map.
  • The relationships remain: RUNS_AS, CALLS, INVOKES, TRIGGERS_ON, EXECUTES_ON.
  • The execution_chains collection uses entity_refs[].entity_type — these will be migrated to "workload".

Consequences​

Positive​

  • Eliminates "automation inside Automation" naming collision
  • Aligns with cloud-native vocabulary familiar to platform engineers
  • Creates clear separation: "workload" (entity) vs "Automation Definition" (broad concept) vs "Authority Path" (derived structure) vs "Automation Run" (runtime event)

Negative​

  • ~45 files modified across platform, connector, and documentation
  • Backward-compatibility alias adds a small amount of code complexity
  • External consumers referencing entity_type: "automation" need to update (mitigated by alias period)

Risk​

  • Finding ID stability: Finding IDs use eval:hash(tenant|type|entity). Changing entity_type does NOT change finding IDs (entity_type is not part of the hash). Finding IDs use finding_type, not entity_type.
  • Execution chain migration: entity_refs[].entity_type field (NOT steps[] — the steps field does not exist in ExecutionChainDoc) needs to be updated. The migration script targets the correct field.