Architecture Documentation Update — Change Summary

Date: 2026-02-13 Scope: Entity type reclassification, execution chain modeling, relationship type updates Trigger: Round 5 (Entity Type Classification) synthesis from the 2026-02-12 Automation Classification analysis

---

Overview

This document summarizes all changes made to SecurityV0 architecture documentation following the 5-round automation classification analysis. The changes implement the consensus recommendation to reclassify the autonomous_identity catch-all into 4 distinct entity types: automation, connection, credential, and the narrowed identity.

These changes affect the data model, database schema, connector interface contract, glossary, and introduce 4 new Architecture Decision Records.

---

Files Changed

File	Change Type	Scope
architecture/01-data-model.md	Major rewrite	9-type entity system, decision tree, subtypes, relationships, execution chains, OAA mapping
architecture/03-database.md	Addition	execution_chains collection + Phase 2 temporal collections, updated entity type references
architecture/05-connectors.md	Modification	NormalizedNodeType/EdgeType enums, new property interfaces, Chain Hints section
docs/glossary.md	Modification	Updated entity/relationship tables, new terms (Connection, Execution Chain, OAA, Veza)
architecture/decisions/adr-006-entity-type-reclassification.md	New	Documents the 4-type split decision
architecture/decisions/adr-007-execution-relationship-types.md	New	Documents 4 new edge types + edge migration mapping
architecture/decisions/adr-008-execution-chains-collection.md	New	Documents platform-computed chain tracking collection
architecture/decisions/adr-009-oaa-export-projection.md	New	Documents OAA as export format, not internal model
architecture/decisions/index.md	Modification	Added 4 ADR entries + summaries, updated ADR-002 summary
mkdocs.yml	Modification	Added 4 ADR entries to navigation

---

Detailed Changes and Rationale

1. Entity Type Reclassification (ADR-006)

What changed: The autonomous_identity type was split into 4 distinct types:

• identity — Entities that authenticate (service principals, OAuth apps, machine accounts)
• automation — Entities that define executable behavior (Business Rules, Flows, Scheduled Jobs)
• connection — Outbound integration endpoints (REST Messages, HTTP Connections)
• credential — Authentication material (OAuth Profiles, API Keys, Certificates)

Why: The Round 5 analysis established that these 4 categories have fundamentally different security semantics:

• Identity: authenticates and has roles/permissions
• Automation: executes logic but does NOT authenticate — delegates via RUNS_AS
• Connection: defines WHERE data goes (egress analysis target)
• Credential: holds secrets with rotation/expiration lifecycle

Conflating them under autonomous_identity made it impossible to answer "what can this automation actually do?" without traversing untyped edges.

Impact on existing code: The platform ingestion normalizer accepts autonomous_identity as a NormalizedNodeType during a migration window and remaps it to the correct internal type. No breaking changes to existing connectors.

2. New Relationship Types (ADR-007)

What changed: 4 new edge types were added to model the execution chain from automation logic through to authenticating identity:

Edge	Direction	Purpose
CALLS	automation → automation	Code invocation (Business Rule calls Script Include)
INVOKES	automation → connection	Automation uses outbound connection
USES	connection → credential	Connection uses authentication material
AUTHENTICATES_AS	credential → identity	Credential represents an identity

Why: The previous model had only EXECUTES_ON (identity → resource) and AUTHENTICATES_VIA (identity → credential), which were both too coarse-grained. With the new types, you can trace the complete chain:

BR --CALLS--> SI --INVOKES--> REST Message --USES--> OAuth Profile --AUTHENTICATES_AS--> Service Principal

This enables deterministic blast radius analysis: "If this Business Rule is compromised, what Service Principal credentials are reachable?"

Edge migration mapping:

• EXECUTES_ON (automation → REST message) → INVOKES (when target is connection)
• EXECUTES_ON (automation → resource) → kept as-is
• AUTHENTICATES_VIA (connection → credential) → USES
• AUTHENTICATES_VIA (identity → credential, legacy) → removed (path now goes credential → identity via AUTHENTICATES_AS)

3. Execution Chains Collection (ADR-008)

What changed: New execution_chains MongoDB collection stores platform-computed chain tracking with:

• Stable chain identity anchored to entry point entity (survives credential rotation)
• Composition fingerprint (SHA256 of sorted entity_id:role pairs) for structural drift detection
• Summary statistics (trigger, destination, egress_category, ownership_status, canonical_permissions)
• Phase 2 temporal collections (execution_chain_versions, execution_chain_events) for temporal drift tracking

