We pointed Muttr at our own site.

We tell clients to demand four things from any audit: every finding traces to a root cause, every finding is implementation-ready, every finding is anchored to revenue, and the whole thing arrives as one ranked plan instead of a folder of PDFs.

So when it came time to harden our own site, there was only one honest move: point our own tools — Muttr, Canary, and Delphi — at weknowthewhy.com and hold the output to our own standard.

Then we did the part most companies skip. We didn't just read the report. We remediated it, finding by finding, with an AI assistant doing a lot of the hands-on work — monitoring it closely so we could validate the output. What we learned is worth more than a clean bill of health, so we're publishing all of it.

What the audit was actually worth

The value of the audit is real.

The first pass flagged roughly eighty issues. Triaged against the actual code, about a dozen were genuine, and they were the kind of mistakes that could be expensive to miss. Here's what Muttr found:

• Visitor IP addresses were reaching Google's font CDN before anyone consented — a GDPR exposure hiding in a <link> tag. We self-hosted every font and closed it.
• Google Tag Manager loaded before the consent banner could be answered. We gated it behind Accept, so nothing non-essential fires until a visitor opts in.
• The site served no security headers and no Content Security Policy. We built a per-request, nonce-based CSP.
• A dozen concrete accessibility defects: tap targets under the 48px minimum, a heading-order skip repeated across seven pages, links signalled by color alone, no reduced-motion handling. All fixed.

None of those were glamorous, and none of them announced themselves.

That's the point of running an audit at all: a good one finds the specific, unglamorous things that are actually wrong and hands you a ranked plan to fix them. Ours did. That dozen shipped.

Then the report lied to us

The other findings were noise. Not malicious, not random — a specific, nameable kind of wrong. The root cause has a name, and it's the same one that governs every bad finding we've ever seen.

Grounding is the discipline of re-checking the specific thing in front of you instead of reasoning from a generic template of what a thing like it usually looks like. It sounds obvious. It's the first thing to go under time pressure, and it's where almost every bad finding is born.

Here's what ungrounded looked like, from our own audit:

• The tool reported a 2.56 MB JavaScript bundle, ~475 KB of it unused, and attributed the weight to our “cart, product configurators, checkout, and filter/sort systems.” We have none of those. This is a static marketing site whose entire shipped JavaScript is a single 28 KB component. The tool wasn't measuring our site — it was describing a generic e-commerce template and stapling our URL to the top.
• A finding whose own internal name ended in -unverifiable was filed under “Confirmed.” The confidence label was tracking where the finding came from, not whether anyone had checked it.
• Fix snippets arrived written for the wrong platform — WordPress template language for a site built on Astro — because the tool free-associated the stack from prose hints instead of reading the actual package.json.

None of these are stupid. They're what you get when a system reasons from the average case instead of the case in front of it. A confident severity rating and two hundred pages of color-coded findings can sit on top of a claim that was never grounded in the real target, and nothing in the formatting tells you which is which.

The AI working on the site did the same thing

Mid-remediation, the assistant added a small dependency, saw the package manager report a handful of security advisories, and wrote in its summary that the vulnerabilities “came from the new dependency's tree.”

It hadn't checked. One command — npm ls — showed the opposite: the package we'd just added has zero nested dependencies, and every one of those advisories was pre-existing, sitting in the core framework toolchain the whole time. The assistant had reasoned from the obvious template — the new thing I just added must be the source of the new warning — instead of grounding the claim against the actual dependency graph.

It was caught because a human stopped and said “run the audit and let's verify” before the claim went anywhere. The fix was the same one command that should have run in the first place.

This is a known issue with AI-based tools. In an effort to be fast and save tokens, models make assumptions whenever possible and only check the data when they're forced to. We have a lot of forced grounding in our systems already, but you always surface new edge cases once the tool runs under real load.

