OAA Mapping Analysis -- Product Owner

Role: Product Owner Date: 2026-02-13 (Round 4) Core Question: Given OAA's entity model (Application, Local User, Resource, Permission), how should SecurityV0 model automation execution chains for maximum product value, standards compliance, and CISO intuitiveness?

---

Table of Contents

1. Founder's Insight: The Mapping Challenge
2. OAA Entity Model Analysis
3. Approach A: Automation as OAA Application
4. Approach B: Automation as OAA Resource
5. Approach C: Hybrid (Application + Resources)
6. Approach D: Separate Collection (Round 3 Recommendation)
7. User Stories Under Each Approach
8. UI Text Mockups
9. API Surface Comparison
10. SCIM Export Implications
11. SIEM/SOAR Consumption Patterns
12. Scoring Matrix
13. Where OAA Alignment Creates Value
14. Where OAA Alignment Destroys Value
15. Recommendation

---

1. Founder's Insight: The Mapping Challenge

The founder's observation is precise and architecturally significant:

"OAA has application notion, not only identity. So stuff like script include, business flow looks more like an application, but not identity. Furthermore autonomous execution also could be treated either as application, or a collection of applications, identities, roles, data modifications. When there is an incident trigger - can it be 'data' or 'resource', and when updating some data later like incident table - it looks like a change to 'data' or 'resource' as well."

This statement identifies a fundamental tension in how SecurityV0 models automation artifacts. Let me decompose it:

Tension 1: Identity vs. Application

Currently, SecurityV0 models automation artifacts (business rules, script includes, flows) as Identity subtypes. The justification: they participate in execution paths, hold roles (via RUNS_AS), and are the "who" in "who can do what."

OAA's model is different. OAA has two top-level containers:

• Application -- a thing that HAS users, roles, permissions, and resources
• Identity (Local User) -- a thing that IS GRANTED permissions

A business rule is not intuitively an "identity." It does not authenticate. It does not hold credentials. It is a code artifact that executes in a context. In OAA terms, it is either:

• An Application -- a self-contained thing with its own users and resources
• A Resource -- a data/system component within an application

Tension 2: Trigger as Data vs. Trigger as Event

When an incident is inserted into the incident table, that triggers a business rule. In OAA terms:

• The incident table is a Resource (with DataWrite permission implied)
• The insert event is an action on that resource
• But from the automation's perspective, the insert is a trigger, not a data operation

OAA has no concept of "trigger." Its permission model is CRUD-oriented (DataRead, DataWrite, DataCreate, DataDelete, MetadataRead, MetadataWrite, NonData). An event trigger maps to... nothing in OAA's canonical permission set.

Tension 3: Outcome as Permission vs. Outcome as Action

When the automation writes to the incident table (setting assignment group) and then calls graph.microsoft.com to route teams, these are outcomes. In OAA terms:

• Writing to incident = DataWrite on the incident Resource
• Calling graph.microsoft.com = DataWrite on an external Resource

This actually maps reasonably well to OAA's model. The problem is that OAA captures the permission to act, not the execution flow (trigger -> process -> outcome).

The Core Question for Product

The question is not "can we force automations into OAA categories?" -- we can always force-fit. The question is: does force-fitting create or destroy value for the CISO?

A CISO using SecurityV0 needs to answer:

1. "What automations do we have?" (inventory)
2. "What can each automation do?" (blast radius)
3. "Who is accountable for each automation?" (ownership)
4. "How has each automation changed?" (drift)
5. "Is this automation still needed?" (justification)

The OAA mapping must make these questions easier to answer, not harder. If shoehorning automations into OAA categories creates confusion, we should deviate from OAA and document why.

---

2. OAA Entity Model Analysis

OAA's Core Structure (from Veza documentation and community connectors)

Having studied the OAA community connectors (GitHub, Jira, PagerDuty, Slack), here is the pattern every connector follows:

Provider
  └── Application (e.g., "GitHub - my-org", "Jira - instance.atlassian.net")
        ├── local_users[]       (identities within the app)
        ├── local_groups[]      (grouping construct for users)
        ├── local_roles[]       (named permission bundles)
        ├── custom_permissions[] (app-specific, map to OAA canonical types)
        ├── resources[]         (things users have permissions on)
        │     └── sub_resources[] (nested resources)
        └── identity_to_permissions[]  (the authorization edges)

Key Observations from Real OAA Connectors

1. Application = "the SaaS product" or "the organizational unit within a SaaS product."

• GitHub connector: Application("Github - {org_name}", "Github") -- one app per GitHub org
• Jira connector: CustomApplication("Jira - {instance}", "Jira") -- one app per Jira instance
• PagerDuty connector: CustomApplication("PagerDuty - {subdomain}", "PagerDuty") -- one app per PD subdomain
• Slack connector: CustomApplication("Slack - {team_name}", "Slack") -- one app per Slack workspace

The Application is always a top-level system boundary. It is never a feature, workflow, or script within a system.

2. Resource = "something you can have permissions on."

• GitHub: repositories are Resources (type: "repository")
• Jira: projects are Resources (type: "project")
• PagerDuty: teams are Resources (type: "team")

Resources are data containers or organizational units. They are things that hold data or configuration that users interact with.

3. Local User = "an entity with an identity that can be granted permissions."

• GitHub: organization members
• Jira: Atlassian users
• PagerDuty: PagerDuty users

Local Users are always human-like or at least identity-like. They have names, emails, statuses (active/inactive), and credentials (implicitly, via the IdP correlation).

4. Permissions are always CRUD-mapped.

Every connector maps source-system permissions to OAA's 10 canonical types. This is a CRUD-centric authorization model. There is no concept of "execute", "trigger", "schedule", or "chain."

What OAA Does NOT Model

Concept	OAA Coverage	Gap
Execution flow (A triggers B which calls C)	Not modeled	OAA is a permission snapshot, not a process model
Temporal drift (permissions changed over time)	Not modeled	OAA is snapshot-only; no versioning
Ownership accountability (who is responsible)	Partial	Local User has identities for IdP correlation, but no ownership hierarchy
Evidence (proof that X actually executed)	Not modeled	OAA captures authorization, not execution evidence
Trigger/event semantics	Not modeled	Permission model is CRUD; no trigger concept
Cross-system execution chains	Not modeled	Each Application is isolated; no cross-app relationships
Credential lifecycle	Not modeled	No concept of credential rotation, expiry, or status

This table is critical for the scoring exercise. OAA covers authorization structure. SecurityV0's differentiators (temporal, evidence, ownership, execution flow) are entirely beyond OAA's scope. Any OAA mapping is inherently a lossy projection.

---

3. Approach A: Automation as OAA Application

The Model

Each execution chain is modeled as an OAA Application. The chain's components become the Application's internal entities:

Application: "AzureGraphRouter Incident Routing"
  application_type: "execution_chain"

  local_users:
    - name: "sn-ticket-router" (Entra SP)
      user_type: "service_principal"
      custom_properties:
        sv0_chain_role: "destination_identity"
    - name: "sn-integration-user" (ServiceNow)
      user_type: "integration_user"
      custom_properties:
        sv0_chain_role: "executor"

  local_roles:
    - name: "itil"
    - name: "hr_agent_workspace"
    - name: "personalize"
    - name: "task_editor"

  permissions:
    - name: "incident.write" -> [DataWrite]
    - name: "hr_case.crud" -> [DataRead, DataWrite, DataCreate, DataDelete]
    - name: "sys_user.write" -> [DataWrite]

  resources:
    - name: "incident" (type: "table", domain: "it_ops", sensitivity: "internal")
    - name: "hr_case" (type: "table", domain: "hr", sensitivity: "confidential")
    - name: "sys_user" (type: "table", domain: "security", sensitivity: "confidential")
    - name: "graph.microsoft.com" (type: "external_api", domain: "identity_platform")

  custom_properties:
    sv0_chain_trigger: "incident table insert"
    sv0_chain_destination: "graph.microsoft.com"
    sv0_owner_status: "orphaned"
    sv0_execution_mode: "autonomous"
    sv0_security_relevance: "active_external"
    sv0_first_seen: "2025-03-10"
    sv0_composition_hash: "sha256:abc..."