Why: Execution chains are the primary unit of analysis for CISOs asking "list all automations that can reach HR data and who owns them." Pre-computing chains with stable identity enables:

1. O(1) chain lookup by entry point
2. Drift detection via fingerprint comparison
3. Temporal queries ("what did this chain look like 30 days ago?")

Important: Chains are assembled platform-side via BFS, not by connectors. Connectors provide entities and relationships; the platform computes chains during ingestion.

4. OAA Export Projection (ADR-009)

What changed: Documented that OAA (Veza's Open Authorization API) is an export format, not the internal data model. SecurityV0's model is a superset — it captures execution chains, temporal drift, and evidence provenance that OAA does not represent.

Status: Proposed (deferred). No implementation until customer integration requires OAA-format export.

What is lost in OAA export: Execution chains, temporal tracking, evidence packs, execution_mode/security_relevance. These are acceptable losses for the export use case because OAA connectors focus on authorization state, not execution flow.

5. Data Model (01-data-model.md) Major Rewrite

What changed:

• Entity Types table expanded from 6 to 9 types with detailed descriptions, subtypes, key properties, and examples
• New dedicated sections for Automation, Connection, and Credential entities with examples
• Entity Classification Decision Tree — Mermaid flowchart with 5-question checklist for classifying new entities
• Subtype Definitions — TypeScript union types for IdentitySubtype, AutomationSubtype, ConnectionSubtype, CredentialSubtype
• Relationships — Complete table expanded from 11 to 15 relationship types, split into Core/Automation/Derived sections
• Edge migration mapping table documenting legacy→new edge transitions
• Execution Chains section with chain composition, identity, fingerprint, assembly, lifecycle
• Execution Flow Provenance Diagram — Mermaid diagram showing the full typed chain from trigger through authorization
• OAA Mapping Reference — Table showing internal type → OAA export entity mapping
• Overview ASCII diagram updated to show Automation → Connection → Credential → Identity chain
• AUTHENTICATES_TO vs AUTHENTICATES_AS clarification note added

Why: The previous data model documented 6 entity types with automations as "identity subtypes." This made it impossible to define typed relationships (CALLS, INVOKES, USES) or to model execution chains as first-class entities.

6. Database Schema (03-database.md) Updates

What changed:

• entity_type comment and entity types paragraph updated to list all 9 types
• execution_chains collection schema with full field documentation
• execution_chain_versions collection (Phase 2) for temporal tracking
• execution_chain_events collection (Phase 2) for event history
• 9 new indexes for the 3 new collections
• baseline_metadata.entity_counts expanded to include all 9 entity types
• entity_refs.entity_type comment updated to include resource and all types
• Fixed execution_type → execution_mode in example document

7. Connector Framework (05-connectors.md) Updates

What changed:

• NormalizedNodeType enum: Added automation, connection, credential, execution_evidence. Kept human_identity. Added autonomous_identity with migration compatibility note.
• NormalizedEdgeType enum: Added CALLS, INVOKES, USES, AUTHENTICATES_AS. Marked AUTHENTICATES_VIA as deprecated.
• Renamed AutonomousIdentityProperties → IdentityProperties with executionMode and securityRelevance
• New AutomationProperties interface with automationSubtype, executionMode, securityRelevance
• New ConnectionProperties interface with connectionSubtype, egress properties
• New CredentialProperties interface with credentialSubtype, rotation properties
• New EdgeProperties fields for CALLS, INVOKES, USES, AUTHENTICATES_AS
• Chain Hints section — Optional ChainMembershipHint interface for connector-provided chain metadata
• Updated normalization note for human_identity → owner mapping

8. Glossary Updates

What changed:

• Updated Automation definition with entity_type: "automation" and ADR-006 cross-reference
• Added Connection, Execution Chain, Chain Composition Fingerprint to Domain Concepts
• Added Execution Chains Collection to Platform Concepts
• Added OAA (Open Authorization API) and Veza to Platform Concepts
• Replaced Entity Types table: 9 types with descriptions and entity_type values
• Replaced Relationship Types table: 15 relationships with directions, meanings, and ADR cross-references

---

Review Process

Architect Review

An architect review was conducted checking cross-document consistency, technical accuracy, broken references, completeness, and stale content.

Critical findings fixed:

1. execution_type → execution_mode in 03-database.md example document
2. canonical_permissions schema in ADR-008 aligned with 03-database.md (changed from [String] to { reads, writes })
3. IdentityProperties.executionType in 05-connectors.md updated to executionMode with correct enum values
4. CALLS.callType values aligned between 01-data-model.md (direct | include | delegate) and 05-connectors.md
5. Mermaid diagram TRIGGERS_ON arrow direction corrected (automation → resource)
6. ADR-002 summary in index.md updated to list all 9 entity types
7. Edge migration mapping for AUTHENTICATES_VIA (identity → credential) clarified as removed (not remapped to USES)
8. ADR-007 typed chain traversal final hop corrected (was AUTHENTICATES_TO → resource, now HAS_ROLE → GRANTS → APPLIES_TO → resource)
9. ADR-007 AUTHENTICATES_TO example corrected (was "SP authenticates to Entra ID", now "Entra SP authenticates to ServiceNow Integration User")
10. baseline_metadata.entity_counts expanded to include all 9 entity types
11. entity_refs.entity_type in execution_chains schema expanded to include resource

Remaining items for future work:

• IdentitySubtype in connector interface has extra values (github_app, pat, agent, bot) beyond the data model's canonical set — to be resolved when GitHub/AWS connectors are implemented
• CredentialProperties.credentialSubtype in connector is a superset of data model's CredentialSubtype — connector produces wider set, platform normalizer maps
• DELEGATES_TO, MEMBER_OF, APPROVED_BY edge types exist in connector contract but not in data model — reserved for future use, to be documented when connectors emit them

New Developer Review

A "first day on the team" comprehensibility review identified:

Addressed in this iteration:

• Added AUTHENTICATES_TO vs AUTHENTICATES_AS clarification note in data model
• Added OAA and Veza definitions to glossary
• Fixed IdentityProperties to use executionMode (was using deprecated executionType)

Deferred improvements (non-blocking):

• Add "Start Here" reading guide to documentation set
• Add "Connector Developer Quick Reference" section to 05-connectors.md
• Add concrete NormalizedGraph JSON example to connector doc
• Add edge migration status column (active/complete/pending)
• Clarify credential_subtype vs credential_type distinction
• Clarify who computes ownershipState (connector vs platform)

Praise from Reviews

Both reviewers highlighted as excellent:

• The end-to-end BEFORE/AFTER example in 01-data-model.md
• The Entity Classification Decision Tree (5-question mermaid flowchart)
• Evidence Completeness design (declaring available/unavailable evidence)
• ADR structure with honest trade-off documentation
• Execution Mode x Security Relevance two-dimensional classification
• Execution Flow Provenance Diagram with entity type annotations

---

Round 2 — External Review Fixes (2026-02-13)

An external critical review identified 7 remaining issues (1 critical, 2 high, 4 medium). All were addressed:

Critical fixes (round 2)

1. 04-api-layer.md staleness notice — Added prominent deprecation warning documenting 6 specific gaps (missing entity types, wrong field names, missing endpoints, missing edge types). The endpoint contract structure remains valid; entity filters and examples need updating.

2. AUTHENTICATES_VIA semantics unified — Glossary previously said Identity → Credential which contradicted the data model's statement that identity→credential is removed. Fixed glossary to show AUTHENTICATES_VIA as fully deprecated with two distinct migration paths: connection→credential → USES, identity→credential → removed (now credential→identity via AUTHENTICATES_AS). Fixed 05-connectors.md comment to match.

3. entity_refs.entity_type in ADR-008 — Expanded from 4 types (identity | automation | connection | credential) to 7 types (resource | automation | connection | credential | identity | role | permission) to match the database schema in 03-database.md. Chains may include trigger resources and authorization chain entities.

4. "9 node types" wording in 01-data-model.md — Line 988 previously listed owner among "9 node types" in a sentence pointing to 05-connectors.md, but the connector uses human_identity (normalizer maps to owner). Reworded to list the 9 NormalizedNodeType values correctly and explain the mapping.

5. Chain anchor wording — 01-data-model.md previously said "first automation or identity" while ADR-008 defines the anchor as always the entry-point automation. Removed "or identity" and added explicit reference to ADR-008 chain identity design.

6. NodeProperties union type — 05-connectors.md line 359 referenced NodeProperties without defining it. Added a type NodeProperties union of all 9 type-specific property interfaces with a mapping comment.

7. Adjacent doc staleness notices — Added ⚠ Staleness Warning blocks to:

   • 06-scim-oaa-integration.md: 5 specific gaps (missing entity types, executionType → executionMode, SCIM extension subtypes, OAA entity counts, ADR-009 deferred status)
   • 07-ui-reporting.md: 5 specific gaps (filter sidebar, node colors, edge styles, rank assignment, execution chain views)

Files changed (round 2)

File	Change
glossary.md	AUTHENTICATES_VIA row rewritten with deprecation semantics
05-connectors.md	AUTHENTICATES_VIA comment fixed; NodeProperties union type added
01-data-model.md	Chain anchor wording fixed; "9 node types" wording clarified
architecture/decisions/adr-008-execution-chains-collection.md	entity_refs.entity_type expanded to 7 types
04-api-layer.md	Staleness warning + metadata annotation added
06-scim-oaa-integration.md	Staleness warning added
07-ui-reporting.md	Staleness warning + metadata annotation added

---

Round 3 — Post-Round-2 Review Fixes (2026-02-13)

A follow-up review of round-2 fixes identified 3 remaining issues (1 high, 2 medium). All addressed:

Fixes (round 3)

1. entity_refs.role semantics expanded (High) — After expanding entity_refs.entity_type to 7 types in round 2, the role field still only had 5 values that didn't cover resource, role, or permission entities. Added 4 new roles: trigger_resource, authorized_role, authorized_permission, target_resource. Updated the Chain Roles table in ADR-008 with entity_type column. Updated assembly process to show full BFS path including TRIGGERS_ON, HAS_ROLE, GRANTS, APPLIES_TO. Aligned 03-database.md role comment.

2. API doc endpoint naming (Medium) — Staleness warning in 04-api-layer.md speculated /api/v1/chains as endpoint name, which conflicts with implementation plan's /execution-chains. Removed specific path, now says "chain listing, chain-level findings, chain-level blast radius" generically.

3. ADR-007 AUTHENTICATES_VIA clarity (Medium) — Three fixes: (a) Context section rewritten to describe both legacy usages (connection→credential and identity→credential) with distinct semantics instead of vague "catch-all" wording. (b) Deprecated relationship table expanded from 1 row to 2 rows showing both migration paths (USES for connection→credential, removed for identity→credential). (c) Full edge migration mapping table gained the missing AUTHENTICATES_VIA identity→credential → _(removed)_ row.

Files changed (round 3)

File	Change
architecture/decisions/adr-008-execution-chains-collection.md	role enum expanded to 9 values; Chain Roles table expanded with entity_type column; assembly process updated
architecture/03-database.md	entity_refs.role comment expanded to 9 values
architecture/04-api-layer.md	Removed speculative /api/v1/chains endpoint path
architecture/decisions/adr-007-execution-relationship-types.md	AUTHENTICATES_VIA context rewritten; deprecated table expanded; migration mapping row added

---

Round 4 — Stale Doc Rewrites (2026-02-13)

Three architecture docs (03, 05, 06) still contained staleness warnings from round 2. This round replaced the stale content with full rewrites reflecting the 9-type entity model, ADRs 006-009, and actual platform implementation state.

Status marker convention

Every section/feature now carries an implementation status tag:

Marker	Meaning
[Implemented]	Feature exists in current sv0-platform code
[Planned]	Designed in ADRs/data model, not yet implemented
[Deferred]	No implementation timeline

Changes per file

04-api-layer.md — Full rewrite (~1060 lines)

• Replaced staleness warning with implementation status block
• Entity type filter expanded to 9 types; subtype filters for all 4 subtypeable types (identity_subtype [Implemented], automation/connection/credential_subtype [Planned])
• Added implemented filters: egress_category, ownership_status, risk_group, execution_mode, security_relevance, q, has_findings
• execution_type → execution_mode in all examples
• Entity response examples show both identity and automation entities
• Relationship detail includes CALLS, INVOKES, USES, AUTHENTICATES_AS examples with correct [Planned] markers
• New endpoint sections: batch fetch, version history, subgraph traversal [Implemented], execution chains [Planned]
• Execution chain detail uses ADR-008 canonical roles (code_component, outbound_target, auth_credential, destination_identity)
• Full endpoint summary table with status markers (22 endpoints)
• Structured query DSL with operators table

06-scim-oaa-integration.md — Full rewrite (~520 lines)

• Status: Draft — SCIM [Planned], OAA [Deferred]
• OAA entity mapping table replaced with ADR-009's 9-type mapping
• "What is Lost in OAA Export" table added (execution chains, typed edges, temporal, evidence packs)
• "What SecurityV0 Adds Beyond OAA" comparison table added
• All OAA sections marked [Deferred] per ADR-009
• SCIM NHI extension: identityType → identitySubtype, executionType → executionMode
• SCIM Users endpoint: identity-only scope note, cursor pagination extension added to list example
• ownershipStatus values: healthy → owned (aligned with API filter vocabulary)

07-ui-reporting.md — Full rewrite (~750 lines)

• Status block with [Implemented]/[Planned] markers
• Tech stack: ReactFlow → @xyflow/react 12.x, added @tanstack/react-table 8.x
• Route table rewritten from actual App.tsx (includes /automations, /temporal, /execution-chains [Planned])
• Entity statistics expanded to 9 types; filter sidebar 9 types
• Node colors table: 3 new entries (automation=#F97316, connection=#06B6D4, execution_evidence=#A855F7)
• Edge styling: 4 new edges (CALLS, INVOKES, USES, AUTHENTICATES_AS) + BELONGS_TO + AUTHENTICATES_VIA deprecated
• New §9A Execution Chains Page [Planned] with chain list table and detail view
• TanStack Query hooks: useSubgraph [Implemented], useExecutionChains/useExecutionChain [Planned]

01-data-model.md — Targeted fixes

• identity_type → identity_subtype in property name (line 107) and subtype reference text (line 451)
• Removed system_execution from IdentitySubtype enum (not a valid identity subtype per ADR-006)

Review process (round 4)

Architect review identified 14 findings (3 High, 6 Medium, 5 Low/pass):

• Fixed: Chain roles in 03 using non-canonical names → aligned to ADR-008 (code_component, outbound_target, auth_credential, destination_identity)
• Fixed: identity_type → identity_subtype in API response examples
• Fixed: RUNS_AS/EXECUTES_ON status markers split from [Planned] to [Implemented] in 03
• Fixed: Chain API response entry_point_id → anchor_entity_id (aligned with ADR-008/01-database)
• Fixed: first_seen_at → first_detected_at (aligned with ADR-008/01-database)
• Fixed: Status header expanded to include batch, versions, subgraph, events, structured query
• Fixed: BELONGS_TO edge added to 06 edge styling table
• Fixed: SCIM ownershipStatus value healthy → owned
• Low/pass: Entity type order, SCIM naming, SCIM scope, ADR references, endpoint paths — all consistent

New developer review identified 20 findings (3 High, 9 Medium, 8 Low):

• Fixed (overlap with architect): identity_type/subtype, RUNS_AS status, entry_point_id, first_seen_at
• Fixed: Chain API response missing name, summary.trigger, summary.destination fields → added
• Fixed: SCIM list response missing cursor pagination extension → added
• Fixed: SCIM pagination reference in 03 reworded (not "consistent" — different formats)
• Deferred: Abbreviation expansions, blast radius definition, evidence pack viewer section alignment, section renumbering, structured query field prefix consistency

Verification checks (round 4)

Check	Result
execution_type in architecture docs	Only in deprecated context (01-data-model.md migration note)
AUTHENTICATES_VIA in architecture docs	Only in deprecated/migration context
identity_type as SecurityV0 property	Removed from 03; remaining in 05 are OAA schema fields
entry_point_id in architecture docs	No matches (all aligned to anchor_entity_id)
first_seen_at in architecture docs	No matches (all aligned to first_detected_at)
/execution-chains consistency	Used in all docs (never /chains)
Subtype enums match 01-data-model.md	Confirmed in 03 filter params
SCIM Users identity-only scope	Confirmed in 05

Files changed (round 4)

File	Change
architecture/04-api-layer.md	Full rewrite — API contract with 9-type model, status markers
architecture/06-scim-oaa-integration.md	Full rewrite — SCIM/OAA with ADR-009 alignment
architecture/07-ui-reporting.md	Full rewrite — UI architecture with new entity types
architecture/01-data-model.md	Targeted fixes — identity_subtype, remove system_execution

---

Round 5 — Code-Level Review Fixes (2026-02-13)

A code-level review cross-referenced the architecture docs against actual sv0-platform source code and identified 6 issues where [Implemented] markers or response schemas did not match the live codebase.

Fixes (round 5)

Critical: Phantom [Implemented] endpoints

1. GET /api/v1/events — No events route registered in app.ts. Events only accessible per-entity via GET /entities/{id}/timeline. Downgraded to [Planned] with explanatory note.
2. POST /api/v1/syncs — syncs.ts only has GET routes. Downgraded to [Planned] with note that syncs are triggered via connector CLI POST /ingest/normalized-graph.
3. POST /api/v1/query — No query route in app.ts. Downgraded to [Planned] with note.

Critical: Phantom filter 4. has_findings filter — Not parsed in entities.ts query filter construction (lines 19-31). Downgraded to [Planned].

High: Response schema mismatches 5. Entity list/detail responses used id instead of _id — EntityDoc uses _id (MongoDB convention). Fixed all entity response examples to _id. 6. Entity list responses included non-existent relationship_summary and finding_count fields — EntityDoc has no such fields. StorageAdapter returns full entity documents. Replaced relationship_summary with full relationships array matching the actual EntityRelationship type (type, target_id, properties). 7. Subgraph response edges used type field — SubgraphEdge interface uses relationship_type. Fixed to relationship_type.

High: Automations list query pattern 8. 07-ui-reporting.md said automations page uses entity_type=automation — But use-automations.ts actually queries entity_type=identity with identity_subtype filter (because automation is not yet in the platform's EntityType enum). Fixed route table and stats panel. Added explanatory note about the workaround and target state.

Medium: Tech stack versions 9. Updated 07-ui-reporting.md versions from actual ui/package.json: React 18.x→19.x, Vite 5.x→7.x, React Router 6.x→7.x, Tailwind CSS 3.x→4.x, lucide-react 0.3.x→0.5.x. TypeScript refined to 5.9.x.

Medium: Timeline pagination shape 10. Timeline endpoint documented cursor pagination — Actual entities.ts returns { data } only with limit param (no cursor). Removed cursor query param and cursor/meta from timeline response.

Cascading fix: Syncs page 11. 07-ui-reporting.md syncs route referenced POST /syncs as [Implemented] — Fixed to note manual trigger is [Planned]. Manual trigger button in §9.3 marked [Planned].

Verification checks (round 5)

Check	Result
relationship_summary in 04-api-layer.md	No matches (fully removed)
finding_count in 04-api-layer.md	No matches (fully removed)
GET /events marked [Implemented]	No matches — now [Planned]
POST /syncs marked [Implemented]	No matches — now [Planned]
POST /query marked [Implemented]	No matches — now [Planned]
has_findings marked [Implemented]	No matches — now [Planned]
Entity response "id": vs "_id":	Entity examples use _id; non-entity docs (events, findings, syncs, chains) retain id (different doc types, not flagged)
Subgraph edge field	Uses relationship_type (matches SubgraphEdge interface)
Tech stack versions match package.json	Confirmed

Files changed (round 5)

File	Change
architecture/04-api-layer.md	Status block updated; has_findings→[Planned]; entity response schemas fixed (_id, relationships, no relationship_summary/finding_count); timeline response fixed; events/POST syncs/query→[Planned]; subgraph edge type fixed; summary table updated
architecture/07-ui-reporting.md	Automations route + stats panel fixed to actual query pattern; tech stack versions updated; syncs page POST→[Planned]

Platform source files referenced

File	Lines	What was verified
sv0-platform/src/api/app.ts	64-70	Route registration (no events or query routes)
sv0-platform/src/api/routes/entities.ts	19-31, 101-111	Query filter parsing (no has_findings); timeline returns { data } only
sv0-platform/src/api/routes/syncs.ts	8, 32	Only GET routes
sv0-platform/src/api/routes/graph.ts	56	Subgraph response wrapping
sv0-platform/src/domain/entities/types.ts	48-62	EntityDoc uses _id; EntityRelationship uses type
sv0-platform/src/storage/storage-adapter.ts	62-67	SubgraphEdge uses relationship_type
sv0-platform/ui/src/hooks/use-automations.ts	20-21	Queries entity_type=identity + identity_subtype
sv0-platform/ui/package.json	17-25	Actual dependency versions

---

Open Questions for External Review

1. AUTHENTICATES_VIA deprecation timeline — The migration window accepts legacy AUTHENTICATES_VIA edges. When should the platform stop accepting them?

2. IdentitySubtype canonical set — The connector interface allows subtypes (github_app, pat, agent, bot) that are not in the data model's TypeScript union. Should these be added to the canonical set now, or when the connectors that produce them are implemented?

3. Execution chain assembly trigger — Should chains be recomputed on every sync, or only when the diff engine detects changes to chain-relevant entities?

4. OAA export priority — ADR-009 is "Proposed" status. Is there customer pressure to implement OAA export sooner, or can it remain deferred?

5. DELEGATES_TO / MEMBER_OF / APPROVED_BY — These edge types exist in the connector TypeScript interface but have no corresponding data model documentation. Should they be removed from the connector interface, or documented in the data model as reserved?