We're leaving that in on purpose. An AI that helps fix an audit committing, in miniature, the exact failure the audit tool is criticized for isn't an embarrassing footnote. It's the proof that grounding is a property of the work, not of the worker. Tools do it. People do it. AIs do it. The only defense is structural.

What actually kept us honest

Four habits did the load-bearing work, and none of them are clever:

1. A human as the ground-truth interrupt. The single highest-leverage move wasn't writing code — it was someone pausing to say “verify that before you write it down.” These grounding errors don't survive a request to verify, because it forces the AI to look at the actual code.
2. Verification you can falsify. “The link checker passes” is not evidence. Feeding it a deliberately broken link and confirming it fails is. “Search works” is not evidence. Pulling a real entry out of the built search index and watching the query resolve is. If a check can't fail, it isn't a check.
3. Scope honesty. The audit proposed a tidy three-tier pricing grid we could drop onto the site. We deleted it — publishing tiers we don't sell would have described a business that doesn't exist, which was, ironically, the audit's own stated number-one risk.
4. The value was in the no's as much as the yeses. Eighty findings in; a dozen real fixes out. The rest were stale, false, or passing checks dressed up as problems. Most of the work — and most of the trust — was in the triage.

≈80 raw findings → deduped to 39 distinct items → sorted:

Real fixes shipped 12

Additive optional enhancements 7

Netlify config 3

Tag-manager console 1

Stale · false · passing no-op 16

Twelve were real defects worth shipping. Sixteen were non-issues. Separating them — proving each against the actual site — is the audit.

We fixed the tool, then re-ran it, and the same mistakes didn't come back

Every ungrounded finding we caught, we logged against the tool itself. Then we shipped the fixes — grounding the payload measurement so it reads the real bundle, grounding the code snippets so they match the actual stack, teaching the confidence label to track verification instead of origin, and adding a repo-grounding pass that reads the source before it reasons about it.

Then we re-audited weknowthewhy.com. The trajectory is the proof:

• The phantom 2.56 MB bundle was gone. This time, Muttr measured the JavaScript correctly. Its one performance finding was real and precise.
• The wrong-stack fix snippets were gone. No more WordPress advice for an Astro site.
• The report got shorter and cleaner — fewer findings, and the tool now quarantines its own malformed and ungrounded output before it ever reaches you.
• The real fixes held. The privacy, security, and accessibility work from round one didn't reappear — because it was actually fixed, and the tool was now grounded enough to confirm it.

The second audit wasn't perfect, and we won't pretend it was. It caught one fresh false positive: it flagged our working cookie banner as broken and invisible, having measured it in a hidden state instead of on the rendered page. That one ungrounded measurement caused eight cascading findings. We caught it the same way we caught everything in the first audit: we traced it to a single root cause and filed the fix against the tool. That's the next improvement cycle, already in motion.

That's the compounding part, and it's the honest version of a promise: the failure modes we find, we train out. Each site we audit makes the next audit sharper. By the time our tools run on your site, the specific mistakes in this write-up have already been grounded out of them — and the ones they haven't met yet get the same treatment, in the open, the moment they surface.

Don't take our word for it

Our site is open source. The code is on GitHub — diff every change we made. So is the raw evidence: the first audit and the re-audit; the triage log showing how we sorted real findings from noise, finding by finding, each tied to the commit that closed it; and the tool-hardening log where we fixed Muttr in the open.

That's the reason we wrote this. It's one thing to claim your audit works. It's another to show how you prove it. Our audit found value, and we also found out how to make our process better — and we're showing you both.

The takeaway

An audit is only as good as its weakest grounding. So is an AI assistant, or a human under deadline. Verbosity, severity ratings, and confident prose are not evidence — they're useful when the evidence is validated, and noise when it's not.

The deliverable that ships is the one where every claim has been re-checked against the specific target and can be proven wrong if it's wrong. That's not a nice-to-have we discovered. It's the entire thesis of what we build — now corroborated from the inside by watching a tool, an AI, and ourselves all fail and recover on the same axis, and by a second audit that was measurably better than the first because we did the work.