What the CISO Sees

Automation Inventory (OAA Applications list):

APPLICATIONS (by Type: execution_chain)
+-----------------------------------------------------------------------+
| Application                         | Users | Resources | Risk       |
+-----------------------------------------------------------------------+
| AzureGraphRouter Incident Routing   | 2     | 4         | CRITICAL   |
| HR Onboarding Workflow              | 1     | 2         | MEDIUM     |
| AI Triage via Azure OpenAI          | 2     | 3         | HIGH       |
+-----------------------------------------------------------------------+

Each automation appears as a self-contained Application with its own users (the identities it uses), roles, permissions, and resources (what it touches). This is conceptually clean: the automation IS a mini-application.

Drill into "AzureGraphRouter Incident Routing":

The CISO sees the Application detail with:

• Users: The identities this automation operates as (SP, integration user)
• Resources: The tables and APIs this automation touches
• Permissions: What the automation can do on each resource
• Custom Properties: SecurityV0-specific metadata (trigger, destination, ownership status)

Strengths

1. Conceptual clarity. An automation IS a logical application. It has users, permissions, and resources. The OAA Application container maps naturally.
2. Self-contained context. All chain information is in one Application payload. No cross-referencing needed.
3. Natural listing. "List all execution_chain Applications" gives the CISO an automation inventory.
4. Veza integration. If SecurityV0 pushes to Veza, each automation appears as a separate discoverable Application in Veza's graph.
5. Permission visibility. The automation's permissions are explicit: what it can read, write, delete on which resources.

Weaknesses

1. Entity duplication. sn-ticket-router (the SP) is also a Local User in the "Entra ID" Application. Now it appears in two Applications. OAA has identity correlation (via identities array), but the SP is now a Local User in two contexts. This creates confusion: "Is this SP used by 1 application or 2?"

2. Application proliferation. If a ServiceNow instance has 15 automation chains, the OAA export has 15 Applications of type execution_chain plus the 2 actual Applications (Entra ID, ServiceNow). A Veza consumer sees 17 Applications where they expected 2.

3. Resource duplication. The incident table is a Resource in both the "ServiceNow" Application (where it is discovered) and the "AzureGraphRouter" Application (where it is a chain member). Which is canonical?

4. OAA semantics violation. In every OAA community connector, an Application represents a real SaaS product or system boundary. Making an automation chain an Application breaks this convention. A Veza customer who asks "how many applications do we have?" gets a count that includes automation chains alongside real apps.

5. No trigger concept. The trigger ("incident table insert") has to be stuffed into custom_properties because OAA has no trigger/event concept. The CISO sees it as metadata, not as a structural element.

6. Temporal gap. OAA is snapshot-based. "How has this Application changed since last month?" is not an OAA question. SecurityV0's temporal model would need to operate entirely outside OAA's structure.

CISO Mental Model Test

Question: "Show me all automations that can write to HR data."

With Automation-as-Application:

1. List all Applications of type execution_chain
2. Filter where Resources include any with domain: "hr"
3. Filter where Permissions include DataWrite on those Resources

This works. The query is natural in OAA terms.

Question: "Show me the SP sn-ticket-router and all the automation chains it participates in."

With Automation-as-Application:

1. Search for Local User sn-ticket-router across all Applications
2. The SP appears in: "Entra ID" (source app) and "AzureGraphRouter" (chain app)
3. The CISO sees two Application contexts for one identity

This is confusing. The SP is not "in" the AzureGraphRouter application in the way a GitHub user is "in" the GitHub application. The SP participates in a chain that the AzureGraphRouter Application represents. OAA's flat local_users list does not convey this participation semantics.

---

4. Approach B: Automation as OAA Resource

The Model

Automation chains are modeled as Resources within their primary source system Application. The chain is a "thing" within ServiceNow (or wherever the trigger lives), and its components are sub-resources:

Application: "ServiceNow - corp.service-now.com"
  application_type: "servicenow"

  local_users:
    - name: "sn-integration-user"
      roles: ["itil", "hr_agent_workspace", "personalize", "task_editor"]

  resources:
    - name: "incident" (type: "table")
    - name: "hr_case" (type: "table")
    - name: "sys_user" (type: "table")
    - name: "AzureGraphRouter Incident Routing" (type: "execution_chain")
        sub_resources:
          - name: "incident (trigger)" (type: "trigger_resource")
          - name: "Business Rule: Auto-route" (type: "code_artifact")
          - name: "Script Include: AzureGraphRouter" (type: "code_artifact")
          - name: "REST Message: graph.microsoft.com" (type: "external_endpoint")
          - name: "incident (outcome: DataWrite)" (type: "outcome_resource")
          - name: "hr_case (outcome: DataWrite)" (type: "outcome_resource")

  identity_to_permissions:
    - identity: "sn-integration-user"
      permission: "DataWrite"
      resource: "AzureGraphRouter Incident Routing"

The founder's specific insight maps here: the incident table when it triggers the automation is a "trigger_resource" (Resource with DataRead), and when the automation writes back to a table, that is an "outcome_resource" (Resource with DataWrite). The OAA Resource with sub-resources captures the flow structure as a resource hierarchy.

What the CISO Sees

Resource Browser (within ServiceNow Application):

RESOURCES in ServiceNow
+-----------------------------------------------------------------------+
| Resource                              | Type             | Users      |
+-----------------------------------------------------------------------+
| incident                              | table            | 15 users   |
| hr_case                               | table            | 3 users    |
| sys_user                              | table            | 8 users    |
| AzureGraphRouter Incident Routing     | execution_chain  | 1 user     |
|   ├── incident (trigger)              | trigger_resource |            |
|   ├── BR: Auto-route identity tickets | code_artifact    |            |
|   ├── SI: AzureGraphRouter            | code_artifact    |            |
|   ├── REST: graph.microsoft.com       | external_endpoint|            |
|   ├── incident (outcome)              | outcome_resource |            |
|   └── hr_case (outcome)              | outcome_resource |            |
| HR Onboarding Workflow                | execution_chain  | 1 user     |
+-----------------------------------------------------------------------+

Strengths

1. No entity duplication. sn-integration-user appears once, in the ServiceNow Application. The automation chain is just another Resource that this user has permissions on.

2. Hierarchical structure. OAA's sub-resource model naturally captures the chain's components. Trigger, code, auth, and outcome are sub-resources of the chain resource.

3. OAA convention conformance. Resources are "things within an application." An automation chain is a thing within ServiceNow. It is managed, configured, and executed within ServiceNow's boundary.

4. Permission semantics work. The identity_to_permissions edge says "sn-integration-user has DataWrite on AzureGraphRouter chain." This is a valid OAA statement.

5. Application count stays sane. The Veza consumer sees 2 Applications (Entra ID, ServiceNow), not 17. Automations are Resources within ServiceNow, which is correct.

Weaknesses

1. Cross-system chains break the model. AzureGraphRouter spans ServiceNow AND Entra ID AND Microsoft Graph. Placing it as a Resource under "ServiceNow" is misleading. The SP sn-ticket-router is not a ServiceNow entity -- it is an Entra ID entity. The OAA model forces the chain into one Application's resource tree.

2. Resource semantics mismatch. OAA Resources are things you have permissions ON. A table is a Resource because you can read/write it. But an execution chain is not something you "have permissions on" -- it is something that EXECUTES. The identity does not "have DataWrite on the AzureGraphRouter chain." The identity executes AS the chain. The OAA permission arrow points the wrong direction.

3. Trigger/outcome sub-resources are redundant. The incident table already exists as a top-level Resource. Making it also a sub-resource of the chain (as "incident (trigger)" and "incident (outcome)") creates two representations of the same table with different semantic roles. OAA has no way to express "this sub-resource is a reference to that top-level resource."

