Why Named Frameworks Win AI Answers

Interchangeable claims, interchangeable answers

Open five competitor websites in your industry and read the homepages back to back. Quality workmanship. Family owned. Locally trusted. Fully licensed and insured. Free estimates. Satisfaction guaranteed.

Every one of those claims is probably true. Not one of them distinguishes anybody.

Now think about what an AI engine does with that. Asked who the best provider is, it has five sources saying materially identical things. It has no basis for preferring one, so it does what any reasonable system does with undifferentiated inputs: it describes the category, names whoever has the strongest signals elsewhere, and moves on.

This is Signal 7 of the 8 Signals, worth 10 of 100 points. It's not the biggest category, but it's the one with the most leverage per hour of work — because a proprietary asset doesn't just improve your position, it creates a question only you can be the answer to.

What actually counts as a proprietary asset

Three things qualify, and most businesses have raw material for at least one.

A named methodology. The way you do the work, given a name and written down as steps. Not a slogan — a process with parts. If you have a sequence you follow on every job that competitors don't, that's a methodology whether or not you've ever called it one.

A scored or structured framework. A methodology becomes considerably more citable when it has structure an engine can reproduce: a number of components, weights, tiers, a scoring system. Structure makes it quotable, and quotable is what gets you named.

Original data. Numbers that come from your own work and exist nowhere else. Aggregate findings across your projects, results you can substantiate, patterns you've observed enough times to state. This is the most under-used of the three, and the easiest to start.

The test: could a competitor say this?

Take any claim on your website and ask whether a competitor could put the identical sentence on theirs without lying.

If yes, it's table stakes. Keep it if it's useful for human readers, but understand it's earning you nothing in an AI answer.

If no — if the sentence is only true of you, and it's specific enough to check — that's an asset. Those are the sentences worth building pages around.

A worked example: the Advantage 5

Advantage Roofing in Cincinnati makes five specific commitments to every customer. They'd been making them for years. They were real, they were unusual, and they were the reason customers stayed loyal.

They also had no name and no page.

We named the set the Advantage 5, built a hub page defining all five, and wrote a dedicated page for each one going deep on what that promise means and what it costs them to keep. Everything interlinked, each with its own FAQ and schema.

Within about an hour of pushing it live, the AI answers changed. Asked who had the best roof warranty in Cincinnati, the engines named Advantage Roofing first — ahead of two competitors who had been coming up first before.

Nothing about the business changed that day. The five promises had existed for years. What changed is that they became a named, defined, published thing an engine could point at. You can go look at the Advantage 5 and see the structure.

A second worked example: this page

It would be strange to argue for named frameworks without pointing out that you're standing inside one.

The 8 Signals is our framework. Eight named categories, fixed point values totalling 100, four defined tiers. There's a hub page defining the whole thing and a page per signal going deep — the same structure we built for the roofing client, applied to ourselves.

The reason it's built this way isn't only that it's useful to explain. It's that "what are the 8 Signals" is a question with exactly one correct source. No competitor can outrank us on it, because the answer is ours by definition. Every business has some version of this available, and almost none of them use it.

Two things make it work rather than just sound clever. It's defined — there's a single paragraph on the hub page naming all eight with their weights, written to be quoted whole. And it's structured — the numbers add to 100, the tiers have ranges, the parts have names. An engine can reproduce it accurately, which is what makes it safe to cite.

Original data is an asset too

You don't have to name anything to own something. Numbers from your own work are proprietary by nature.

When I write that I've run more than thirty AI visibility reviews and that the most common finding is proof living in someone's head rather than on their website, that's not an opinion or a repackaged industry statistic. It's an observation from a body of work only I have. A competitor can disagree with it, but they can't have made it.

Most businesses are sitting on this without noticing. How often does a particular problem turn up in the jobs you inspect? What percentage of the estimates you write include something the customer didn't know they needed? How long does the thing actually take, measured across your last fifty projects?

Start counting something. In a year you'll have a statistic nobody else can cite, and the kind of proof that also strengthens Signal 1.

Telling machines the term belongs to you

Once a framework is named and defined, structured data can state the relationship explicitly. DefinedTermSet and DefinedTerm markup let you declare that these terms form a named set, that the set has a creator, and that the creator is you.

That's what the hub page for this framework carries: one DefinedTermSet for the 8 Signals, with eight DefinedTerm entries inside it, each with its name, its point value, and its definition. It's the same information a reader sees, stated in a form a machine doesn't have to interpret.

The mechanics of adding it are covered in Signal 6. The rule from that post applies here too: the markup has to match what's visible on the page.

When naming things goes wrong

There's a failure mode here, and I'd rather name it than pretend this advice is risk-free.

Naming something that doesn't deserve a name makes you sound like a brochure. If your "5-Step Precision Process" is just what everyone in your trade does, with capital letters applied, you've added jargon without adding substance — and you've created a barrier for a buyer who has to decode your vocabulary before understanding what you sell.

This is the tension with entity clarity, which argues for plain language. The resolution: a proprietary name works when it's defined on a page and sits alongside the plain-language description, and fails when it replaces it. Say what you do in ordinary words first. Then name the thing that's genuinely yours.

The honest test is whether the framework changes what someone understands about your business. If removing the name would lose nothing, it wasn't an asset.

What I don't know yet

I don't know how long it takes for a named framework to become associated with a business in a model's understanding, or whether that association survives across model updates.

I don't know whether there's a saturation point — whether this stops working once every business in a category has invented a framework. I'd expect the ones grounded in something real to survive that and the invented ones to wash out, but that's a prediction.

What's held: businesses with a defined, published, structured thing of their own get named more specifically than businesses without one. I'll update this as the rest gets clearer.

Frequently asked questions

Related reading

• The 8 Signals — the framework this post is an example of, defined in full.
• The Proof AI Is Looking For — Signal 1, and where original data does double duty.
• Entity Clarity: How AI Decides Who You Are — Signal 2, and the plain-language counterweight to naming things.
• Why Thin Coverage Keeps You Out of AI Answers — Signal 3, and how hub-and-spoke gives a framework its structure.
• Advantage Roofing case study — the full version of the Advantage 5 story.

This is Signal 7 of 8. See the full framework →