Research Prompt: What Should We Call the Entity Type Currently Named "automation"?

Date: 2026-02-17 Status: Closed — decision made. The entity type is workload. See ADR-010 for the formal decision and doc 09 section 9 for the comparative analysis. Context: SecurityV0 — an Autonomous Execution Exposure Management platform that discovers non-human identities, maps their execution paths, and produces deterministic findings.

---

The Problem

We have a naming collision in our data model. The word "automation" refers to two different things at two different scopes:

Scope 1: The entity (narrow) — NEEDS A NEW NAME

A single configured code/logic artifact discovered in a source system. Examples from ServiceNow:

Subtype	What it is
Business Rule	Server-side script triggered by record changes
Script Include	Reusable server-side script library, called by other automations
Flow Designer Flow	Visual automation flow (low-code)
Scheduled Job	Cron-like job that runs on a schedule
UI Action	Server-side script triggered by user button click
Event Script	Script triggered by system events

These entities:

• Are configured artifacts — they define executable behavior but don't execute on their own
• Do not authenticate — they delegate to an identity via a RUNS_AS relationship
• Are discovered by connectors from source systems (ServiceNow, Azure, GitHub, etc.)
• Have subtypes that describe what KIND of artifact they are
• Currently stored as entity_type: "automation" in our database

Scope 2: The full configured behavior (broad) — KEEPING "Automation Definition"

The complete chain from trigger through code, outbound connections, credentials, identity, to reachable resources. This is the page-level concept in our UI:

TRIGGER → [entity] → CALLS (outbound API) → RUNS AS (identity) → CAN ACCESS (resources)

This has been named "Automation Definition" — it describes the full definition of what an automation IS and DOES, including all its relationships.

The collision

If the page is "Automation Definition" and the entity within it is also called "Automation", we have "Automation inside Automation." In the UI, in the data model, in documentation — everywhere the word is overloaded.

---

The Settled Naming Model (decided by founder)

These names are FINAL and not up for discussion:

#	Concept	Name	Description
1	Full configured behavior	Automation Definition	The complete chain: trigger → code → connections → identity → resources
2	Derived structural path	Authority Path	Platform-computed traversal showing how authority flows from automation to resources
3	Runtime instance	Automation Run	One execution of the full behavior (deferred to W2)
4	Raw proof event	Execution Evidence	Immutable proof of execution (sign-in logs, transaction logs)

We need a name for the entity type — the individual code artifact (Scope 1 above) — that does NOT use the word "automation."

---

Our Data Model — The 9 Entity Types

The entity we're renaming exists alongside 8 other entity types. The new name must fit naturally in this taxonomy:

Current entity_type	Description	Example
identity	An entity that authenticates and acts in systems	Service Principal, OAuth App, Machine Account
automation ← RENAME THIS	A configured artifact that defines executable behavior	Business Rule, Script Include, Flow, Scheduled Job
connection	An outbound integration endpoint	REST Message, SOAP Message, HTTP Connection
credential	Authentication material	OAuth Profile, API Key, Certificate
owner	A human or team accountable for an entity	IT Admin, Security Team
role	A named grouping of permissions	Application Role, Directory Role
permission	An individual capability scoped to a resource	Read, Write, Execute, Admin
resource	A system object acted upon	Table, API Endpoint, Repository
execution_evidence	Immutable proof of execution	Sign-in log, Flow execution record

Relationship pattern for this entity type

[THIS ENTITY] --TRIGGERS_ON--> Resource (what triggers it)
[THIS ENTITY] --RUNS_AS--> Identity (what identity it executes as)
[THIS ENTITY] --INVOKES--> Connection (what outbound endpoint it calls)
[THIS ENTITY] --CALLS--> [THIS ENTITY] (when one calls another, e.g., Business Rule calls Script Include)
Owner --OWNED_BY--> [THIS ENTITY] (who is accountable)

Key property: this entity type is the ONLY entity that has the RUNS_AS relationship — it delegates its execution to an identity. Identities authenticate; this entity type does not.

---

Constraints for the New Name

1. Must NOT contain the word "automation" — that word belongs to the broader "Automation Definition" concept
2. Must be a single word or short compound — it appears in code (entity_type: "new_name"), database queries, API filters, UI badges, and graph legends
3. Must be generic enough to cover all subtypes: Business Rules, Script Includes, Flows, Scheduled Jobs, UI Actions, Event Scripts — and potentially similar artifacts from other platforms (Azure Logic Apps, GitHub Actions, AWS Lambda)
4. Must be specific enough to distinguish from the other 8 entity types (not so generic it could mean anything)
5. Must communicate "configured code/logic that can execute" — these are not static data, they are executable artifacts
6. Must be platform-agnostic — not tied to ServiceNow vocabulary
7. Should be natural in security/governance context — our audience is CISOs and security teams
8. Should read well in sentences like:
   • "This [entity_type] has 3 execution paths"
   • "The [entity_type] runs as service principal X"
   • "Found 42 [entity_type]s with external egress"
   • "This [entity_type] is a Script Include"

---

Options We've Already Considered (and their weaknesses)

Option	Why we're not sure
process	OS connotations (PID, process management)
workflow	Script Includes aren't workflows; too narrow
executable	Sounds like a binary file
component	Too generic — connections and credentials are also components
logic	Too abstract, doesn't feel like a "thing"
routine	Programming-specific, unusual in security context
task	Overloaded (Airflow tasks, JIRA tasks, OS tasks)
action	Overloaded (GitHub Actions, UI Actions in ServiceNow)
artifact	Too generic — everything is an artifact
automation_source	Still contains "automation" adjacent; "source" is ambiguous
procedure	SQL/database connotations
handler	Doesn't fit Scheduled Jobs or Flows

---

What We're Looking For

Please propose 3-5 naming options for this entity type. For each option:

1. The name (as it would appear in entity_type: "name")
2. Why it works — how it communicates "configured executable artifact"
3. How it reads in context — test it in the sentences from the constraints section
4. Potential downsides — what connotations or confusions could arise
5. Industry precedent — does any security, DevOps, or orchestration platform use this term for a similar concept?

Prioritize names that a CISO would immediately understand and that a developer would find natural in code.