4. Chain-level queries are awkward. "List all execution chains" requires filtering Resources by type execution_chain across all Applications. OAA's standard queries are user-centric ("what can user X access?"), not resource-type-centric ("list all resources of type Y").

5. Execution flow is invisible. The sub-resource hierarchy shows components but not flow. "Trigger -> code -> auth -> outcome" is a directed sequence. OAA sub-resources are a containment hierarchy, not a flow. The CISO sees nested items, not a directed chain.

CISO Mental Model Test

Question: "Show me all automations that can write to HR data."

With Automation-as-Resource:

1. Find Resources of type execution_chain
2. Inspect their sub-resources for outcome_resources in the HR domain
3. This works, but requires understanding the sub-resource structure

Question: "Who has access to the AzureGraphRouter automation?"

With Automation-as-Resource:

1. Find Resource "AzureGraphRouter Incident Routing"
2. Query identity_to_permissions for this Resource
3. Returns: "sn-integration-user has DataWrite"

But this is misleading. sn-integration-user does not "have access to" the automation in the way they "have access to" the incident table. The user does not read or write the automation. The user IS the automation's runtime identity. OAA cannot express this distinction.

---

5. Approach C: Hybrid (Application + Resources)

The Model

The automation chain is an OAA Application. The trigger and outcome tables remain Resources in their source system Applications. Cross-references link them:

Application: "ServiceNow - corp.service-now.com"
  resources:
    - name: "incident" (type: "table")
    - name: "hr_case" (type: "table")
    - name: "sys_user" (type: "table")
  local_users:
    - name: "sn-integration-user"

Application: "Entra ID - contoso-prod"
  local_users:
    - name: "sn-ticket-router" (SP)

Application: "AzureGraphRouter Incident Routing" (type: "execution_chain")
  local_users:
    - name: "sn-integration-user"  (reference to ServiceNow user)
      custom_properties:
        sv0_chain_role: "executor"
        sv0_source_application: "ServiceNow - corp.service-now.com"
    - name: "sn-ticket-router"  (reference to Entra SP)
      custom_properties:
        sv0_chain_role: "destination_identity"
        sv0_source_application: "Entra ID - contoso-prod"
  resources:
    - name: "incident (trigger: insert)"
      resource_type: "trigger"
      custom_properties:
        sv0_source_resource: "ServiceNow/incident"
        sv0_canonical_permission: "DataRead"
    - name: "incident (outcome: write)"
      resource_type: "outcome"
      custom_properties:
        sv0_source_resource: "ServiceNow/incident"
        sv0_canonical_permission: "DataWrite"
    - name: "hr_case (outcome: CRUD)"
      resource_type: "outcome"
      custom_properties:
        sv0_source_resource: "ServiceNow/hr_case"
    - name: "graph.microsoft.com (outcome: API call)"
      resource_type: "external_endpoint"
  permissions:
    - name: "trigger_read" -> [DataRead]
    - name: "outcome_write" -> [DataWrite]
    - name: "external_call" -> [NonData]
  identity_to_permissions:
    - identity: "sn-integration-user"
      permission: "outcome_write"
      resources: ["incident (outcome)", "hr_case (outcome)"]
    - identity: "sn-ticket-router"
      permission: "external_call"
      resources: ["graph.microsoft.com (outcome)"]

What the CISO Sees

The CISO sees three categories of Applications:

• Source System Applications (Entra ID, ServiceNow) -- discovered infrastructure
• Execution Chain Applications (AzureGraphRouter, etc.) -- derived by SecurityV0

The execution chain Application is a self-contained view: who runs the chain, what it reads (triggers), what it writes (outcomes), and where it goes (external endpoints).

Strengths

1. Cross-system chains are explicit. The chain Application contains references to users from both ServiceNow and Entra ID. The cross-system nature is visible.

2. Trigger/outcome semantics. Resources within the chain Application are typed as "trigger" or "outcome," mapping to the founder's insight about data-as-resource in both directions.

3. Permission flow visible. sn-integration-user has outcome_write on incident (outcome). sn-ticket-router has external_call on graph.microsoft.com. The CISO sees the permission flow through the chain.

4. Veza graph potential. If pushed to Veza, the chain Application links to IdP identities via identity correlation. Veza could show: "Azure AD User -> SP -> Chain Application -> Outcome Resources." This is a rich query surface.

Weaknesses

1. Maximum entity duplication. Every identity and resource in the chain is duplicated: once in the source Application, once in the chain Application. With 15 chains sharing 30 identities and 50 resources, the export payload balloons with redundant data.

2. Application count explosion. Same problem as Approach A, but now with the additional cognitive load of "which Applications are real systems vs. derived chains?"

3. Synchronization nightmare. When sn-integration-user gets a new role in ServiceNow, both the "ServiceNow" Application AND every chain Application that references this user must be updated. OAA exports are snapshots; keeping them consistent requires re-generating all chain Applications on every sync.

4. Custom property overload. The chain Application uses sv0_source_application, sv0_chain_role, sv0_source_resource, sv0_canonical_permission to link back to source Applications. A Veza consumer must understand these custom properties to make sense of the data. This defeats the purpose of a standard format.

5. OAA semantics are stretched thin. The "trigger" resource with DataRead permission says "the automation reads the incident table to trigger." But the automation does not "have permission to read the incident table" in the way OAA means. The business rule fires because of a table event, not because of a granted permission. We are encoding execution semantics into permission semantics, which is a lossy and potentially misleading translation.

CISO Mental Model Test

Question: "How many applications do we have?"

With Hybrid:

1. Count all Applications: 17 (2 source systems + 15 chains)
2. CISO asks: "Why do we have 17 applications? I thought we only have Entra ID and ServiceNow."
3. Answer: "15 of those are SecurityV0-derived execution chain Applications."
4. CISO: "That is confusing. Can I filter them out?"

The hybrid approach creates cognitive overhead. The CISO must learn a new Application taxonomy (source vs. derived) that does not exist in OAA's mental model.

---

6. Approach D: Separate Collection (Round 3 Recommendation)

The Model

Round 3 recommended an execution_chains collection as a platform-internal concept. For OAA export, the chain does NOT appear as an Application or Resource. Instead:

• Source system Applications (Entra ID, ServiceNow) are exported as standard OAA payloads
• Automation chain metadata is exported via a SecurityV0 extension (not OAA-compatible)
• The chain's constituent identities appear as Local Users in their respective Applications with SecurityV0-specific custom properties indicating chain membership

Application: "ServiceNow - corp.service-now.com"
  local_users:
    - name: "sn-integration-user"
      custom_properties:
        sv0_chain_memberships: [
          { chain_id: "chain-azuregraphrouter", role: "executor" }
        ]

Application: "Entra ID - contoso-prod"
  local_users:
    - name: "sn-ticket-router"
      custom_properties:
        sv0_chain_memberships: [
          { chain_id: "chain-azuregraphrouter", role: "destination_identity" }
        ]

// Separate endpoint (not OAA):
GET /api/v1/execution-chains
{
  "chains": [
    {
      "id": "chain-azuregraphrouter",
      "name": "AzureGraphRouter Incident Routing",
      "trigger": { "table": "incident", "event": "insert" },
      "destination": "graph.microsoft.com",
      "entity_refs": [...],
      "summary": { ... },
      "composition_hash": "sha256:abc..."
    }
  ]
}

What the CISO Sees

OAA Export: Standard source system Applications with identities, roles, permissions, resources. No chain clutter.

SecurityV0 UI: A separate Automations page (as described in Round 3) with chain-level views, timelines, diffs, and findings.

API: Two surfaces:

1. GET /api/v1/oaa/applications -- standard OAA payloads for source systems
2. GET /api/v1/execution-chains -- SecurityV0-native chain inventory

Strengths

1. Clean OAA compliance. OAA exports contain only what OAA is designed to model: source system authorization metadata. No force-fitting of execution chains into Application/Resource categories.

2. No entity duplication. Each identity appears once, in its source Application.

