Field guide · Reviewed August 16, 2026
What is a product graph?
A product graph is a connected model of the customer evidence, product decisions, specifications, delivery work, and learning behind a product. It lets a person or AI builder inspect why work exists—not only where its files and tickets live.
The missing relationship
Most teams have the nodes. They lose the edges.
Customer calls, research, roadmap records, specifications, issues, pull requests, and releases already describe parts of a product. A folder or search index can find those records. It cannot reliably explain which evidence changed a decision, which constraint survived review, or which release should change the next bet.
A product graph preserves those relationships. Provenance matters as much as connectivity: an agent should be able to reach the source, identify the decision owner and review state, and distinguish an approved constraint from an unreviewed suggestion.
The graph is useful when it supports a decision or handoff. It is not valuable merely because more records have been connected.
A product-development graph
Connect the reason to the result.
This model is not a mandatory workflow. It names the records and relationships needed to inspect product intent across discovery, planning, building, and learning.
- 01
Source
The call, ticket, research note, usage event, or document that preserves what happened.
- 02
Signal
A relevant observation kept with its source and account context.
- 03
Insight
An interpreted finding that remains traceable to supporting evidence.
- 04
Opportunity
A recurring customer problem or unmet outcome worth evaluating.
- 05
Decision
The chosen bet, alternatives, trade-offs, owner, and approval state.
- 06
Initiative
The committed scope, constraints, non-goals, acceptance checks, and delivery plan.
- 07
Delivery
The issue, pull request, release, or agent action that implements the decision.
- 08
Learning
The customer response and product result that changes the next decision.
Questions the graph should answer
Query the product intent, not only the archive.
- Why does this feature exist?
- Follow the feature or initiative back to the decision, opportunity, insight, and original customer evidence.
- What supports this product bet?
- Inspect supporting and contradicting evidence, affected accounts, decision owner, and review state.
- What may an AI builder change?
- Retrieve approved scope, constraints, non-goals, acceptance checks, and the sources behind them.
- What changed after release?
- Connect shipped work to usage, support, research, and the decision that should now be kept, revised, or reversed.
Term boundaries
“Product graph” has more than one meaning.
This guide uses product graph to mean the graph behind product development and product decisions. These boundaries prevent a shared term from hiding different jobs.
- Product catalog graph
- Connects products, variants, attributes, offers, and customer behavior for commerce or recommendations. A product-development graph connects the evidence and decisions behind software work.
- Software dependency graph
- Connects code, services, packages, and runtime dependencies. It explains how software is assembled, but usually not why a product choice was made.
- Knowledge graph
- Models entities and relationships for a broad domain. A product graph is a purpose-specific graph whose relationships support product decisions, delivery, and learning.
- Product context layer
- Operates the graph across people and tools by adding permissions, ownership, review state, freshness, retrieval, and write-back rules.
- Agent harness
- Controls how an agent runs: instructions, tools, state, checks, and feedback loops. The harness can consume reviewed product context from the graph.
For AI builders
Repository context explains the code. Product context explains the choice.
An AI coding agent can inspect implementation patterns, dependencies, and tests in a repository. The product graph supplies facts that often live elsewhere: affected customers, rejected alternatives, approved constraints, unresolved questions, and evidence behind the request.
The safest handoff is bounded. Retrieve the smallest reviewed context set needed for the task, preserve links to its sources, and keep consequential product decisions with people.
Minimum operating contract
Connections need receipts.
- Source and provenance
- Owner and approval state
- Freshness and review date
- Permission boundary
- Supporting and contradicting evidence
- Downstream delivery and learning
Use the graph
Give the next builder the reviewed reason.
Zentrik connects source evidence, insights, opportunities, decisions, initiatives, delivery records, and learning. Teams review the product choice. MCP and connected workflows carry the relevant context into Codex, Claude Code, Cursor, Jira, GitHub, and other tools.
Sources
How this definition was formed.
Reviewed August 16, 2026. The definition is Zentrik's synthesis of current product-graph, requirements, protocol, and product-context perspectives.
- Unified Product Graph
An open schema effort for connecting product information across work systems.
- Model Context Protocol specification
The protocol boundary through which an agent can receive context or use tools.
- Jama Software: Product Context Layer
A requirements and traceability perspective on product context for AI-assisted development.
- Zentrik: Product Context Layer field guide
The operating layer around a product graph, including review, permissions, freshness, and delivery rules.
Questions
Product graph FAQ
- What is a product graph?
- A product graph is a connected model of the customer evidence, product insights, opportunities, decisions, specifications, delivery work, and learning behind a product. Its relationships let people and AI builders inspect why work exists and what evidence or constraints apply.
- How is a product graph different from a knowledge graph?
- A knowledge graph can describe any domain. A product graph is purpose-specific: its entities and relationships are designed to preserve product intent from customer evidence through decisions, delivery, and learning.
- What is the difference between a product graph and a product context layer?
- The product graph records product entities and their relationships. The product context layer makes those relationships safe and useful across people and AI tools by adding permissions, ownership, review state, freshness, retrieval, and write-back rules.
- Why do AI coding agents need a product graph?
- Repository context can show how software works, but it often cannot show which customer evidence supports a change, who approved the decision, or which trade-offs and non-goals apply. A reviewed product graph supplies that missing product intent.