Building the Canonical Layer (What it looks like as a system)
Two weeks ago I wrote about why the output layer is commoditizing. Last week I described what a canonical layer is: the proprietary context inside your organization that AI can't get from public sources, and why it's the only competitive advantage left when everyone's running the same tools.
Fair warning: this will be more technical than the previous two posts. Not engineering-level technical, but specific enough that you'll leave with an architecture in your head rather than a framework to nod at.
The problem with how PMMs currently store knowledge
Before you can build a canonical layer, you need a clear picture of where your knowledge lives right now. For most PMM teams, it's scattered across a handful of places: a message house doc that's three versions out of date, a Notion wiki that was curated once and then abandoned, a Confluence page nobody can find, a Slack thread where someone summarized a win/loss debrief and it was brilliant for the 48 hours before it scrolled out of view. The knowledge exists. It just isn't structured in a way that's queryable.
That distinction matters more than it sounds. When you hand an AI a flat document, such as a positioning PDF, a message house in slide form, or a competitive brief, it reads it the way a person skimming it would. It pulls out phrases it recognizes, synthesizes them with everything else it knows, and produces something directionally related to what you gave it.
That on its own is not grounding. That's just input. And input that isn't structured gets blended with everything else the model already knows, which is exactly the public corpus we've been talking about for two weeks. Your message house doc doesn't override the model's priors. It competes with them.
A canonical layer is different. It is a structured graph of approved claims rather than a document repository, organized into domains, versioned, locked to specific owners, and queryable by type.
The difference between "we have a message house" and "we have a message house domain" is the difference between context and architecture.
What the architecture looks like
The canonical layer has three components. They build on each other.
1. Canon Domains
A domain is the top-level namespace for a category of knowledge. For PMM, the obvious one is a Message House, but you'd also want domains for competitive positioning, persona libraries, objection handlers, and product proof points.
Each domain has an owner. Not a team. A specific person with authority to approve, lock, and version entries inside that domain. This matters for governance reasons I'll come back to.
2. Canon Entries
Inside each domain, knowledge lives as atomic entries. Not paragraphs. Not sections. Singular, structured assertions.
A canon entry for a message house pillar looks something like this:
That's the unit: a single claim, with one owner, in one version. Locked against paraphrase.
When your AI generates a battlecard, it doesn't summarize your positioning doc and hope for the best. It traverses these entries directly, retrieves the locked claim, and cites it verbatim. The output is only as good as what's in the canon, and what's in the canon is controlled by a person with context and accountability, not a model making probabilistic guesses.
3. The Knowledge Graph
The entries don't just sit in a flat list. They're connected. A message house pillar connects to the personas it targets, which connect to their pain points, which connect to the objections they'll raise, which connect to the approved responses. Every relationship is an explicit edge in the graph.
This is the part that most knowledge management systems skip. They index documents. They don't model relationships. The graph matters because it's what allows an AI to answer a question like "what objection does a VP of HR Operations raise when evaluating us against a legacy HRIS, and what's the approved response?" by traversing a path through the graph, not by guessing from context.
How it connects to your AI tooling
Here's where the architecture pays off. The canonical layer connects to your AI tools via MCP, the Model Context Protocol, which is how AI systems expose external data sources as callable tools rather than static context. Once your canonical layer is registered as an MCP server, an AI assistant working on a deliverable can query it directly.
A session generating a competitive battlecard looks like this:
That last step is the one most teams skip. The alignment scorer catches claims the model generated that aren't grounded in the canon: statistics it inferred, product capabilities it embellished, category language it pulled from its training data. Before the battlecard ships, a human reviews the flags. What passes the audit is grounded. What doesn't gets corrected or removed.
The four-step loop of discover, retrieve, generate, and audit is what makes this different from generating content with a prompt and hoping it's accurate. The hope is gone. The contract is explicit.
The drift problem
Here is the governance angle most people miss when they start building this.
Your canonical layer isn't static. Products ship. Proof points change. Win/loss patterns shift. A claim that was accurate in Q1 may be wrong by Q3, but it's still sitting in your message house doc, still getting pulled into generated content, still being used by sales reps who have no idea it's outdated.
In a structured canonical layer, entries have explicit dependencies. A core value proposition entry in your message house connects to the proof points that support it, which connect to the customer references that validate them. When a proof point changes, because a customer churns or a stat gets updated or a capability ships, the system flags every downstream entry and artifact that depends on it.
That cascade is what a document repository can't do. A PDF doesn't know what depends on it. A canon entry does.
What it takes to build one
I'm not going to understate the work. Building a canonical layer takes time that looks unproductive by conventional PMM metrics. You're not making decks. You're not writing briefs. You're doing extraction work, pulling knowledge out of conversations, call recordings, Slack threads, win/loss interviews, and structuring it into atomic entries someone can audit.
The canonical layer I've been building and running in my own work took months to become useful. The technology is not hard to set up. The hard part is knowledge capture, not infrastructure. Getting a product manager to sit with you for two hours and articulate why the architecture works a certain way and what that unlocks competitively. Getting sales to log the objections they're hearing in every deal, not just close them and move on. Getting customer success to surface what's coming up in renewals before it becomes a churn signal.
That work doesn't produce an artifact. It builds the input layer that makes every subsequent artifact better than what your competitor is generating with the same tools.
Channel mapping, knowing that the sales deck version of a pillar should differ from the LinkedIn version because the context changes even though the claim does not, is another layer of structure most PMMs don't build intentionally.
This is what differentiation looks like now
Post 1 of this series was about the output layer commoditizing. Post 2 was about why proprietary context is the only thing left to differentiate on.
This is the answer to both. When everyone has access to the same generation tools, the competitive advantage is in what you feed those tools, not in how fast you can produce content. A canonical layer built from real customer language, real win/loss patterns, real field feedback, and real product context will produce output that diverges from the category average, because the input diverged first.
The screenshots in this post are from MsgStack, an open-source project I built as a public proof of concept for this architecture. It is not a product. It is a demonstration that the canonical layer can be built. The principles are the same ones I apply in my own work, where the internal version has grown to dozens of message houses connected to AI assistants across sales, marketing, and field teams. Different implementation. Same idea.
MsgStack exists because I wanted other PMMs to have something concrete to look at, a working system rather than a framework slide. Fork it, adapt it, ignore it and build your own. The architecture is the point, not the tool.
The canonical layer is a new responsibility for PMM more than a new category of software. The teams that build it will produce content that is faster and, more important, differentiated in a way volume alone can't replicate.
I'm speaking at the Product Marketing Alliance Seattle Summit on June 17th about what PMM is for when the output layer commoditizes. On June 18th I'm running a masterclass on building canonical layers in practice. If you're going to be there, come find me.
MsgStack is open source under Apache 2.0. msgstack.ai · GitHub
Discussion
Sign in to leave a comment
Uses your Google account — no password needed.