3. SecurityV0 differentiators preserved. Temporal tracking, evidence chains, ownership hierarchy, execution flow -- all modeled in SecurityV0's native format, not constrained by OAA's snapshot CRUD model.

4. Application count accurate. OAA consumers see 2 Applications (Entra ID, ServiceNow), which matches reality.

5. Future-proof. If OAA evolves to include execution/process concepts (unlikely near-term but possible), SecurityV0 can adopt those extensions without restructuring existing OAA exports.

Weaknesses

1. No OAA representation of chains. A Veza consumer ingesting SecurityV0's OAA export gets identities and permissions but not chain structure. They cannot answer "what automation chains exist?" from OAA data alone.

2. Two API surfaces. Consumers must use OAA endpoints for authorization data and SecurityV0-native endpoints for chain data. This is additional integration work.

3. Custom properties as hints. The sv0_chain_memberships custom property on Local Users is a SecurityV0-specific extension. A Veza consumer that does not understand this property ignores chain membership entirely.

4. No Veza graph integration for chains. If pushed to Veza, the chain structure is invisible. Veza shows "sn-integration-user has these roles" but not "sn-integration-user participates in these execution chains."

---

7. User Stories Under Each Approach

Here I map the 7 user stories from Round 3 to each OAA mapping approach. The question is: does the OAA mapping help or hinder each user story?

US-1: Automation History Timeline

Approach	Impact	Notes
A (Application)	Neutral	OAA is snapshot-only. Timeline is a SecurityV0 feature regardless. Chain Application provides a listing anchor but no temporal data.
B (Resource)	Negative	Chain buried within source Application's resource tree. Timeline must navigate through resource hierarchy.
C (Hybrid)	Neutral	Same as A. Chain Application provides anchor; temporal data is SecurityV0-native.
D (Separate)	Positive	Chain has dedicated API and UI. No OAA constraints on timeline format.

US-2: Automation Comparison (Diff)

Approach	Impact	Notes
A (Application)	Negative	Comparing two OAA Application snapshots is comparing entire payloads. OAA does not support versioned Application payloads. Must be done outside OAA.
B (Resource)	Negative	Comparing sub-resource trees across two snapshots requires custom logic not in OAA.
C (Hybrid)	Negative	Same as A, plus duplication makes diffs larger and harder to parse.
D (Separate)	Positive	Chain comparison is a native SecurityV0 feature on the execution_chains collection. Clean API: GET /execution-chains/:id/compare?v1=X&v2=Y.

US-3: Automation Inventory Listing

Approach	Impact	Notes
A (Application)	Positive	GET /oaa/applications?type=execution_chain gives the listing. Natural fit.
B (Resource)	Negative	Must aggregate Resources of type execution_chain across all Applications. Awkward.
C (Hybrid)	Positive	Same as A, but with Application count confusion.
D (Separate)	Positive	GET /execution-chains is purpose-built.

US-4: Automation Change Alert

Approach	Impact	Notes
A-D	Neutral	Change alerting is entirely a SecurityV0 feature. OAA does not model alerts, events, or notifications. No approach helps or hurts.

US-5: Automation Drift Detection

Approach	Impact	Notes
A (Application)	Negative	OAA Application payloads do not track historical states. Drift detection requires SecurityV0-native temporal comparison, which the chain Application does not provide.
B (Resource)	Negative	Same issue. Resource snapshots are not versioned in OAA.
C (Hybrid)	Negative	Same. Drift detection is outside OAA's scope.
D (Separate)	Positive	Chain versions in execution_chains collection directly support drift detection with composition_hash comparison.

US-6: Continuity Through Entity Rotation

Approach	Impact	Notes
A (Application)	Negative	When OAuth client rotates, the chain Application's local_users list changes. If identity correlation is by entity ID, the Application appears to have a new user. OAA has no concept of "same logical user, new credential."
B (Resource)	Neutral	Sub-resource list changes but the parent Resource persists.
C (Hybrid)	Negative	Same as A, compounded by duplication.
D (Separate)	Positive	Chain identity is anchored to entry point. Credential rotation updates entity_refs but chain ID persists. This is the core design of the execution_chains collection.

US-7: Cross-Automation Impact Analysis

Approach	Impact	Notes
A (Application)	Positive	"Which Applications share this Local User?" is a natural OAA query. Veza could compute this from the graph.
B (Resource)	Negative	Resources do not share users across sub-resource trees. Must query identity_to_permissions across resource types.
C (Hybrid)	Positive	Same as A. Cross-Application user queries work.
D (Separate)	Positive	entity_refs in execution_chains directly support "which chains reference entity X?" queries.

Summary: User Story Impact

User Story	A (App)	B (Resource)	C (Hybrid)	D (Separate)
US-1: Timeline	0	-1	0	+1
US-2: Comparison	-1	-1	-1	+1
US-3: Listing	+1	-1	+1	+1
US-4: Alerts	0	0	0	0
US-5: Drift	-1	-1	-1	+1
US-6: Rotation	-1	0	-1	+1
US-7: Cross-chain	+1	-1	+1	+1
Net	-1	-5	-1	+6

---

8. UI Text Mockups

Approach A: Automation as Application -- OAA Export Page

+------------------------------------------------------------------------+
| OAA EXPORT                                                              |
+------------------------------------------------------------------------+
| Applications (17)                                    [Export JSON]       |
+------------------------------------------------------------------------+
| TYPE: source_system (2)                                                 |
| +--------------------------------------------------------------------+ |
| | Entra ID - contoso-prod          | 142 users | 38 roles | 89 res  | |
| | ServiceNow - corp.service-now.com| 215 users | 52 roles | 134 res | |
| +--------------------------------------------------------------------+ |
|                                                                         |
| TYPE: execution_chain (15)                                              |
| +--------------------------------------------------------------------+ |
| | AzureGraphRouter Incident Routing| 2 users   | 4 roles  | 4 res   | |
| | HR Onboarding Workflow           | 1 user    | 2 roles  | 2 res   | |
| | AI Triage via Azure OpenAI       | 2 users   | 3 roles  | 3 res   | |
| | ... (12 more)                    |           |          |         | |
| +--------------------------------------------------------------------+ |
|                                                                         |
| WARNINGS:                                                               |
| [!] 15 execution_chain Applications are SecurityV0-derived.             |
|     Some OAA consumers may not expect derived Applications.             |
|     Custom property 'sv0_chain_role' is required to interpret users.    |
+------------------------------------------------------------------------+

Approach B: Automation as Resource -- Resource Browser

+------------------------------------------------------------------------+
| ServiceNow - corp.service-now.com > Resources                          |
+------------------------------------------------------------------------+
| Resource                             | Type              | Permissions |
+------------------------------------------------------------------------+
| incident                             | table             | 15 users    |
| hr_case                              | table             | 3 users     |
| change_request                       | table             | 8 users     |
| sys_user                             | table             | 12 users    |
| ---                                  |                   |             |
| AzureGraphRouter Incident Routing    | execution_chain   | 1 user      |
|   +-- incident (trigger: insert)     | trigger_resource  |             |
|   +-- BR: Auto-route identity tix    | code_artifact     |             |
|   +-- SI: AzureGraphRouter           | code_artifact     |             |
|   +-- REST: graph.microsoft.com      | external_endpoint |             |
|   +-- incident (outcome: write)      | outcome_resource  |             |
|   +-- hr_case (outcome: write)       | outcome_resource  |             |
| ---                                  |                   |             |
| HR Onboarding Workflow               | execution_chain   | 1 user      |
|   +-- hr_case (trigger: insert)      | trigger_resource  |             |
|   +-- Flow: HR Onboard               | code_artifact     |             |
|   +-- hr_case (outcome: update)      | outcome_resource  |             |
+------------------------------------------------------------------------+

Approach D: Separate Collection -- SecurityV0 Native

