The one-model thesis

The thesis in one line: an AI-native organization runs on one typed property graph - a labeled property graph (LPG) - with a single identity rule and a single change rule, materialized into a few derived read shapes and served behind one query layer that is MCP-native. Cogitave's own Core is one such graph; this unit uses it as the worked example, and its architecture doc states the same thesis for that instance. Everything below is what the one-line thesis cashes out to - and what you would decide when you model your own estate this way.

Nodes, edges, and one flat namespace

A canonical model needs a closed, typed vocabulary: a fixed set of node types and a fixed set of edge types. A closed set is what keeps traversal queries, faceting, and certification evidence stable as the org grows - new content is new nodes, not new schemas. Cogitave's Core, for instance, has 18 node types - Org, Repo, Product, Service, Doc, Unit, Module, LearningPath, ADR, Agent, Skill, Standard, InfraResource, Decision, Team, Person, and more - and a closed set of 11 edge types, among them partOf (composition), dependsOn, xref, appliesTo, teachesSkill, and derivedFrom. You are reading one node of that graph right now: this Unit is partOf this Module, exactly as the schema describes.

Two identifiers, two jobs

Separate identity from version:

• An immutable uid - a dotted name (<org>.<area>.<name>) that is globally unique across the whole multi-org estate. One flat namespace means a UID names exactly one node everywhere, so an edge or an @uid reference resolves the same way regardless of which org issued it. The URL may change; the UID never does. (Cogitave's own UIDs read cogitave.<area>.<name>.)
• A content-addressed contentHash - a digest of the canonicalized node payload. Two materializations with the same hash are byte-identical and stored once: the same Merkle-DAG discipline Git and IPFS use for their object models.

Identity carries no PII: a Person node holds only a non-PII handle and coarse role labels, with any personal data in a separate, access-controlled store keyed by the same UID.

Derived reads, one source of truth

The graph is the source of truth; reads are served from derived, rebuildable indexes - typically a catalog (UID-keyed flat records), a graph store (typed adjacency for traversal), and a search index (lexical + vector). Each is a pure function of the graph at a given content root, so any of them can be rebuilt independently without touching the source.

Why this is "one model," not three

Because the estate itself - orgs, teams, services, infra, standards, controls, observability signals - is nodes and edges in this same graph, a rule like "if code changes, docs are mandatory" becomes a graph-level invariant rather than a CI afterthought: a Repo node changing without a connected Doc or Decision node is something the graph itself can flag, not just a check bolted on top of it. That is the payoff of modeling a whole organization as one graph - and the reason to reach for a single canonical model before you have five disconnected stores to reconcile.