OAA Mapping Analysis — Team Synthesis Report
Date: 2026-02-13 (Round 4) Team: automation-analysis (6 agents — first round with OAA Specialist) Core Question: How should autonomous execution flows map to OAA concepts? Should automations be Applications, Resources, or something else? Can we extend OAA rather than deviate?
Team Participants
| Role | Model | Lines | Key Contribution |
|---|---|---|---|
| OAA Specialist | opus | 1,762 | OAA entity mapping, 3 approaches evaluated, hybrid model design, founder's insight response |
| Product Owner | opus | 1,316 | User story impact, scoring matrix (4 approaches × 5 criteria), UI mockups, SCIM/SIEM analysis |
| Architect | opus | 2,154 | Schema designs (3 approaches), NormalizedNodeType evolution, Neo4j Cypher, trigger/data problem |
| CISO | opus | 1,279 | Compliance mapping (5 controls), forensic Day 0-91 walkthrough, Execute permission gap, dual-layer design |
| Integrator | sonnet | 1,252 | Connector architecture, OAA SDK analysis, platform OAA adapter design, cross-system limitations |
| Developer | sonnet | 1,552 | Implementation comparison (3 approaches), TypeScript types, effort estimates, file impact analysis |
Total: 9,315 lines across 6 perspectives.
1. Unanimous Agreement: OAA Is an Export Format, Not the Internal Data Model
All 6 roles agree: OAA should NOT drive the internal data model. SecurityV0's richer model projects INTO OAA format for interoperability.
| Role | Position |
|---|---|
| OAA Specialist | "OAA models static authorization (who can do what to what). It cannot express execution flow order, credential chains, trigger/event causality, temporal state, or findings." |
| Product Owner | "OAA models authorization: who can do what to which resource. Execution chains model process flow. These are different questions with different structures." |
| Architect | "OAA is a permission snapshot format. SecurityV0 is a temporal execution authority platform. Full alignment would mean losing execution direction, temporal tracking, execution evidence, and chain identity." |
| CISO | "OAA has no temporal capability, no change tracking, no execution evidence, and no ownership modeling. It is a catalog, not a forensic tool." |
| Integrator | "NormalizedGraph is a superset of OAA (supports features OAA doesn't have). Transforming NormalizedGraph → OAA is lossy but one-way." |
| Developer | "SecurityV0 is NOT an OAA system — it's an execution exposure platform that CAN export to OAA format." |
What OAA cannot express:
| SecurityV0 Capability | OAA Status |
|---|---|
| Execution flow direction (trigger → process → output) | Not supported |
| Temporal chain versioning | Not supported (snapshot only) |
| Execution evidence (proof-of-execution) | Not supported |
| Credential chain tracking | Not supported (no credential entity) |
| Chain-level findings/evaluation | Not supported (descriptive only) |
| Cross-system AUTHENTICATES_TO | Partial (IdP email correlation only) |
| RUNS_AS, TRIGGERS_ON, EXECUTES_ON edges | Not supported |
| Chain composition fingerprint / change detection | Not supported |
2. Unanimous Agreement: execution_chains Collection (Round 3) Remains Essential
All 6 roles confirm: The Round 3 recommendation (new execution_chains collection) stands. OAA analysis reinforces rather than replaces it.
| Role | Position |
|---|---|
| OAA Specialist | "The execution_chains collection is the internal authority. The OAA chain registry is the external projection." |
| Product Owner | "This confirms the Round 3 majority recommendation. I now reverse my Round 3 dissent (virtual entity) based on the OAA analysis showing execution chains are fundamentally different from authorization entities." |
| Architect | "The internal model (entities + execution_chains) continues as designed. OAA export is an output concern, not a data model concern." |
| CISO | "Implement execution_chains as the persistence and forensic layer. Add OAA canonical permission vocabulary as the compliance and attestation layer. These are complementary, not competing." |
| Integrator | "Connectors continue to emit NormalizedGraph only. Platform provides OAA export API." |
| Developer | "Keep Round 3's execution_chains collection. Add thin OAA export layer. 94h + 44h = 138h total." |
Notable: The Product Owner reverses their Round 3 dissent. In Round 3, the PO advocated for Option D (virtual entity in entities collection). After the OAA analysis, the PO now supports the separate execution_chains collection because "execution chains are fundamentally different from authorization entities." This makes the Round 4 consensus fully unanimous (6/6).
3. Three OAA Mapping Approaches Evaluated
Approach A: Automation as OAA Application
Each execution chain becomes its own OAA Application with local users (service principals), resources (tables/APIs), and permissions.
| Criterion | Assessment |
|---|---|
| Semantic appeal | High — chains have their own "users," "resources," "permissions" |
| OAA compliance | LOW — application proliferation (50 chains = 50 apps), entity duplication, no OAA connector follows this pattern |
| Implementation | 76h (Developer estimate) |
| Problem | Same SP appears in multiple Applications. SCIM exports duplicate identities. Application count confusion (17 apps vs 2 real systems). |
Verdict (all 6 roles): Rejected.
- OAA Specialist: "Semantically appealing but operationally broken"
- CISO: "Do NOT model automations as OAA Resources [or standalone Applications]"
- Architect: "Architecturally incorrect"
Approach B: Automation as OAA Resource
Automations are Resources within the source system's Application (e.g., ServiceNow). Business Rules, Script Includes become nested sub-resources.
| Criterion | Assessment |
|---|---|
| OAA compliance | HIGH — follows community patterns (GitHub repos, Jira projects as resources) |
| Cross-system | BROKEN — chains span ServiceNow + Entra but Resources live in one Application |
| Implementation | 106h (Developer estimate) |
| Problem | Cannot express cross-system chains. Listing chains requires aggregating across Applications. Permission semantics inverted (identity "has DataWrite on" a chain rather than "executes as" the chain). |
Verdict (all 6 roles): Rejected as primary model. Useful as OAA export representation for source-system artifacts.
Approach C: Hybrid (execution_chains + OAA Export Projection)
Keep Round 3's execution_chains collection internally. Add an OAA export layer that projects:
- Source systems as OAA Applications (ServiceNow App, Entra App)
- Automation artifacts as Resources within source Applications
- Optionally: a "Chain Registry" Application that provides chain-as-resource views
| Criterion | Assessment |
|---|---|
| Internal model | Unchanged — execution_chains collection, full temporal/forensic capability |
| OAA compliance | Standard source-app exports + optional chain registry extension |
| Cross-system | Preserved internally via NormalizedGraph edges; lossy in OAA export (documented) |
| Implementation | 138h (94h chains + 44h OAA projection) |
| Advantage | Clean separation, zero breaking changes, rollback safe, future-proof |
Verdict (all 6 roles): Recommended.
4. Scoring Matrix (Product Owner Assessment)
| Criterion | A: App | B: Resource | C: Hybrid | D: Round 3 Only |
|---|---|---|---|---|
| CISO intuitiveness | 7/10 | 4/10 | 8/10 | 9/10 |
| OAA compliance | 5/10 | 7/10 | 7/10 | 8/10 |
| Implementation effort | 7/10 | 5/10 | 6/10 | 8/10 |
| Future extensibility | 5/10 | 5/10 | 9/10 | 9/10 |
| Standards portability | 5/10 | 5/10 | 8/10 | 8/10 |
| Weighted total | 5.8 | 5.2 | 7.6 | 8.4 |
The PO notes that "Round 3 Only" (without any OAA layer) scores highest, but recommends the Hybrid (C) approach for future interoperability.
5. Responding to the Founder's Insights
"OAA has application notion, not only identity. Script include, business flow looks more like an application, but not identity."
Team response (unanimous): The founder is directionally correct but the mapping needs refinement:
- Script includes and business rules are not identities — correct
- But they are also not applications (in OAA's sense of "a software system with its own user base")
- They are resources within the ServiceNow application — analogous to how GitHub repos are resources within a GitHub org
- The execution chain AS A WHOLE has application-like qualities (container with users, permissions, resources) but the most OAA-compatible way to model it is as a resource within a chain registry, not as a standalone application per chain
Architect's key insight: "Automation artifacts are simultaneously identities AND resources. They execute (identity), and they are configured (resource). OAA cannot represent this duality because OAA's world is strictly divided: Applications contain Resources, and Users have Permissions on Resources. SecurityV0's edge types (RUNS_AS, TRIGGERS_ON, EXECUTES_ON) capture what OAA cannot."
"Autonomous execution could be treated either as application, or a collection of applications, identities, roles, data modifications."
Team response: Correct — an execution chain IS a collection of resources, identities, and permissions. The hybrid model captures this: the internal execution_chains collection stores the composition (entity_refs with roles), and the OAA export projects it as an Application-like container with local users and resources. The "collection" semantics are preserved without promoting each chain to a full OAA Application.
"When there is an incident trigger - can it be 'data' or 'resource'? When updating some data later like incident table - it looks like a change to 'data' or 'resource' as well."
Team response (Architect + OAA Specialist): The incident table IS a resource in all three roles:
- Trigger source: The table emits an event (incident INSERT fires the BR)
- Data input: The automation reads from it (DataRead in OAA)
- Data output: The automation writes to it (DataWrite in OAA)
The difference is not WHAT the table is, but WHAT RELATIONSHIP it has to the automation:
TRIGGERS_ON— table as event source (not expressible in OAA)EXECUTES_ON— table as data access target (maps to DataRead/DataWrite)APPLIES_TO— table as permitted scope (maps to permission binding)
OAA collapses all three into DataRead/DataWrite permissions. SecurityV0 distinguishes them via typed edges. The trigger event (incident INSERT fires the BR) is NOT expressible in OAA. OAA models authorization ("who can do what"), not execution causality ("what event causes what action"). The trigger dimension must be modeled as a custom property (trigger_table, trigger_condition).
6. The "Execute" Permission Gap
CISO identified a critical gap: OAA's 10 canonical permissions don't include "Execute" or "Trigger."
| OAA Permission | Automation Semantics | Problem |
|---|---|---|
| DataRead | Automation reads trigger data | OK for input |
| DataWrite | Automation writes outcome data | OK for output |
| NonData | "Everything else" | Conflates trigger, code execution, API calls, auth, delegation |
Team recommendation: Do NOT modify OAA's canonical types (breaks interoperability). Instead, add an sv0_action_type extension under NonData via custom properties:
{
"permission_type": ["NonData"],
"custom_properties": {
"sv0_action_type": "execute_automation",
"sv0_action_detail": "business_rule_trigger"
}
}
Any OAA consumer that doesn't understand sv0_action_type sees standard "NonData." SecurityV0-aware consumers get execution semantics. CISO estimates this resolves the compliance communication gap at ~4 hours implementation cost.
7. Compliance Impact (CISO Assessment)
OAA Alignment Value for Compliance
| Control | execution_chains Only | execution_chains + OAA Vocabulary |
|---|---|---|
| CC6.1 (Access Controls) | PARTIAL — chain state, internal terms | IMPROVED — canonical DataRead/DataWrite language |
| CC7.1 (Monitoring) | IMPROVED — chain-level findings | IMPROVED — "Application gained DataWrite on confidential resource" |
| CC8.1 (Change Management) | PARTIAL — composition hash | IMPROVED — canonical permission diff in events |
| A.5.9 (Asset Inventory) | MET — chains identifiable | STRONGLY MET — chains exportable as OAA Applications (industry-standard asset type) |
| SOX ITGC | PARTIAL — current inventory | PARTIAL → IMPROVED — canonical vocabulary for auditor communication |
CISO verdict: "The OAA enrichment is incremental — it adds canonical type fields to documents that already exist. The compliance benefit is immediate: the first audit conversation will ask about permissions in terms the auditor understands (DataWrite on HR data, not hr_agent_workspace role)."
Incremental cost: ~27 hours on top of Round 3 estimates (4h canonical types in chain builder + 16h OAA export endpoint + 7h tests/docs).
8. Implementation Architecture (Team Consensus)
Recommended: execution_chains Collection + OAA Export Projection
┌─────────────────────────────────────────────────────┐
│ INTERNAL MODEL │
│ ┌──────────┐ ┌─────────────────┐ ┌────────────┐ │
│ │ entities │ │ execution_chains │ │ findings │ │
│ │ │ │ (Round 3) │ │ │ │
│ └──────────┘ └─────────────────┘ └────────────┘ │
│ │ │ │ │
│ └───────────────┼────────────────────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ Export Layer │ │
│ └────────┬────────┘ │
└───────────────────────┼─────────────────────────────┘
│
┌───────────────┼───────────────┐
│ │ │
┌────▼────┐ ┌─────▼─────┐ ┌────▼────┐
│ OAA │ │ SCIM │ │ Neo4j │
│ Export │ │ Export │ │ Export │
│ (Veza) │ │ │ │ (future) │
└─────────┘ └───────────┘ └─────────┘
Phased Implementation
| Phase | What | Effort | Dependency |
|---|---|---|---|
| Phase 1 | execution_chains collection + chain builder + API + UI (Round 3) | 94h | None |
| Phase 1.5 | OAA canonical permission enrichment on chain documents | 4h | Phase 1 |
| Phase 2 | Chain temporal versioning (Round 3 Phase 2) | 24-48h | Phase 1 |
| Phase 3 | OAA export endpoint (GET /api/v1/export/oaa/:sourceSystem) | 24h | Phase 1 |
| Phase 4 | Chain registry OAA export (chains as resources in meta-Application) | 8h | Phase 3 |
| Phase 5 | Veza integration (push to Veza platform) | 8h | Phase 3 |
What This Means for Connectors
No connector changes required. Connectors continue to emit NormalizedGraph only. The OAA export is a platform-side concern.
| Concern | Resolution |
|---|---|
| Connector output format | NormalizedGraph only (unchanged) |
| OAA Application creation | Platform export layer (not connector) |
| Cross-system chain assembly | Platform sync pipeline (not connector) |
| OAA SDK dependency | Platform only (if integrated with Veza) |
9. OAA Compatibility: What Works and What's Lost
What OAA Export Provides
- Per-system authorization view (ServiceNow users → roles → resources, Entra SPs → roles → permissions)
- IdP identity correlation (if email addresses match, Veza links identities)
- Resource classification (business domain, sensitivity level)
- Custom properties (identity_subtype, execution_mode, security_relevance)
- Industry-standard asset types for compliance (OAA Application = auditor-recognized concept)
What OAA Export Cannot Provide (Documented Limitations)
| SecurityV0 Feature | OAA Representation | Information Loss |
|---|---|---|
| Cross-system execution chains | Split into separate Applications per source system | No single-query path from BR → SP → Entra roles |
| AUTHENTICATES_TO edges | IdP email correlation only | Cross-system auth requires manual correlation |
| Credential lifecycle | Custom properties on local_users | No credential entity or rotation tracking |
| Execution evidence | Not included | No proof of actual execution vs. authority |
| RUNS_AS, TRIGGERS_ON edges | Not represented | Automation identity binding lost |
| Temporal diff | OAA is snapshot-only | No change detection (full replace each sync) |
| Chain-level findings | Not represented | No evaluation or risk assessment |
Key insight (Integrator): "Deterministic cross-system execution paths are SecurityV0's core differentiator. OAA export loses this. Customers who need the full picture use SecurityV0's native API; OAA export serves the Veza integration use case."
10. Edge Type → OAA Mapping Reference (Architect)
| SecurityV0 Edge | OAA Equivalent | Mapping Fidelity |
|---|---|---|
OWNED_BY | Custom property on local_user | Lossy (no ownership model) |
HAS_ROLE | local_user.add_role() | Direct |
GRANTS | role permissions list | Direct |
APPLIES_TO | permission → resource binding | Direct |
AUTHENTICATES_TO | IdP identity link | Partial (users only) |
RUNS_AS | No equivalent | Lost in OAA |
TRIGGERS_ON | No equivalent | Lost in OAA |
EXECUTES_ON | No equivalent | Lost in OAA |
CREATED_BY | No equivalent | Lost in OAA |
CALLS | No equivalent | Lost in OAA |
4 of 10 SecurityV0 edge types have direct OAA equivalents. 2 have partial equivalents. 4 are completely lost — these are the execution-specific edges that define SecurityV0's differentiation.
11. Open Questions for Founder Decision
Q1: Is Veza integration a product requirement?
The OAA export adds ~40h of implementation effort (Phases 3-5). If Veza integration is not a near-term product requirement, the OAA export can be deferred entirely. The internal execution_chains collection provides all forensic, compliance, and CISO capabilities without OAA.
Team recommendation: Build Phase 1 (chains) and Phase 1.5 (canonical permissions). Defer OAA export (Phase 3+) until a customer or sales requirement demands it.
Q2: Should SecurityV0 position itself as extending OAA?
If SecurityV0 publishes an OAA extension for execution exposure, it could become a reference pattern for the OAA community. This is a product/positioning decision, not a technical one.
Q3: Should the NormalizedNodeType enum change?
Team recommendation: No. All 6 roles agree to keep the existing type enum stable. Add semantic richness through properties.resource_type subtypes instead (Architect recommendation). This avoids breaking queries, filters, SCIM exports, and UI.
12. Answer to the Core Question
"How should autonomous execution flows map to OAA concepts?"
Team Answer: They shouldn't — not internally.
OAA is a permission snapshot format designed to answer "who can do what to which resource." Execution chains answer "what triggers what, through what code, via what authentication, producing what outcome." These are fundamentally different questions.
The right architecture is:
-
Internal model (execution_chains + entities): SecurityV0's canonical representation. Provides stable chain identity, temporal versioning, forensic investigation, chain-level findings, and cross-system execution path tracking. This is what the CISO uses daily.
-
OAA export (projection layer): An output format for interoperability. Projects source systems as OAA Applications, automation artifacts as Resources, and chain membership as custom properties. This is what Veza or third-party tools consume.
-
OAA vocabulary enrichment: Add canonical permission types (DataRead, DataWrite, etc.) to chain documents for compliance communication. This bridges the gap between internal terms (hr_agent_workspace role) and auditor terms (DataWrite on HR data).
What Changed from Round 3
| Aspect | Round 3 | Round 4 |
|---|---|---|
execution_chains collection | Recommended (3/5 majority) | Confirmed (6/6 unanimous) |
| PO dissent (virtual entity) | 1 dissenter | Resolved — PO reverses position |
| OAA alignment | Not considered | Export layer, not internal model |
| Canonical permissions | Not considered | Add to chain documents (4h incremental) |
| Trigger/data modeling | Not analyzed | Incident table = Resource in 3 roles, distinguished by edge type |
| Execute permission gap | Not identified | sv0_action_type extension under NonData |
13. Files Produced (Round 4)
| File | Role | Lines | Key Topics |
|---|---|---|---|
| 04-oaa-mapping-oaa-specialist.md | OAA Specialist | 1,762 | 3 approach evaluation, hybrid model design, OAA entity/permission mapping reference |
| 04-oaa-mapping-product-owner.md | Product Owner | 1,316 | Scoring matrix, UI mockups, SCIM/SIEM analysis, PO reversal on Round 3 dissent |
| 04-oaa-mapping-architect.md | Architect | 2,154 | Full schema designs (3 approaches), NormalizedNodeType analysis, Neo4j Cypher, trigger/data problem |
| 04-oaa-mapping-ciso.md | CISO | 1,279 | Compliance mapping (5 controls), forensic walkthrough, Execute gap, dual-layer recommendation |
| 04-oaa-mapping-integrator.md | Integrator | 1,252 | Connector architecture, OAA SDK decision, platform adapter design, cross-system limitations |
| 04-oaa-mapping-developer.md | Developer | 1,552 | Implementation comparison, TypeScript types, effort estimates (76h/106h/138h), file impact |
| 04-oaa-mapping-synthesis.md | Lead | This document |
Round 4 analysis complete. 6 perspectives, ~9,315 lines of research. Unanimous consensus: execution_chains collection (Round 3) is the internal authority; OAA is an export projection layer. PO reverses Round 3 dissent — now fully unanimous. Total estimated effort: Phase 1 (chains) 94h + Phase 1.5 (canonical permissions) 4h + Phase 3 (OAA export) 24h = 122h for chains + OAA. Deferred: Veza integration (Phase 5, 8h).