+------------------------------------------------------------------------+
| AUTOMATIONS                                        [OAA] [Native JSON] |
+------------------------------------------------------------------------+
|                                                                         |
| This view shows execution chains tracked by SecurityV0.                |
| OAA export available separately at /api/v1/oaa/applications.           |
|                                                                         |
| Chain                              | Entities | Egress     | Owner     |
+------------------------------------------------------------------------+
| [!] AzureGraphRouter               | 6        | external   | ORPHANED  |
|     incident (insert) -> graph.microsoft.com                            |
|                                                                         |
| [!] AI Triage via Azure OpenAI     | 3        | external   | Active    |
|     sc_request (submit) -> api.openai.com                              |
|                                                                         |
| [ ] HR Onboarding Workflow         | 4        | internal   | IT Team   |
|     hr_case (insert) -> internal                                       |
+------------------------------------------------------------------------+
| OAA Note: Execution chains are not part of OAA export because OAA      |
| does not model execution flow, temporal drift, or ownership hierarchy. |
| Source system authorization data is exported via OAA-compliant APIs.    |
+------------------------------------------------------------------------+

---

9. API Surface Comparison

Approach A: Automation as Application

OAA Endpoints:

GET /api/v1/oaa/applications
  Returns: All applications including execution_chain types
  Filter: ?type=execution_chain (SecurityV0 extension)

GET /api/v1/oaa/applications/{chain-id}
  Returns: Full OAA payload for the execution chain
  Includes: local_users, permissions, resources (chain members as OAA entities)

Pros: Single API surface. OAA-compatible. Cons: Chain-specific queries (timeline, diff, drift) need additional SecurityV0-native endpoints anyway. The OAA endpoints handle listing/detail; everything else is non-OAA.

// Still needed (not OAA):
GET /api/v1/execution-chains/{id}/timeline
GET /api/v1/execution-chains/{id}/compare?v1=X&v2=Y
GET /api/v1/execution-chains/{id}/drift-report

Approach B: Automation as Resource

OAA Endpoints:

GET /api/v1/oaa/applications/{app-id}
  Returns: Application payload with execution_chain Resources in the resource tree

// No way to list all chains across applications without a custom endpoint:
GET /api/v1/execution-chains  (non-OAA, searches resources by type)

Pros: Resources are within Applications (no new top-level concept). Cons: Cross-application chain listing requires a non-OAA endpoint. Chain queries against nested sub-resources are cumbersome.

Approach C: Hybrid

OAA Endpoints:

Same as Approach A, plus cross-references via custom properties.

Cons: Most complex API surface. Chain Applications must be kept in sync with source Applications. Every sync regenerates chain Application payloads.

Approach D: Separate Collection

OAA Endpoints:

GET /api/v1/oaa/applications
  Returns: Source system applications ONLY (no chains)

GET /api/v1/oaa/applications/{app-id}
  Returns: Standard OAA payload for Entra ID, ServiceNow, etc.
  Local Users have sv0_chain_memberships in custom_properties

SecurityV0-Native Endpoints:

GET /api/v1/execution-chains
  Returns: All execution chains with summary data
  Filters: ?owner_status=orphaned, ?egress=external, ?risk=critical

GET /api/v1/execution-chains/{id}
  Returns: Full chain detail with entity_refs, summary, composition_hash

GET /api/v1/execution-chains/{id}/timeline
  Returns: Chronological events affecting any entity in the chain

GET /api/v1/execution-chains/{id}/compare?v1=X&v2=Y
  Returns: Diff between two chain versions

GET /api/v1/execution-chains/{id}/blast-radius
  Returns: Resources reachable through this chain with domain/sensitivity

Pros: Clean separation. OAA endpoints are purely standards-compliant. Chain endpoints are purpose-built for SecurityV0's differentiating features. Cons: Two API families. Integration requires consuming both.

API Surface Summary

Feature	A (App)	B (Resource)	C (Hybrid)	D (Separate)
Chain listing	OAA (filtered)	Custom endpoint	OAA (filtered)	Custom endpoint
Chain detail	OAA payload	OAA sub-resources	OAA payload	Custom endpoint
Chain timeline	Custom	Custom	Custom	Custom
Chain comparison	Custom	Custom	Custom	Custom
Chain drift	Custom	Custom	Custom	Custom
OAA purity	Moderate	Low	Low	High
Total endpoints	2 OAA + 3 custom	1 OAA + 4 custom	2 OAA + 3 custom	2 OAA + 5 custom

The key insight: regardless of approach, 3-5 custom (non-OAA) endpoints are needed for SecurityV0's differentiating features (timeline, comparison, drift, blast radius). OAA provides at most a listing/detail surface for chains. The question is whether using OAA for listing/detail is worth the semantic distortion.

---

10. SCIM Export Implications

SecurityV0's SCIM endpoint (/scim/v2/Users) exports identities as SCIM Users. The question is: how does each approach affect SCIM exports?

Current SCIM Model

GET /scim/v2/Users
  Returns: Identity entities as SCIM Users with NHI extension schema
  Includes: service_principal, oauth_app, machine_account, etc.

Impact by Approach

Approach A (Application): If automation chains are Applications, their constituent identities (local_users) are already exported as SCIM Users from the source Applications (Entra ID, ServiceNow). The chain Application's local_users would be duplicates. SCIM consumers would see the same SP exported twice -- once from "Entra ID" and once from "AzureGraphRouter." This violates SCIM's expectation that each user has a unique canonical representation.

Risk: HIGH. SCIM deduplication is a known pain point for IGA tools. Adding duplicates from chain Applications compounds it.

Approach B (Resource): No SCIM impact. Resources are not Users. Chains as Resources do not appear in SCIM exports.

Risk: NONE.

Approach C (Hybrid): Same duplication problem as Approach A.

Risk: HIGH.

Approach D (Separate): No SCIM impact. Chains are separate from the entities collection (or a separate query surface). SCIM exports source system identities only.

Risk: NONE.

SCIM Summary

Approach	SCIM Duplication Risk	SCIM Compatibility
A (Application)	HIGH (users in multiple apps)	Moderate (requires dedup)
B (Resource)	NONE	Full
C (Hybrid)	HIGH	Moderate (requires dedup)
D (Separate)	NONE	Full

---

11. SIEM/SOAR Consumption Patterns

Enterprise customers will want to send SecurityV0 data to their SIEM (Splunk, Sentinel, Chronicle) and SOAR (Cortex XSOAR, Tines, Swimlane) platforms. How does each approach affect these integrations?

What SIEM/SOAR Consumers Want

1. Structured alerts with entity context (CEF, STIX, custom JSON)
2. Automation inventory as a queryable data source
3. Change events on automations for correlation with security incidents
4. Blast radius data for incident scoping

Approach A (Application): SIEM Impact

SIEM consumers receive OAA-structured Application payloads. Splunk, for example, would ingest:

{
  "application_name": "AzureGraphRouter Incident Routing",
  "application_type": "execution_chain",
  "local_users": ["sn-integration-user", "sn-ticket-router"],
  "resources": ["incident", "hr_case", "sys_user", "graph.microsoft.com"]
}

Problem: This looks like an application inventory event, not an automation chain event. Splunk correlation rules written for "application discovered" events would fire for every chain. The SIEM analyst must build custom filters to separate real applications from derived chains.

Approach D (Separate): SIEM Impact

SIEM consumers receive SecurityV0-native chain events:

{
  "event_type": "execution_chain_changed",
  "chain_id": "chain-azuregraphrouter",
  "chain_name": "AzureGraphRouter Incident Routing",
  "change_type": "blast_radius_expanded",
  "entity_changed": "sn-integration-user",
  "change_detail": "role_assigned: personalize",
  "blast_radius_before": { "tables": 2, "domains": ["it_ops"] },
  "blast_radius_after": { "tables": 3, "domains": ["it_ops", "hr"] },
  "owner_status": "orphaned",
  "risk_level": "critical"
}

This is what a SOC analyst needs. The event is self-contained, chain-level, and immediately actionable. No need to understand OAA Application structure or filter out derived entities.

SIEM/SOAR Summary

