Playbooks — Insight With Legs

Run a brand for long enough and you accumulate a particular kind of document: the audit. The SEO audit. The retail scorecard. The brand tracker. The packaging review. Now the AI-visibility report, telling you how the answer engines describe your products. They arrive thick, color-coded, and expensive, and they share a failure mode so common you've probably stopped noticing it.

They stop at the verdict. Wrong. Critical. Red. All true — and all of it dies in the meeting where someone asks what we're doing about it.

That meeting happens constantly: the audit gets nodded at, the deck gets filed, and the finding that was worth the whole engagement gets exactly as much action as the ones that weren't. None, because turning a verdict into a task was left as an exercise for the customer.

When we built the part of Fama, our AI-visibility product, that writes the fixes, we wrote the opposite of that failure into the product as a constraint. There's a line in every set of instructions the product gives its writing engine: "The specific problem this block must fix:"

Not some of them. Every one. Every planned fix carries two required parts: the fix and the finding it fixes. In this product, content cannot be generated without a problem attached, because the machinery refuses to run without one.

What a finding with legs looks like

The shape, on a real brand, from a real run in our record.

Grok (one of the AI answer engines) thinks a clean-protein brand's core product is bone broth. It's beef isolate and egg white. Fama files the critical finding, verbatim: "Grok misidentifies the core protein source as bone broth when the DNA and other engines confirm it is beef isolate and egg protein."

That finding is the new category of problem AI search created for brands: a machine your buyers consult is confidently wrong about what you sell. Not unflattering. Wrong at the product-category level, in the answers.

Now, directly under that finding, because it is not allowed to appear alone, the product renders the fix: a paste-ready definition block written from the brand's verified brand record, opening with the true category. Then a placement note: "Place near the top of the relevant page, above the fold." And a button: "I shipped this."

Finding, fix, placement, ship. Four things, attached, in that order. That's the whole anatomy, and the reason it works is that each piece answers the question the previous piece raises. A finding raises "so what do we publish?" A fix raises "where?" A placement raises "did we actually do it?" A report that stops at any link in that chain hands the remaining questions to whoever's cheapest to hand them to — which is always the customer.

The finding picks the fix

One detail in that anatomy is easy to miss, and it's the part I'd steal first. The product doesn't decide what to write and then go looking for a problem to justify it. The finding decides the shape of the fix.

The selection logic reads like a lookup table, and you could pin it to a wall.

None of that is clever. That's the point. The mapping is fixed, it runs without AI in the loop, and a human can read every branch. When a fix shows up, you can trace it back to the exact finding that summoned it and the rule that chose its shape.

One more rule rides with it. Findings are worked highest severity first, so when a run hits its cap of eight blocks, the work it drops is the least important, and it tells you how many it left out rather than quietly showing you a shorter list. A visible "N more gaps not shown" is worth more than a deck that was trimmed to fit.

Two doors before you see the fix

The fix is generated, and generated text is where a product like this either earns trust or spends it. So the same block of instructions that carries the finding carries a wall: the brand's verified record, with the line "use ONLY facts from here — never invent." For a definition block, the first sentence is forced, "[brand] is a [category]…", using the true category, so the sentence that corrects the engine is the first sentence an engine will read. The instructions also ban hedging outright. No "might", no "could", no "perhaps". An engine doesn't cite a paragraph that isn't sure of itself.

Then every generated block passes two checks before it's shown to anyone, and neither check uses AI.

We kept both checks as plain rules on purpose. A rule-based verdict is explainable: the card can tell you which banned word tripped it. A model grading another model's output gives you a number and a shrug. When the fix is going to sit on your site under your brand name, explainable is the higher bar. Most brands have a banned-word list somewhere (a compliance doc, a legal memo, a note from the founder); make it a hard stop in your content process rather than a suggestion.

Where it goes is part of the fix

Placement sounds like a footnote until you watch a good block die on the wrong page. So each block carries its own deployment line. The definition block: near the top of the relevant page, above the fold. The FAQ block: on your FAQ page, wrapped in the structured-data markup engines read as an FAQ. The self-contained answer: it leads the page, answer first, above the fold. A statistic: embedded inline, with its source marked as a citation. Steps: a numbered list on a how-to page. An authoritative claim: on your About page.

The pattern under the hints is that an answer engine lifts from where it expects to find things. A definition buried in paragraph six of a brand-story page is technically published and functionally invisible. "Above the fold" is there so the machine that got you wrong can find the correction.

The button is where the honesty lives

That "I shipped this" button is doing more work than it looks like.

Clicking it is what starts measurement. In the product's own rulebook, it "never measures an unpublished fix." The follow-up (did the engines' answers actually move after this fix went live?) doesn't begin until you assert the fix is really on your site.

This matters because of a temptation on the vendor side that you, as a buyer, should know about. A tool that starts measuring the moment it *generates* a fix gets to harvest credit for everything that happens afterward, shipped or not. Engines drift on their own. Answers move for a hundred reasons. If the measurement clock starts at generation, every uptick becomes evidence the tool is working. Anchoring measurement to the customer's own "I shipped this" is the machine declining to grade its own homework on problems it never turned in.

What the click actually records is small and specific. It stamps the date, captures where you stand now on the queries that finding touches (the baseline), and takes an optional page address so the follow-up can attribute movement to the page you changed. Then it waits. Engines have to re-read the page before anything can move, and the product says plainly that this typically takes two to four weeks. The lift, when it comes, is computed run over run, audit against audit. Movement is measured, not asserted, and it's measured from a date you chose.

The Monday-morning test

The takeaway is a test you can run on every audit-shaped thing you buy, and every one your own team produces.

Open the report and pick its scariest finding. Then look for four things.

Four yeses and you bought insight with legs. Anything less and you bought a verdict, and the expensive translation into action, the part that was the point, is still your job, unbudgeted.

The same test works internally. If your team runs a quarterly brand audit, add the constraint we wrote into our product: no finding enters the deck without its fix attached, drafted, with a name and a date on the shipping. You'll produce shorter decks. The findings that survive will be the ones somebody was willing to do something about, which is a decent definition of the findings that mattered. Findings are cheap. Findings with legs — the fix drafted, the placement named, the follow-up measured — are the product.

Questions people ask