Day 119: Auditing My Own Marketing for Lies
For fourteen days I’ve been writing about marketing in public, and the whole time a small unease sat behind it: I check the code against production constantly, but I had never once checked the marketing against the code. Today I did. I pointed the same scrutiny at the website that I point at the runtime, and it did not come out clean. A site-wide audit, cross-checked claim by claim against what’s actually shipped, found 56 truth violations. Fifty-six places where the site said something the product doesn’t do.
That’s not a typo or a rounding error. That’s a company that sells governance discovering it had been ungoverned about itself.
The 56
They weren’t lies in the sense of someone sitting down to deceive. They were the more ordinary kind: drift, optimism, copy written ahead of code and never reconciled when the code went a different way. But the reader doesn’t get to see my intent. They see a claim, and the claim is either true or it isn’t.
Some examples, all real. Pages advertised Slack and Teams as channels. We don’t have Slack or Teams. Pinchy speaks web and Telegram, full stop. Pricing copy implied per-seat billing; Pro is a flat rate. An “approval gate” was described as a platform feature, as though there were a switch somewhere, but approval in Pinchy is really the per-agent allow-list plus draft-only conventions, an architecture, not a button. And the Odoo pages implied scheduled, hands-off automation that simply isn’t shipped; what’s shipped is on-request. Every one of those is a reader forming a mental model of the product that the product would then fail to honour. Website PR #24 fixed all 56.
Fixing the visible copy turned out to be the easy half. The structured data was worse.
The JSON that answer engines quote
Modern marketing pages carry a hidden layer: FAQPage structured data, the machine-readable JSON that answer engines lift and quote verbatim when someone asks them about you. The problem with a hidden layer is that you fix the visible text and forget it exists. That’s exactly what had happened. The FAQPage JSON had drifted from the corrected visible copy and still carried the old false claims on 8 pages, meaning an AI assistant asked about Pinchy would have confidently repeated the very statements I’d just spent a PR removing. PR #26 reconciled the structured data with the truth on the page.
There’s a grim joke in there. We build governed AI agents, and the most durable copy of our own overclaims was sitting in the one format designed to be read back by AI agents.
The one that stung
And then the one I keep coming back to. On our own OpenClaw security page (the page where we explain why exposed deployments are a risk and why self-hosting with real audit and permissions matters), we had written that 63% of exposed deployments were vulnerable. The primary source says 35.4%. We had nearly doubled it.
I don’t know how the 63 got there. It doesn’t matter. What matters is what it is: a confident, authoritative-sounding, wrong number, sitting on a security page, where it does the most damage to trust precisely because the surrounding context is otherwise careful. PR #28 corrected the figure to 35.4% and added the source links so a reader can check me, which is what should have been there from the first draft.
That number is the exact failure mode we warn customers about. The entire pitch for permissions, allow-lists, and a tamper-evident audit trail is that an agent will, sooner or later, state something false with total confidence, and you need the architecture to catch it before it acts. I had written a page about that danger and then committed the danger on the same page. The medium was the message, and I’d failed the message.
The rest of the cleanup
The audit pulled a few more threads. We’d been quietly funnelling developers toward a sales call from every call-to-action, which is precisely wrong for a self-hosted AGPL tool you can just run. #29 added a self-serve path to every CTA so the obvious next step is “go try it,” not “book a meeting.” On the code side, the same honesty sweep landed three fixes: #511 for a tab-refocus crash, #513 deleting dead-code modules that no longer did anything, and #516 correcting truth across 12 documentation pages, because docs are product surface too, and the agent reads them.
The honest meta-note: a lot of this audit ran with AI assistance. I had an agent cross-check every marketing claim against the actual code, page by page, and surface the mismatches. There’s something fitting about that: a company that builds governed AI agents using one to find its own overclaims. The agent had no investment in the copy being true. It just diffed what we said against what we’d built, which is the whole job.
Day 119
This closes the fourteen-day marketing stretch, and it closes it on the note the rest of it was circling. The 56 violations weren’t on pages I distrusted. They were on the pages I was proud of, the security page most of all. The most dangerous claims aren’t the ones you’re worried about; they’re the ones you’ve already congratulated yourself for.
“I built it” and “it works in production” are different claims. So are “I wrote it” and “it’s true.” For four months I’ve held the code to the first distinction and never once held the marketing to the second. The uncomfortable symmetry is that a governance company has to govern its own voice, or the governance is just another claim on a page. And now I know which page would have caught it.