Approach	SIEM Event Quality	SOAR Playbook Fit	Custom Integration Effort
A (Application)	Low (mixed with app events)	Low (must separate chains)	High
B (Resource)	Low (buried in resource data)	Low	High
C (Hybrid)	Low (same as A + duplication)	Low	Very High
D (Separate)	High (dedicated chain events)	High (chain-level actions)	Low

---

12. Scoring Matrix

Scoring Criteria Definitions

Criterion	1 (worst)	5 (neutral)	10 (best)
CISO intuitiveness	CISO confused by model; needs training	CISO understands with explanation	CISO immediately grasps the model
OAA compliance	Violates OAA semantics; rejected by Veza	Partially compliant with extensions	Fully compliant; works with any OAA consumer
Implementation effort	200+ hours; major refactoring	100 hours; moderate new code	50 hours; uses existing infrastructure
Future extensibility	Locks us into one approach; hard to change	Some flexibility	Maximum flexibility; supports future OAA evolution
Standards portability	SecurityV0-specific; no standards alignment	Partial SCIM/OAA alignment	Full SCIM + OAA + future standards ready

Scores

Criterion	A (Application)	B (Resource)	C (Hybrid)	D (Separate)
CISO intuitiveness	7	4	5	9
OAA compliance	5	6	4	8
Implementation effort	5	6	3	8
Future extensibility	6	5	4	9
Standards portability	6	5	4	8
WEIGHTED TOTAL	5.8	5.2	4.0	8.4

Weights: CISO intuitiveness 30%, OAA compliance 20%, Implementation effort 15%, Future extensibility 20%, Standards portability 15%.

Detailed Score Justifications

CISO Intuitiveness

A (Application): 7. The CISO understands "automation = application." This mental model works for the inventory use case. Deductions: application count confusion (17 vs. 2), entity duplication confusion ("why does this SP appear in two apps?"), and the inability to express temporal/ownership concepts within the OAA Application model.

B (Resource): 4. The CISO must navigate a resource hierarchy within an Application to find chains. Chains are at the same level as tables in the resource tree. The CISO asks "where are my automations?" and the answer is "they are Resources within your ServiceNow Application, alongside the tables they touch." This is unintuitive. Automations are not resources in the way tables are resources.

C (Hybrid): 5. The CISO sees three categories of Applications. Must learn the distinction between source system Applications and derived chain Applications. The cognitive overhead of understanding why identities appear in multiple contexts reduces intuitiveness.

D (Separate): 9. The CISO sees two distinct surfaces: "Applications" (source systems) and "Automations" (execution chains). Each has a clear purpose. No cross-contamination. The Automations page is purpose-built for the CISO's questions (inventory, risk, ownership, drift). One point deducted because two surfaces means two learning curves, but the separation itself is a virtue.

OAA Compliance

A (Application): 5. The payload structure is valid OAA JSON. A Veza consumer can ingest it. But the semantics are stretched: execution chains are not Applications in the way GitHub or Jira are Applications. Custom properties carry the real meaning, which defeats the purpose of a standard format.

B (Resource): 6. Resources with sub-resources are fully OAA-compliant. The resource type execution_chain is a custom type, but OAA supports custom resource types. The weakness is that permission semantics (identity "has DataWrite on" a chain) are misleading. Slightly higher than A because it does not pollute the Application namespace.

C (Hybrid): 4. Maximum OAA surface area, maximum semantic stretch. Chain Applications with cross-references via custom properties are technically valid OAA but practically require so much SecurityV0-specific interpretation that they are a custom format dressed in OAA syntax.

D (Separate): 8. OAA exports are pure and correct. Source system Applications are modeled exactly as OAA intends. Chain data is explicitly outside OAA, which is honest: OAA does not model execution chains, and pretending it does hurts consumers. Two points deducted because chains have NO OAA representation, which means OAA-only consumers miss chain data entirely.

Implementation Effort (10 = least effort)

A (Application): 5. Requires building an OAA Application generator for each chain. Must handle entity deduplication (same identity in source app and chain app). Must build Application-level refresh on every sync. Estimated additional effort over Round 3 plan: +30-40 hours.

B (Resource): 6. Simpler than A because chains are Resources within existing Applications. Must build sub-resource generation for chain components. Must handle trigger/outcome resource semantics. Estimated additional: +20-30 hours.

C (Hybrid): 3. Maximum effort. Build everything from A plus cross-references, synchronization logic, and duplication management. Estimated additional: +50-60 hours.

D (Separate): 8. Chains are built as described in Round 3 (execution_chains collection). OAA exports remain unchanged from current spec (06-scim-oaa-integration.md). Only addition: sv0_chain_memberships custom property on Local Users in OAA exports. Estimated additional: +5-10 hours over Round 3 plan.

Future Extensibility

A (Application): 6. If OAA adds execution/process concepts, chain Applications can adopt them. But the Application-per-chain model creates a scaling problem as chain count grows. Refactoring from Application to a future OAA execution model would require rebuilding the entire chain export layer.

B (Resource): 5. Resources are relatively static in OAA's evolution. If OAA adds a new entity type for processes, resources would need to be migrated. The sub-resource hierarchy is also rigid -- adding new chain component types requires extending the sub-resource schema.

C (Hybrid): 4. The most complex model is the hardest to evolve. Any OAA evolution requires updating three places: source Applications, chain Applications, and cross-references.

D (Separate): 9. Maximum flexibility. SecurityV0's native chain model can evolve independently of OAA. If OAA adds execution/process concepts in a future version, SecurityV0 can build an adapter from execution_chains to the new OAA concepts without touching the existing OAA export. If OAA never adds these concepts, SecurityV0 has a clean native model that serves the CISO without compromise.

Standards Portability

A (Application): 6. OAA-compatible, but the execution_chain Application type is SecurityV0-specific. SCIM exports have duplication risk. A generic OAA consumer can ingest but may be confused by the Application taxonomy.

B (Resource): 5. OAA-compatible for resources. SCIM unaffected. But the execution semantics encoded in resource hierarchies are not portable to other standards (STIX, CAEP, IETF drafts for NHI).

C (Hybrid): 4. Maximum OAA surface, minimum portability. The custom properties and cross-references are SecurityV0-specific. No other standard uses this pattern.

D (Separate): 8. SCIM exports are fully RFC-compliant. OAA exports are fully OAA-compliant. Chain data uses a SecurityV0-native format that can be adapted to any future standard (STIX for threat modeling, CAEP for continuous access evaluation, IETF NHI drafts). The separation is the portability: each standards surface is clean.

---

13. Where OAA Alignment Creates Value

OAA alignment is genuinely valuable in specific areas. Being precise about where it helps:

1. Authorization Snapshot Export

OAA is excellent for answering: "What can identity X do in system Y?" This is the core authorization query. SecurityV0 should absolutely export source system authorization data in OAA format. Every identity, its roles, permissions, and reachable resources should be available as OAA Application payloads.

Value: Enterprise customers using Veza can ingest SecurityV0's authorization data alongside their other OAA sources. The CISO sees a unified view of NHI permissions across all systems.

2. Permission Normalization

OAA's 10 canonical permissions (DataRead, DataWrite, DataCreate, DataDelete, MetadataRead, MetadataWrite, NonData, OwnershipAssignment, ResourceAdmin, AccountAdmin) provide a standard vocabulary for comparing permissions across systems.

Value: A CISO can ask "which identities have DataWrite across all systems?" and get a consistent answer. SecurityV0's existing permission normalization (7 actions) maps cleanly to OAA's 10 types.

3. Identity Correlation

OAA's identities array on Local Users enables cross-system identity correlation. SecurityV0's AUTHENTICATES_TO relationship maps to this: "SP X in Entra ID correlates to Integration User Y in ServiceNow."

Value: Veza can show cross-system identity graphs using SecurityV0's OAA exports without SecurityV0-specific logic.

4. Standard Integration Interface

OAA's JSON schema is a defined contract. SIEMs, SOARs, and IGA tools that support OAA can ingest SecurityV0's authorization data without custom parsers.

