How the knowledge graph actually works (and why it matters)

Nodes for brand, audience, products, voice (connected, not pile-of-docs)

When we talk about T-Matic AI’s “knowledge graph” we get one of two reactions. People who’ve built RAG systems nod and move on. Everyone else assumes it’s marketing language for “we read your website.” Both are wrong, and the difference matters because the knowledge graph is the thing that makes the output not sound like generic AI content.

This post walks through what’s actually under the hood, the shape of the data, what we put into it, and how it gets used the moment a draft is being generated.

Why a longer prompt isn’t the answer

The naive version of “AI that knows your brand” is: write a long system prompt that contains your voice rules, your audience, your products. Stuff it in front of every generation. People do this; it kind of works for a while; then it falls apart.

It falls apart because:

• A long static prompt is a flat list. The model can see it, but can’t tell which parts apply to this piece of content.
• It bloats fast. Once you’ve added voice, audience, positioning, three product lines, a list of competitors, banned phrases, and recent campaigns, the prompt is 8,000 tokens and the model is paying attention to half of it.
• It can’t reference itself. “Like the post we wrote on X last month” is something a human marketer says all the time. A static prompt can’t pull that thread.

The fix isn’t a bigger prompt. It’s a structured store the system queries selectively, the same way a writer pulls only the relevant tab on their desk for a given piece.

What the graph actually stores

We model your brand as a graph of typed entities and relationships. The shape, simplified:

• Brand nodes, voice rules, tone descriptors, positioning statements, banned and approved phrases, do/don’t examples paired with explanations.
• Audience nodes, named ICPs, with the language they use, the objections they raise, the metrics they care about.
• Product nodes, what each product is, who it’s for, the language we describe it in (and the language we don’t).
• Asset nodes, every post, page, email, and campaign you’ve shipped, with metadata on what it was about and how it performed.
• Relationship edges, “this audience cares about this product feature,” “this campaign proved this positioning,” “this voice rule was added because of this past mistake.”

Two properties matter more than the list:

Each node has provenance. A voice rule isn’t just a sentence, it’s a sentence plus a reason (“we don’t say seamless because three customers told us it sounds like marketing fluff”). At draft time the system surfaces the rule with its reason, which is what stops it from being interpreted by the wrong angle.

The graph is queryable, not concatenated. When a draft is generated, we run a query against the graph for just the nodes relevant to this brief, this audience, this product, the last 12 posts on adjacent topics, and feed only those into the model. That’s why the same pipeline can produce a tight LinkedIn post in your founder’s voice in one query and a deep technical blog post for a different ICP in the next.

How a draft actually gets generated

Here’s the flow on a typical request, say, “draft a LinkedIn post about our latest case study, aimed at heads of marketing at mid-market SaaS.”

1. Brief expansion. The brief is parsed into structured fields: channel, audience, format, topic, source material. Anything ambiguous gets resolved against defaults from the brand.
2. Graph query. We pull: the audience node (head of marketing at mid-market SaaS), the relevant product/feature nodes, voice rules tagged for LinkedIn, the last 5 posts that hit the same ICP, and any banned phrases active for that channel.
3. Context assembly. Those nodes get serialized into a focused context, typically 1,500–3,000 tokens, not 8,000. The model sees the rules that apply, with their reasons, plus the relevant precedent.
4. Generation. The draft is produced. The model has enough constraint to stay on voice and enough room to actually write.
5. Validation pass. The draft is checked against banned-phrase rules and hard constraints (claim limits, regulated language, audience-appropriate framing).
6. Memory update. Once the post is approved or shipped, it becomes a new asset node in the graph, language, framing, performance data, and is available as precedent next time.

The interesting part is step 6. A static prompt is the same on day one and day 365. The graph gets richer every week you use it, which means the next draft has more relevant precedent than the last one did.

What this fixes that prompts can’t

Three things, concretely.

Voice consistency at scale. When you have 12 different writers (or one model across 200 pieces), drift is the default. The graph is the canonical source of truth, every draft is grounded in the same voice rules, with the same reasons attached.

Cross-asset memory. “We already covered that angle in last month’s newsletter” is a thing the system actually knows, because the prior asset is in the graph. You stop publishing accidental near-duplicates. You start building a cumulative point of view.

Senior-on-junior rework collapse. The reason senior people end up rewriting drafts isn’t usually grammar, it’s that the draft missed a piece of brand context the senior had in their head. When that context is in the graph instead of in someone’s head, the draft starts much closer to the line, and the senior’s edit goes from “rewrite half of it” to “tighten and ship.”

Where this goes next

The version of the graph we ship today already does the things above. The version we’re working toward includes two more capabilities:

• Inferred edges. The system noticing on its own that every post that did well with this audience used a specific framing, and surfacing that framing automatically on future drafts to that audience.
• Contradiction detection. The system flagging when a new draft makes a claim that contradicts an existing brand statement or a published asset, before it ships.

Both are the same idea: a brand memory that earns its keep by getting smarter as you use it, instead of getting staler.

---

If you want to see what writing on top of a real knowledge graph looks like (your voice, your audience, your prior work, queried per draft). that’s exactly what T-Matic AI does. Try it free at app.tmatic.ai.