Skip to main content

Graph Data Model — Position

Audience: founder, investor advisory, executive buyer. Backing document: Graph Scalability and Migration Strategy (engineering execution); Sizing and Decision Points (numbers). Status: this position supersedes any prior framing that treated bounded-hop as the destination.

The question, sharpened​

The security investor advisory call (May 2026) asked a sharper version of a question the architecture audit (April 2026) had already raised. The audit answered "is MongoDB acceptable for MVP?" — yes, with a defined exit path. The advisory call asked "what company are you building: a bounded-hop posture tool, the full-chain authority system of record, or a future rewrite?" That is the company-defining question, and it has to be answered before the operational migration staircase is meaningful.

Position​

SecurityV0 is the authority system of record for non-human identities. Full-chain reasoning — workload → connection → credential → identity → role → permission → resource, including cross-system chains — is the product architecture. Bounded-hop materialized paths are today's MVP implementation, not the destination.

That commitment has three parts.

1. Full-chain reasoning is the product architecture​

The differentiating claim is not "we find some risky identities." It is "we can explain what this non-human identity can reach through execution authority." That claim is multi-hop by nature. Capping the product at bounded-hop reduces it to a posture summarization tool, which is not the category we are building.

Honest disclosure: the headline limitation is no longer depth. Write-time path materialization now traverses to MAX_AUTH_CHAIN_DEPTH = 2 — two hops, which reaches a three-system chain such as Jira-webhook → AWS-Lambda → IAM-role → resource. The real remaining gap is provenance: authority paths store auth_chain_depth / via_identity, not an ordered chain_steps record, so the platform cannot yet reason end-to-end over the chain it traverses. The position is depth is no longer the bound, ordered-chain contract change first. We do not claim today's path record as the product's full-chain reasoning.

2. The data-model contract changes before the engine does​

The first move is not "buy a graph database." It is to promote AuthorityChain to a first-class persisted entity with ordered chain_steps: nodes, edges, systems, credentials, evidence references, timestamps, and provenance. The existing bounded materialized authority_paths then becomes a derived projection of that chain.

This is Step 0 — the contract change that precedes the operational migration staircase documented in the backing strategy paper. The reason it comes first: a graph database solves traversal cost; it does not solve the four upstream pipeline cliffs the backing paper identifies (full-tenant evaluator reads, synchronous evidence aggregation, in-memory FIFO queue, role fan-out write amplification). A graph engine fed by an unstabilized pipeline produces faster stale answers, not better ones.

Once the chain contract is in place, the staircase is the right execution path: stabilize the pipeline, then add a graph read model when traversal-cost triggers fire, then add per-tenant isolation, then federated/edge processing for the largest estates. Triggers — not deadlines — drive each step.

One clarification of the architecture, because it strengthens the case rather than weakening it: the model is not purely write-time pre-compute. Intra-system reach is materialized at write time; cross-system reach — the headline "what can this identity reach across systems" — is composed at read time from a separate cross-system identity store (shipped 2026-05). This is deliberate: it is the first proof that the storage seam already supports a hybrid read model, not just static pre-computed answers. The chain contract and the eventual graph engine build on a seam that has already demonstrated read-time composition in production, bounded by explicit caps.

3. Federated/edge processing is the enterprise path, not the MVP fix​

For very large or regulated estates — tens of millions of resources, ephemeral Kubernetes workloads, data-residency procurement — centralized graph ingestion eventually becomes too expensive, too slow, or contractually impossible. Federated/edge processing lets the customer hold raw graph state locally while SecurityV0 receives findings, posture summaries, evidence hashes, and selected projections. This is a primary enterprise path for the largest tier of customers, not a near-term replatform. It presupposes stable resource identity, durable event semantics, and a customer-side agent model that today's architecture does not yet have.

What this position is not​

  • Not "we have already solved graph scale." We have not. The backing paper documents four operational cliffs and the staircase past them.
  • Not a pivot to OpenFGA, SpiceDB, or Cedar as the core store. Those are relationship/tuple authorization engines optimized for "can subject X access object Y right now?" SecurityV0 is broader: stateful exposure, ownership decay, drift over time, source-system provenance, SIEM-grade evidence. Their tuple vocabulary is a useful interop/export model; their engines are not the core store.
  • Not a split into two products. One product category — NHI authority, exposure, ownership, evidence — with two operating modes: central SaaS for small-to-mid estates, dedicated/partitioned and ultimately federated for the largest.
  • Not a near-term replatform commitment. Step 0 (the contract change) is additive at the storage seam. The staircase past Step 0 is bounded and trigger-driven, not deadline-driven.

What we commit to do next​

  1. Promote AuthorityChain with ordered chain_steps as a first-class persisted entity. Bounded materialized authority_paths becomes a derived projection. This unblocks full-chain reasoning regardless of storage engine.
  2. Land the staircase Step 1 work documented in the backing paper: durable queue, async evidence aggregation, bounded evaluator reads.
  3. Re-promote federated/edge processing from its current orphaned appendix in the proposed-changes review into the primary enterprise architecture path, with a phased plan.
  4. Hold the staircase trigger thresholds documented in the sizing companion. Do not promote graph-read-model or per-tenant isolation work ahead of the operational triggers firing.

Bottom line​

The strongest answer is not that graph scale is solved. It is that the cliffs are understood, were independently surfaced by the architecture audit, were correctly elevated to a company-defining decision by the investor advisory call, and our answer is to commit to full-chain reasoning as the product architecture while keeping today's bounded precompute as the MVP implementation. The near-term action is chain-provenance contract change plus pipeline stabilization — not prematurely buying a graph database. The enterprise-scale path includes graph read models, partitioning, and federated/edge processing for the largest estates, on triggers.

References​