Value: Reduced integration effort for customers already in the Veza/OAA ecosystem.

---

14. Where OAA Alignment Destroys Value

Being equally precise about where OAA alignment hurts:

1. Execution Flow Semantics

OAA models WHO can do WHAT to WHICH resource. It does not model HOW an execution chain flows from trigger through code through auth to outcome. Forcing execution flow into OAA's permission model creates false equivalences:

• "Business rule triggers on incident insert" becomes "BR has DataRead on incident" -- which is misleading. The BR does not "read" the incident table. It fires because of a table event.
• "Script include calls REST message" becomes... nothing in OAA. There is no concept of one component calling another.
• "REST message authenticates via OAuth to graph.microsoft.com" becomes "OAuth user has NonData on graph.microsoft.com" -- which strips all meaningful context.

Destruction: The CISO who reads OAA permissions for an execution chain gets a CRUD-ified view that obscures the actual execution flow. They see "DataRead on incident, DataWrite on hr_case, NonData on graph.microsoft.com" but not "incident insert triggers a chain that routes through AzureGraphRouter to Microsoft Graph."

2. Temporal Tracking

OAA is snapshot-based. Every push is a complete replacement. There is no concept of "what changed since last push" or "what did the permission graph look like 6 months ago." SecurityV0's temporal model (entity_versions, events, baselines) is a core differentiator that cannot be expressed in OAA.

Destruction: If SecurityV0 models chains as OAA Applications, the OAA export cannot answer "how has this automation changed over time?" The CISO must use SecurityV0-native APIs for temporal queries regardless. The OAA Application gives a false sense of completeness -- it looks like you have the full picture, but you are missing the temporal dimension.

3. Ownership Hierarchy

OAA has local_users with identities for IdP correlation. It does not model ownership levels (primary, secondary, inherited), ownership decay (departed, disabled, disbanded), or ownership hierarchy (human -> team -> business_unit -> organization).

Destruction: If an automation's ownership status is embedded in OAA custom properties (sv0_owner_status: "orphaned"), the CISO gets a label without the walkable evidence chain. They see "orphaned" but cannot ask "when did ownership degrade? Who was the last owner? Is there an inherited team owner?" without leaving OAA.

4. Evidence Completeness

OAA does not model evidence availability or completeness. SecurityV0's evidence completeness framework (available, unavailable_not_enabled, unavailable_no_access, partial) is a core differentiator that ensures findings are honest about what data was and was not available.

Destruction: An OAA Application for a chain cannot express "role history unavailable because sys_audit_role is not enabled." The CISO sees permissions but has no way to assess the confidence level of the data.

5. Application Count Inflation

This is a practical UX problem. If every chain is an Application, a customer with 2 source systems and 50 chains sees 52 Applications in Veza. A Veza dashboard showing "52 Applications" overstates the integration surface. Enterprise customers who care about "how many SaaS applications do we have?" get a misleading answer.

Destruction: Trust erosion. The CISO asks "why does Veza show 52 applications when we only integrated Entra ID and ServiceNow?" The answer requires explaining SecurityV0's chain-as-application mapping, which is an implementation detail the CISO should not need to understand.

---

15. Recommendation

Primary Recommendation: Approach D (Separate Collection) with OAA Enhancement

I recommend Approach D from Round 3 with one enhancement: add chain summary data to OAA exports as a SecurityV0 extension, without modeling chains as Applications or Resources.

The Enhancement: OAA Custom Extension for Chain Awareness

Instead of forcing chains into OAA entity types, add a sv0_execution_chains extension section to the OAA Application payload:

{
  "application_type": "servicenow",
  "name": "ServiceNow - corp.service-now.com",

  "local_users": [
    {
      "name": "sn-integration-user",
      "custom_properties": {
        "sv0_chain_memberships": [
          {
            "chain_id": "chain-azuregraphrouter",
            "chain_name": "AzureGraphRouter Incident Routing",
            "role_in_chain": "executor",
            "chain_risk": "critical",
            "chain_owner_status": "orphaned"
          }
        ]
      }
    }
  ],

  "resources": [ /* ... standard resources ... */ ],

  "custom_properties": {
    "sv0_tenant_id": "tenant-xyz",
    "sv0_execution_chain_summary": {
      "total_chains": 15,
      "chains_with_external_egress": 3,
      "orphaned_chains": 2,
      "chain_index_url": "/api/v1/execution-chains?source_system=servicenow"
    }
  }
}

This approach:

1. Preserves OAA purity. The Application payload is a standard OAA payload with custom properties. Any OAA consumer can ingest it and ignore the custom properties.
2. Provides chain awareness. A SecurityV0-aware consumer can read sv0_chain_memberships to understand which identities participate in which chains and navigate to the chain API for detail.
3. No entity duplication. Each identity appears once, in its source Application.
4. No Application inflation. Application count reflects real systems.
5. Clear discovery path. The sv0_execution_chain_summary tells consumers: "There are 15 execution chains associated with this Application. Query /api/v1/execution-chains for detail."

Why Not Approach A?

Approach A (automation-as-application) scored 7 on CISO intuitiveness but only 5 on OAA compliance. The core problem is that an OAA Application represents a system boundary, not a derived execution chain. Modeling chains as Applications creates:

1. Application count confusion (17 vs. 2)
2. Entity duplication (same SP in multiple apps)
3. SCIM export contamination (duplicate users)
4. SIEM event pollution (chain events mixed with app events)
5. Semantic distortion (execution flow → CRUD permissions)

The intuitiveness gain (automation = application is a natural metaphor) is real but narrow. It applies only to the listing use case. For timeline, comparison, drift, and ownership -- the use cases that define SecurityV0's value -- the OAA Application model adds nothing and constrains everything.

Why Not Approach B?

Approach B (automation-as-resource) avoids the worst problems of A (no duplication, no app inflation) but introduces its own: cross-system chains do not fit in a single Application's resource tree, permission semantics are backwards (identity "has DataWrite on" a chain rather than "executes as" the chain), and listing chains requires aggregating across Applications.

The founder's insight that "trigger can be data/resource and outcome can be data/resource" maps well to OAA Resources semantically but not structurally. Yes, the incident table is a Resource whether it is being read (trigger) or written (outcome). But the chain itself -- the flow from trigger through code through auth to outcome -- is not a Resource. It is a Process, and OAA does not model processes.

Why Not Approach C?

Approach C (hybrid) combines the worst of A and B: Application inflation, entity duplication, SCIM contamination, maximum implementation effort, and maximum maintenance burden. Its only advantage is the richest OAA representation of the chain, but that richness comes at the cost of semantic honesty. The OAA payload looks comprehensive but requires deep SecurityV0 knowledge to interpret correctly.

The Founder's Question Answered

The founder asked whether automations map better to OAA Applications or OAA Resources. The answer is: neither, because OAA does not model execution chains.

OAA models authorization: who can do what to which resource. Execution chains model process flow: what triggers what, through what code, via what authentication, producing what outcome. These are different questions with different structures.

The right approach is:

1. Use OAA for what it does well: Export source system authorization data (identities, roles, permissions, resources) in OAA format. This is already specified in 06-scim-oaa-integration.md.
2. Use SecurityV0-native APIs for what OAA cannot do: Export execution chains via /api/v1/execution-chains with temporal, ownership, and evidence data that OAA cannot express.
3. Bridge the two surfaces via lightweight cross-references: sv0_chain_memberships on OAA Local Users and sv0_execution_chain_summary on OAA Application custom properties.

This is not a rejection of OAA. It is a recognition that OAA and execution chains answer different questions. Conflating them produces a model that answers neither question well.

Implementation Impact on Round 3 Plan

This recommendation requires minimal changes to the Round 3 implementation plan:

Round 3 Action Item	Change Required
#1: Define chain types	No change
#2: Implement chain builder	No change
#3: Add execution_chains collection	No change
#4: Integrate into sync pipeline	No change
#5: API routes for chains	No change
#6: UI pages for chains	No change
#7: Connector chain hints	No change
#8: Tests	No change
#9: Migration script	No change
New: OAA enhancement	Add sv0_chain_memberships to OAA export

