Build on a single canonical model
Learn the one-model architecture that lets humans and agents read a whole organization the same way: one typed property graph that documentation, governance, infrastructure, and agents all project into, a single query layer over it, and an MCP-native interface. By the end you'll be able to model your own estate as one graph rather than a rack of disconnected stores. Cogitave's own Core is the worked reference example throughout.
Modules4
Duration99 min
Levelintermediate
Prerequisites
- Basic familiarity with graph data models and APIs.
- Completion of the "Onboard to an AI-native codebase" path is recommended.
Modules in this path
- The one-model architecture Explain why an AI-native organization runs on one canonical property graph that humans and agents both query, what its node/edge model and identity scheme look like, and why a labeled property graph is the right substrate. Cogitave's Core is the concrete example.
- Query your canonical model Learn how a query layer resolves a request against one canonical graph - lexical BM25 and dense HNSW vectors fused by Reciprocal Rank Fusion, a graph-aware rerank and ranking signals, and a bounded, read-only profile agents call directly. Cogitave Query is the reference implementation you'll trace.
- A native MCP interface to the canonical model Read a canonical model's native MCP interface as the source of truth for how humans and agents query one org's estate - why the surface is native rather than adapted, the protocol contract it commits to, and the tools and resources you call. Cogitave's Core is the worked example.
- Project products into the canonical model See how content projects into one canonical model as typed, content-addressed nodes rather than separate silos - Cogitave's Core is the worked example - and how the fact registry's cite-not-restate rule and fact-drift scanner keep one owner per fact across your estate.
Related
- Patterns and golden paths Learn to build reuse-first: discover before you generate, start from a patterns catalog, inherit a repository's complete ruleset through the project baseline, and use decision guides for database, infrastructure, and model selection. By the end you'll reach for the named artifact before writing anything new. Cogitave's own patterns catalog is the worked example throughout.
- Design and version an API Shape a clean, consistent API against a clear API design standard - resources, standard methods, typed errors, cursor pagination, idempotency - then version and deprecate it under a versioning policy so no consumer is ever broken without consent.
- Apply the naming standards Name a new identifier, file, repo, or branch the way an AI-native org does - keyword-first, no redundant prefix, cased by role - and tell a functional keyword apart from a product codename, so your first artifact passes the naming gate by default.