ADR-009: OAA Export Projection (Deferred)
Status
Proposed — deferred until customer need (2026-02-13)
Context
The founder asked whether automations should be modeled as OAA Applications or Resources. This is a recurring design question: should SecurityV0's internal data model conform to OAA (Veza's Open Authorization API), or should OAA be an export format?
OAA is a standardized format for representing authorization data, used by 250+ connectors in the Veza ecosystem. It defines entity types (local_user, local_role, local_group, resource) and relationship types (member_of, has_role, can_access).
The tension
- OAA-first approach: Model everything as OAA entities internally, ensuring natural export. But OAA lacks execution chain concepts, credential entities, and automation-specific relationships.
- Internal-model-first approach: Design the optimal model for execution exposure analysis, then project to OAA for export. Richer internal model, but export is lossy.
The team analyzed this across 6 perspectives (security engineering, data modeling, product, connector architecture, OAA compliance, and graph theory).
Decision
OAA is an export projection layer, not the internal data model. SecurityV0's internal model (entities + execution_chains) is a superset of OAA. When OAA export is needed, a read-only projection maps internal types to OAA types.
OAA export mapping
| SecurityV0 Internal Type | OAA Export Entity | Mapping Fidelity | Notes |
|---|---|---|---|
identity | local_user | HIGH | Direct mapping — authenticating entities become OAA users |
automation | resource (type: automation) | HIGH | OAA resources support custom types; automation is a natural fit |
connection | resource (type: connection) | HIGH | Connection configs are resources in OAA's model |
credential | custom property on local_user | MEDIUM | OAA has no first-class credential entity; mapped as user properties |
owner | local_user (type: human) | HIGH | Human owners map to OAA users with human type marker |
role | local_role | HIGH | Direct mapping |
permission | custom_permission | HIGH | OAA supports custom permission definitions |
resource | resource | HIGH | Direct mapping |
execution_evidence | (not exported) | N/A | OAA has no concept of execution evidence |
What is lost in OAA export
| Internal Concept | OAA Equivalent | Loss |
|---|---|---|
| Execution chains | None | Full loss — OAA has no chain concept |
| Typed execution edges (CALLS, INVOKES, USES, AUTHENTICATES_AS) | Generic can_access | Semantic loss — edge types collapsed |
| Credential as first-class entity | Custom property | Structural loss — can't query credentials independently |
| Temporal tracking (first_seen, last_seen, drift) | None | Full loss — OAA is point-in-time |
| Evidence packs | None | Full loss — OAA has no evidence model |
Why this is acceptable
The information lost in OAA export is precisely the information that differentiates SecurityV0 from OAA-based platforms. Customers who need execution chain analysis use SecurityV0's native API and UI. OAA export serves a different purpose: feeding authorization data into existing Veza-compatible workflows.
Consequences
Positive
- Internal model optimized for execution exposure analysis — no compromises to fit OAA constraints
- OAA compatibility preserved — export projection provides interoperability with Veza ecosystem
- Clean separation of concerns — internal model evolves independently of OAA spec changes
- Entity type reclassification (ADR-006) maps naturally to OAA — identities are users, automations are resources
Negative
- OAA export is lossy — documented limitations (execution chains, temporal tracking, evidence packs not exportable)
- Additional code to maintain — export projection layer must be updated when internal model or OAA spec changes
Neutral
- Implementation deferred — no code written until customer or sales need is identified
- When implemented, OAA export is a read-only projection — internal model is the source of truth, export is derived
When to Reconsider
- If a customer requires OAA-format data for integration with their existing Veza deployment
- If the OAA spec adds execution chain or temporal tracking concepts that close the gap
- If a sales opportunity is blocked by lack of OAA export capability
Analysis
Round 4 Synthesis — 6 agents, 9,315 lines, 6/6 unanimous