The OAA enhancement is estimated at 8-12 hours:

• 4h: Add sv0_chain_memberships property generation to OAA export code
• 4h: Add sv0_execution_chain_summary to Application custom properties
• 2-4h: Tests and documentation

Phased Delivery

Phase	What Ships	OAA Impact
Phase 1 (Round 3)	execution_chains collection, chain builder, API, UI	OAA exports unchanged
Phase 1.5 (this round)	sv0_chain_memberships on OAA Local Users, sv0_execution_chain_summary on OAA Applications	OAA exports enhanced with chain hints
Phase 2	Temporal chain tracking, chain versions	OAA exports may include chain version count in sv0_execution_chain_summary
Future	If OAA adds execution/process concepts, build adapter from execution_chains to new OAA types	OAA exports adopt new standard concepts

Decision Statement

The Product Owner recommends: Model execution chains as a separate SecurityV0-native concept (execution_chains collection), NOT as OAA Applications or Resources. Enhance OAA exports with lightweight cross-references (sv0_chain_memberships, sv0_execution_chain_summary) that bridge the OAA authorization model with SecurityV0's execution chain model. Reserve OAA for what it does well (authorization snapshots) and use SecurityV0-native APIs for what OAA cannot do (execution flow, temporal tracking, ownership hierarchy, evidence completeness).

This position reverses my Round 3 stance (where I advocated Option D: virtual entity within the entities collection). The OAA analysis has convinced me that execution chains are fundamentally different from authorization entities. They should not share a collection with identities, roles, permissions, and resources -- and they should not be forced into OAA's Application or Resource categories. The Round 3 majority (Architect, CISO, Developer) was correct: a separate collection is the right answer.

---

Appendix A: OAA Canonical Permission Mapping for Chain Components

If a future revision decides to partially model chains in OAA (Approach A or B), here is how chain component operations map to OAA canonical permissions:

Chain Operation	OAA Permission	Fidelity	Notes
Trigger: table insert event	DataCreate	Low	Event trigger is not "creating data" but OAA has no trigger concept
Trigger: scheduled execution	NonData	Medium	Scheduled execution is a non-data operation
Code: script include execution	NonData	Low	Script execution is not modeled in OAA
Code: flow designer execution	NonData	Low	Same
Auth: OAuth client_credentials	NonData	Low	Authentication is not modeled in OAA's permission set
Auth: AUTHENTICATES_TO	NonData	Low	Cross-system auth delegation has no OAA equivalent
Outcome: table read	DataRead	High	Direct mapping
Outcome: table write	DataWrite	High	Direct mapping
Outcome: table create	DataCreate	High	Direct mapping
Outcome: table delete	DataDelete	High	Direct mapping
Outcome: API call (external)	NonData	Medium	External API calls are non-data from OAA's perspective
Outcome: metadata change	MetadataWrite	High	Configuration changes map well
Ownership assignment	OwnershipAssignment	N/A	Ownership is not a chain operation
Admin access	ResourceAdmin	High	Direct mapping for admin-level access

Key takeaway: Only the "Outcome" operations map cleanly to OAA permissions. Trigger, code, and auth operations all collapse to NonData, which strips all meaningful context. This is why OAA cannot express execution chains -- 60% of the chain's operations lose their semantics in translation.

---

Appendix B: Veza Platform Integration Scenarios

Scenario 1: Customer Using Veza + SecurityV0

Veza Platform
  ├── Native connectors (Snowflake, AWS, GitHub, ...)
  ├── OAA connectors (custom apps)
  └── SecurityV0 OAA connector
        ├── Application: "Entra ID - contoso-prod" (OAA standard)
        ├── Application: "ServiceNow - corp" (OAA standard)
        └── (chain data NOT in Veza -- in SecurityV0 native API)

SecurityV0 Platform
  ├── OAA export: /api/v1/oaa/applications (Veza consumes this)
  └── Chain API: /api/v1/execution-chains (SecurityV0 UI consumes this)

User experience: The CISO uses Veza for cross-platform authorization queries ("who has admin across all systems?") and SecurityV0 for execution chain analysis ("which automations are orphaned?"). Both platforms share the same identity data via OAA.

Scenario 2: Customer Using SecurityV0 Only (No Veza)

SecurityV0 Platform
  ├── OAA export: /api/v1/oaa/applications (available for future integration)
  ├── SCIM export: /scim/v2/Users (available for IGA tools)
  ├── Chain API: /api/v1/execution-chains (primary UI)
  └── Native API: /api/v1/entities, /api/v1/findings, etc. (full platform)

User experience: The CISO uses SecurityV0 exclusively. OAA and SCIM endpoints are available for future integrations but not required.

Scenario 3: SIEM Integration

SecurityV0 Platform
  ├── Chain events → SIEM (Splunk, Sentinel)
  │     Event type: execution_chain_changed
  │     Contains: chain_id, change_type, blast_radius_diff, owner_status
  │
  ├── Finding events → SIEM
  │     Event type: finding_created/updated
  │     Contains: finding_type, entity_id, chain_memberships
  │
  └── OAA snapshots → SIEM (optional)
        Periodic: authorization metadata for compliance dashboards

User experience: SOC analysts see chain-level events in their SIEM. Correlation rules match chain changes with security incidents. The chain context (owner status, blast radius, risk) is embedded in the event, not requiring a separate lookup.

---

Appendix C: Competitive Analysis -- How Other Platforms Handle This

Veza (OAA Creator)

Veza models everything as Applications with Local Users, Permissions, and Resources. Execution flow is not modeled. Veza's value is cross-system authorization visibility, not execution chain tracking. SecurityV0's execution chain concept is a differentiator that Veza does not offer.

Silverfort

Silverfort models "machine identities" with authentication activity but does not group them into execution chains. Individual identity risk scoring, not chain-level analysis.

Astrix Security

Astrix models NHI connections (app-to-app integrations) with a focus on third-party SaaS. Their model is closer to "integration" than "execution chain." They do not track temporal drift or ownership hierarchy.

ConductorOne

ConductorOne focuses on access reviews and provisioning. Their model is SCIM/IGA-oriented. No execution chain concept.

Implication for SecurityV0

None of these competitors model execution chains as first-class, temporal, ownable entities. This is SecurityV0's unique differentiator. Forcing chains into OAA's model (which competitors also use) would eliminate the differentiation. The separate collection approach preserves it.

---

Appendix D: Decision Matrix -- Quick Reference

Question	Answer
Should automations be OAA Applications?	No. Application count inflation, entity duplication, SCIM contamination.
Should automations be OAA Resources?	No. Cross-system chains break the single-Application model. Permission semantics are backwards.
Should we use a hybrid approach?	No. Maximum complexity, maximum maintenance, minimum clarity.
Should we model chains in OAA at all?	Only as cross-references (custom properties on Local Users and Applications).
Where should chain data live?	SecurityV0-native execution_chains collection with dedicated API endpoints.
Does this hurt Veza integration?	No. Veza gets clean OAA authorization data. Chain data is available via SecurityV0's native API.
Does this hurt SCIM export?	No. SCIM exports remain pure RFC-compliant.
Does this hurt SIEM integration?	No. SIEM gets purpose-built chain events, which are better than OAA Application snapshots.
What is the additional effort?	+8-12 hours for OAA enhancement (sv0_chain_memberships) on top of Round 3 plan.
What changes in Round 3's recommendation?	Nothing. Approach D confirms the separate collection. OAA enhancement is additive.

---

Analysis complete. 4 approaches evaluated across 5 scoring criteria with detailed user story mapping, UI mockups, API surface comparison, SCIM/SIEM impact analysis, and competitive context. Recommendation: Approach D (separate collection) with OAA enhancement (chain awareness via custom properties). Total score: 8.4/10 vs. next best 5.8/10. Additional effort over Round 3 plan: +8-12 hours.