Access Chain — Identity-Anchored Control Primitive
Access chain as the canonical product unit — identity-anchored, with paths as expandable evidence. Reframed per founder feedback from aggregation model to first-class control primitive.
Access chain as the canonical product unit — identity-anchored, with paths as expandable evidence. Reframed per founder feedback from aggregation model to first-class control primitive.
Split autonomous_identity into 4 distinct types (identity, automation, connection, credential) to accurately model non-authenticating artifacts
Introduce type='permission_set' for AWS IAM Policies (and analogous policy-holder entities) rather than reusing type='role'
Deep critical review of SecurityV0 architecture and data model with evidence-grade gaps, risk analysis, and prioritized improvements
Plan to update architecture docs (01-data-model.md, 03-database.md, 05-connectors.md, glossary.md) with Round 3-5 decisions
Status tracker and landing page for all research documents in docs/architecture/research/
Why SecurityV0's current resource identity model cannot support deterministic path-scoped execution evidence attribution, and a proposal to introduce a first-class canonical resource_key on both entities and evidence records.
Role-based research synthesis aligned to founder vision and W1 wedge scope, separating automation definition, exposure path, topology, and runtime proof with an implementable W1-first plan
9-type entity system (identity, workload, connection, credential, owner, role, permission, resource, execution_evidence) and execution chains for the SecurityV0 execution/authority graph
Research into whether 'endpoint type' should be a new entity, a derived property, or is already captured
Critical analysis of the current entity_type system
Architect perspective on Round 2 execution-flow analysis: six backward-compatible changes to restore full BR-to-SI-to-SP-to-resource execution provenance without adding a new entity_type.
GPT-authored research on extending SecurityV0's data model with SCIM and Veza OAA — read-only constraint, deterministic detections, and forensic temporal tracking shape what is and is not directly applicable.
One-page founder/investor position on the graph data-model question: what company SecurityV0 is building, what is bounded today, and what the contract change ahead of the migration staircase is.
How SecurityV0's authority-graph data model scales today, the trade-offs we accepted, and the prepared migration staircase to native graph engines and cell architecture.
Opus-authored research on reshaping SecurityV0's data model with SCIM and Veza OAA: layered adoption (OAA-inspired schema internally, SCIM-compatible API externally) preserves SecurityV0's temporal and execution-path concepts.
Complete schema mapping analysis for modeling SecurityV0 automation chains against the Veza OAA data model
6-agent analysis on mapping autonomous execution flows to OAA (Open Authorization API) concepts
Self-contained research prompt for AI tools to propose a better name for entity_type 'automation' to avoid collision with the broader 'Automation Definition' concept
Architectural analysis reconciling doc 06 (4-concept model) and doc 07 (naming plan) with Sergey's W1 product vision, UX spec, and existing 9-entity data model