The Engineering Graph
October 4, 2026 · Prasanna Gopinath, Founder & CEO · 2 min read
Why the concept exists
Engineering information is fragmented. Requirements live in one system. Architecture in another. Code in repositories. Incidents in operational tools. Decisions in documents and messages.
The Engineering Graph exists to represent the relationships among these elements.
The problem
Search can find documents. It does not always explain relationships.
An engineer may find a standard without knowing: which systems it applies to; which decision created it; which exception exists; which incident changed it; which team owns it; whether it is current.
The engineering problem is relational.
The current view
The market uses terms such as: code graph; knowledge graph; dependency graph; software catalog; metadata platform.
Each captures part of the system. The Engineering Graph is broader in intent. It connects engineering meaning across lifecycle stages.
The deeper model
- REQUIREMENTS
- ARCHITECTURE
- CODE AND DEPENDENCIES
- DECISIONS AND STANDARDS
- PEOPLE AND OWNERSHIP
- ENVIRONMENTS AND OPERATIONS
- HISTORY AND OUTCOMES
Full definition
The Engineering Graph is a governed, connected representation that allows people and AI systems to discover: what an asset is; why it exists; what it depends on; which decisions govern it; who owns it; which policies apply; what changed; what happened in production; which knowledge is current.
What it is not
The Engineering Graph is not: only a code graph; only a knowledge graph; automatically complete; a guarantee of truth; unrestricted company memory; a replacement for source systems.
An enterprise example
A team changes an API used by several products. The Engineering Graph should help identify: dependent services; owning teams; affected requirements; architecture decisions; customer commitments; tests; incidents involving the interface; deployment environments.
The value lies in the relationships.
Where it fails
The graph fails when: relationships are inferred incorrectly; sources are stale; ownership is missing; permissions are too broad; ingestion becomes the objective; graph complexity overwhelms users; confidence and provenance are hidden; no workflow uses the graph.
What a serious critic would say
Maintaining the graph is too expensive. It may be. The graph should begin with high-value relationships and automate ingestion where reliable.
Existing tools already contain the data. Yes. The problem is often the absence of connected meaning across them.
Where to begin
Begin with one workflow: architecture change; incident review; dependency update; product requirement; security review. Define the relationships required to improve that workflow.
Where Cortex stands
A delivery platform needs connected context, and Cortex is built on that principle: plans, validation contracts, decisions and what the platform learns about your codebase are kept as connected, first-class records rather than scattered chat history — so every Mission starts with the relationships that give the work its meaning. How Missions use that context →
Want this applied to your own build?
Start with a free Agent Readiness Assessment — a concrete read on whether your codebase is ready for AI-assisted delivery, and where the leverage and risk are.