Entity Type Classification — Team Synthesis Report
Supersession note (2026-02-13): This synthesis captures the Round 5 analysis as produced. During plan review, two corrections were applied to the implementation plans (not this document):
human_identitystays in NormalizedNodeType. This synthesis proposes renaminghuman_identity→ownerin the NormalizedNodeType enum (lines 147, 157, 166). The corrected plan keepshuman_identityas the connector-facing type per the connector contract (05-connectors.md line 334); the platform normalizer maps to internalowner. See Implementation Plan A.1.Effort re-baselined. This synthesis estimates ~52h (line 348). Code review identified 47 files with 13 identity-assumption locations. The corrected plan estimates ~100h with phased rollback. See Implementation Plan A.6.
For implementation details, always prefer the implementation plan over this synthesis.
Date: 2026-02-13 (Round 5)
Team: automation-analysis (6 agents)
Core Question: What entity type should Business Rules, Script Includes, REST Messages, OAuth Profiles, Flow Designer Flows, and Scheduled Jobs actually be? The current model classifies ALL as entity_type: "identity". Is this correct?
Team Participants
| Role | Model | Lines | Key Contribution |
|---|---|---|---|
| OAA Specialist | opus | 1,218 | OAA community connector evidence (0/8 classify artifacts as users), 9-question decision tree |
| Product Owner | opus | 1,299 | CISO mental model test, 5-type UX taxonomy, reversal of Round 2 consensus, execution chain visualization redesign |
| Architect | opus | 1,457 | 9-type hierarchy from scratch, per-artifact identity test (3-part), RUNS_AS vs IS distinction, corrected graph structure |
| CISO | opus | 1,400 | NHI count inflation (13-18x), 5 governance categories, compliance control mapping, forensic investigation impact |
| Integrator | sonnet | 1,073 | Source system data models, "can execute autonomously" test, dissenting position (keep BRs as identity) |
| Developer | sonnet | 1,397 | Code impact audit (47 files), implementation plan (168h), TypeScript types, rollback strategy |
Total: 7,844 lines across 6 perspectives.
1. Unanimous Agreement: The Current Model Is Wrong
All 6 roles confirm: Classifying ALL automation artifacts as entity_type: "identity" is semantically incorrect.
| Role | Position |
|---|---|
| OAA Specialist | "No OAA community connector (0 of 8 reviewed) classifies automation artifacts as Local Users (identities). There is zero precedent." |
| Product Owner | "I explicitly reverse the Round 2 consensus. Label-fixing is a patch on a broken mental model." |
| Architect | "The overloaded autonomous_identity type is a semantic black hole. It conflates things that authenticate with things that define logic." |
| CISO | "Classifying all artifacts as identity inflates NHI counts by 13-18x and undermines compliance reporting." |
| Integrator | "The current model conflates 'can execute autonomously' with 'is executable code'. Script Includes are libraries called BY identities, not identities themselves." |
| Developer | "Every automation artifact is incorrectly typed as entity_type: 'identity'. This is semantically wrong because these are not identities that authenticate." |
2. Unanimous Agreement: These Are NOT Identities
All 6 roles agree on at least three artifacts that must be reclassified:
| Artifact | Authenticates? | Has own authz? | Actor in logs? | All 6 agree: Identity? |
|---|---|---|---|---|
| Script Include | No | No (inherits caller) | No | NO — code library |
| REST Message | No | No | No | NO — connection config |
| OAuth Profile | No (stores creds, doesn't authenticate) | No | No | NO — credential |
These three have zero identity properties. Every role agrees they must move out of entity_type: "identity".
3. The Key Disagreement: Business Rules, Flows, Scheduled Jobs
Position A: Reclassify as automation type (5 advocates)
OAA Specialist, Product Owner, Architect, CISO, Developer recommend moving BRs/Flows/Jobs to a new automation entity type.
Their argument: A Business Rule does not authenticate. It does not have credentials. It does not appear as the actor in audit logs. It RUNS IN a system context or caller context, but it IS NOT that context. The RUNS_AS relationship connects the artifact to the identity — they are two separate entities.
| Artifact | Authenticates? | Has own authz? | Actor in logs? | Identity? |
|---|---|---|---|---|
| Business Rule | No | No (runs in caller/system context) | No (trigger, not actor) | NO |
| Flow Designer Flow | No | Partially (configured "Run As") | Partially | NO |
| Scheduled Job | No | Partially (configured user) | Partially | NO |
Architect's key point: "Multiple automations can delegate to the same identity, and automations have independent lifecycle from the identities they delegate to. This is a delegation relationship, not an identity equivalence."
CISO's key point: "When I ask 'how many NHIs do I have?', I want the answer to be 5-7, not 92. Business Rules are things I MONITOR, not things I GOVERN as identities."
Position B: Keep BRs/Flows/Jobs as autonomous_identity (1 advocate)
Integrator recommends keeping BRs, Flows, and Scheduled Jobs as identities because they CAN execute autonomously and have their own execution context.
Their argument: A Business Rule fires on a database event without human intervention. It runs code. It has an execution context (system or configured user). It produces effects. This is meaningfully different from a Script Include (which is passive code) or a REST Message (which is config data).
| Artifact | Can Execute Autonomously? | Has Identity Context? | Keep as Identity? |
|---|---|---|---|
| Business Rule | Yes (on event trigger) | Yes (runs as user) | YES |
| Flow Designer Flow | Yes (on trigger) | Yes (flow owner) | YES |
| Scheduled Job | Yes (on schedule) | Yes (configured user) | YES |
Integrator's key point: "The discriminating question isn't 'does it authenticate?' — it's 'can it execute autonomously?' A BR DOES execute autonomously. It just delegates authentication."
Resolution: Team Recommends Position A (5/6)
The majority view is that "can execute autonomously" is not the same as "is an identity." A cron job executes autonomously but nobody calls it an identity. A Roomba executes autonomously but it's not an identity — it uses an identity (WiFi credentials, cloud account) to connect. The BR is the Roomba; the SP is the identity.
The deciding factor: The CISO's governance model. Identities are things you GOVERN (rotate credentials, review access, disable on offboarding). Automations are things you MONITOR (review logic, check execution evidence, trace chains). These are different processes with different controls.
4. Proposed Entity Type Classification
The Identity Test (Decision Tree)
Q1: Does this entity authenticate (have credentials, log in)?
YES → identity
NO ↓
Q2: Does this entity store/manage authentication material?
YES → credential
NO ↓
Q3: Does this entity define executable behavior/logic?
YES → automation
NO ↓
Q4: Does this entity define an outbound connection/endpoint?
YES → connection
NO ↓
Q5: Is this entity data that gets read/written/protected?
YES → resource
NO → Review (may need new type)
Per-Artifact Classification (Team Consensus)
| Artifact | Current Type | Proposed Type | Why |
|---|---|---|---|
| Service Principal | identity | identity | Authenticates, has roles, actor in logs |
| OAuth App Registration | identity | identity | Authenticates, has credentials |
| Machine Account | identity | identity | Authenticates with credentials |
| Integration User | identity | identity | Authenticates to ServiceNow |
| Business Rule | identity | automation | Defines execution logic, does not authenticate |
| Script Include | identity | automation | Reusable code library, does not authenticate |
| Flow Designer Flow | identity | automation | Orchestration artifact, does not authenticate |
| Scheduled Job | identity | automation | Time-triggered automation, does not authenticate |
| REST Message | resource | connection | Outbound HTTP endpoint configuration |
| OAuth Provider | identity | credential | Stores authentication material (token endpoint, client_id) |
| OAuth Profile | identity | credential | Stores client secret, token configuration |
| Incident Table | resource | resource | Data that gets read/written (unchanged) |
| Graph API Endpoint | resource | resource | External API target (unchanged) |
| Role Assignment | role | role | Permission grouping (unchanged) |
| Permission/Scope | permission | permission | Individual capability (unchanged) |
| Human User | human_identity | owner | Human who owns/created artifacts (PO proposes rename) |
Proposed NormalizedNodeType Enum
export type NormalizedNodeType =
| "identity" // Things that authenticate: SP, OAuth App, machine account, integration user
| "automation" // Things that define execution logic: BR, SI, Flow, Scheduled Job
| "connection" // Outbound integration configs: REST Message, SOAP Message, HTTP Connection
| "credential" // Authentication material: OAuth Provider/Profile, API Key, Certificate
| "owner" // Human users who own/create things (renamed from human_identity)
| "role" // Permission groupings (unchanged)
| "permission" // Individual capabilities (unchanged)
| "resource" // Data objects, tables, APIs (unchanged)
| "execution_evidence"; // Proof of execution (unchanged)
Changes from current enum:
autonomous_identity→ split intoidentity+automation+connection+credentialhuman_identity→ renamed toowner(PO recommendation)role,permission,resource,execution_evidence→ unchanged
Subtype System
// Things that authenticate
export type IdentitySubtype =
| "service_principal"
| "oauth_app"
| "machine_account"
| "integration_user"
| "system_execution"; // ServiceNow "system" context
// Things that define execution logic
export type AutomationSubtype =
| "business_rule"
| "script_include"
| "flow_designer_flow"
| "scheduled_job"
| "event_script"
| "transform_map";
// Outbound connection configs
export type ConnectionSubtype =
| "rest_message"
| "rest_method" // individual HTTP method within a REST message
| "soap_message"
| "http_connection";
// Authentication material
export type CredentialSubtype =
| "oauth_provider"
| "oauth_profile"
| "api_key"
| "certificate"
| "client_secret";
5. Corrected AzureGraphRouter Execution Chain
Current (Wrong)
[identity:business_rule] AzureGraphRouter
--CALLS--> [identity:system_execution] AzureGraphRouterSI
--CALLS--> [resource] Azure Graph REST Message
--AUTHENTICATES_TO--> [identity] OAuth Profile
--AUTHENTICATES_TO--> [identity:service_principal] SP-AzureGraph
Proposed (Correct)
[automation:business_rule] AzureGraphRouter
--CALLS--> [automation:script_include] AzureGraphRouterSI
--INVOKES--> [connection:rest_message] Azure Graph REST
--USES--> [credential:oauth_profile] AzureGraphOAuth
--AUTHENTICATES_AS--> [identity:service_principal] SP-AzureGraph
--HAS_ROLE--> [role] Directory.Read.All
--GRANTS--> [permission] User.Read.All
--APPLIES_TO--> [resource] Graph API /users
What this communicates:
- The chain starts with an automation (not an identity)
- It flows through code (automation), connection config, credential
- Only at the end does it reach an actual identity (the SP)
- Each node's type tells you what it IS, not just what it does
Edge Type Updates
| Edge | From Type | To Type | Meaning |
|---|---|---|---|
CALLS | automation | automation | Automation invokes code |
INVOKES | automation | connection | Code uses connection config |
USES | connection | credential | Connection uses auth material |
AUTHENTICATES_AS | credential | identity | Credential represents this identity |
RUNS_AS | automation | identity | Automation executes in this identity's context |
TRIGGERS_ON | automation | resource | Automation fires when resource changes |
HAS_ROLE | identity | role | Identity has this role (unchanged) |
GRANTS | role | permission | Role grants this permission (unchanged) |
APPLIES_TO | permission | resource | Permission applies to this resource (unchanged) |
OWNED_BY | any | owner | Entity owned by this human (unchanged) |
CREATED_BY | any | owner | Entity created by this human (unchanged) |
6. Impact on Key Metrics (CISO Assessment)
NHI Count
| Metric | Current (Wrong) | Proposed (Correct) |
|---|---|---|
| "How many NHIs?" | 92 (inflated by artifacts) | ~8-15 (only authenticating entities) |
| "How many automations?" | Must filter subtypes | Direct query: entity_type: "automation" |
| "How many credentials to rotate?" | Mixed in with identities | Direct query: entity_type: "credential" |
| "What connects externally?" | Must trace execution paths | Direct query: entity_type: "connection" |
Compliance Reporting (CISO)
| Control | Current Problem | After Reclassification |
|---|---|---|
| CC6.1 (Access Controls) | Identity count inflated 13-18x in reports | Accurate identity inventory |
| CC7.1 (Monitoring) | Automation monitoring mixed with identity governance | Separate governance processes |
| A.5.9 (Asset Inventory) | Asset types conflated | Clean asset categories (identities, automations, credentials) |
| SOX ITGC | NHI inventory unreliable | Accurate NHI count for attestation |
7. OAA Export Mapping (OAA Specialist)
| SecurityV0 Type | OAA Export Entity | Fidelity |
|---|---|---|
identity | local_user | HIGH — direct mapping |
automation | resource (type: automation) | HIGH — follows OAA resource pattern |
connection | resource (type: connection) | HIGH — follows OAA resource pattern |
credential | Custom property on local_user | MEDIUM — no OAA credential entity |
role | local_role | HIGH — direct mapping |
permission | custom_permission | HIGH — direct mapping |
resource | resource | HIGH — direct mapping |
Key validation: The OAA Specialist confirmed that in ALL 8 community connectors reviewed (GitHub, GitLab, Jira, PagerDuty, Bitbucket, Slack, Rollbar, Looker), automation-like artifacts are ALWAYS classified as Resources, NEVER as Local Users. The proposed reclassification aligns with industry practice.
8. The Dissenting Position (Documented)
The Integrator disagrees on Business Rules, Flows, and Scheduled Jobs (but agrees on Script Includes, REST Messages, and OAuth Profiles).
Integrator's argument: The discriminating question should be "can it execute autonomously?" not "does it authenticate?" BRs fire on events, Flows trigger on conditions, Scheduled Jobs run on timers. They have execution agency. Script Includes do not.
Integrator's proposal: Minimal change — add one new type (code_artifact) for Script Includes, move OAuth Profiles to credential, keep everything else as-is. This is 16 hours of work vs. the majority's larger reclassification.
Counter-arguments from majority:
- Architect: "A cron job executes autonomously. A thermostat executes autonomously. Autonomous execution is not identity. Identity is about authentication and authorization context."
- CISO: "Identities are things I GOVERN (rotate, review, disable). Automations are things I MONITOR (trace, audit, assess). Different processes, different entity types."
- Product Owner: "If BRs stay as identity, the CISO's identity page still shows 30+ Business Rules mixed with 8 actual service accounts. The UX problem persists."
9. Compatibility with Round 3/4 Conclusions
execution_chains Collection (Round 3)
The reclassification is fully compatible. The execution_chains collection stores entity_refs with role annotations. The entity references work regardless of type:
entity_refs: [
{ entity_id: "uuid-br", role: "entry_point" }, // was identity, now automation
{ entity_id: "uuid-si", role: "code_component" }, // was identity, now automation
{ entity_id: "uuid-rest", role: "outbound_target" }, // was resource, now connection
{ entity_id: "uuid-oauth", role: "auth_credential" }, // was identity, now credential
{ entity_id: "uuid-sp", role: "destination_identity" } // stays identity
]
The chain builder BFS already traverses by edge type, not entity type. Reclassification changes the entity_type field but not the graph topology.
OAA Export (Round 4)
Reclassification makes OAA export cleaner:
identity→ OAAlocal_user(direct, no filtering needed)automation→ OAAresource(natural OAA mapping)- No need to filter "identity but not really identity" artifacts from SCIM exports
10. Implementation Estimate
Product Owner recommendation: Do this BEFORE Round 3 Phase 1 (execution_chains), so chains reference correctly-typed entities from the start.
| Task | Effort | Description |
|---|---|---|
| Update NormalizedNodeType enum + subtypes | 4h | TypeScript type changes |
| Update connector transformer.py | 8h | Emit correct types for each artifact |
| Update StorageAdapter + queries | 8h | Handle new types in storage layer |
| Update path materializer | 4h | Traverse mixed types correctly |
| Update finding evaluator | 4h | Adjust type-based finding logic |
| Update UI entity pages | 8h | Separate Identities/Automations/Credentials pages |
| Update tests | 12h | Fix existing + add new tests |
| Update architecture docs | 4h | 01-data-model.md, 03-database.md |
| Total | ~52h | ~1.5 weeks |
11. Answer to the Core Question
"What entity type should Business Rules, Script Includes, REST Messages, etc. be?"
Team Answer:
| Artifact | Correct Type | Decision Basis |
|---|---|---|
| Business Rule | automation | Defines execution logic; does not authenticate |
| Script Include | automation | Code library; does not authenticate |
| Flow Designer Flow | automation | Orchestration artifact; does not authenticate |
| Scheduled Job | automation | Time-triggered artifact; does not authenticate |
| REST Message | connection | Outbound endpoint config; not code or identity |
| OAuth Provider | credential | Stores authentication material |
| OAuth Profile | credential | Stores client secret and token config |
| Service Principal | identity | Authenticates, has roles, actor in logs |
The decision tree is simple: Does it authenticate? → identity. Does it store auth material? → credential. Does it define logic? → automation. Does it define a connection? → connection. Is it data? → resource.
What Changed from Previous Rounds
| Round | Position on BR/SI classification |
|---|---|
| Round 1 | Keep as identity, fix UI labels |
| Round 2 | Keep as identity, fix UI labels (unanimous) |
| Round 3 | Keep as identity, add execution_chains (didn't question typing) |
| Round 4 | Keep as identity internally, project as resource for OAA (no type changes) |
| Round 5 | Reclassify: automation, connection, credential (5/6 majority) |
The shift happened because the founder removed the migration cost constraint. Rounds 1-4 optimized for stability. Round 5 optimized for correctness.
12. Files Produced (Round 5)
| File | Role | Lines | Key Topics |
|---|---|---|---|
| 05-entity-typing-oaa-specialist.md | OAA Specialist | 1,218 | Community connector evidence, 9-question decision tree, dual-nature debunked |
| 05-entity-typing-product-owner.md | Product Owner | 1,299 | CISO mental model, 5-type UX taxonomy, Round 2 reversal, chain visualization |
| 05-entity-typing-ciso.md | CISO | 1,400 | NHI count inflation, 5 governance categories, compliance mapping, forensic impact |
| 05-entity-typing-architect.md | Architect | 1,457 | 9-type hierarchy, per-artifact identity test, RUNS_AS vs IS, corrected graph |
| 05-entity-typing-integrator.md | Integrator | 1,073 | Source system models, "can execute" test, dissent: keep BRs as identity |
| 05-entity-typing-developer.md | Developer | 1,397 | Code impact (47 files), TypeScript types, 168h impl plan, rollback strategy |
| 05-entity-typing-synthesis.md | Lead | This document |
Round 5 analysis complete. 6 perspectives, ~7,844 lines. Unanimous: current model is wrong. 5/6 majority: reclassify BRs/SIs/Flows/Jobs as automation, REST Messages as connection, OAuth Profiles as credential. 1 dissent: Integrator keeps BRs as identity. Estimated effort: ~52h (~1.5 weeks). Recommended: do this BEFORE execution_chains implementation.