Merged Isn't Live, Signed Isn't Honest: What We Did Before Letting the Factory Write Again

Two days ago we published a post about building an EEAT factory — an Evidence Engine that researches a topic, vets and cites sources, and seals the result in a tamper-evident receipt — and then letting it fail in public three times. Two of those failures were plumbing. The third was the one that mattered: the factory produced a cryptographically signed receipt for content that was still making fabricated authorship and first-person experience claims. The receipt was valid. The content was lying. A receipt proved the bytes weren't tampered with — it said nothing about whether the claims were ever true.

This post is the sequel, and it is not "the factory works now." The more useful story is what it took to believe it works — because the most dangerous moment this week wasn't the bug. It was how close the system came to looking fixed before it was.

Three words we stopped trusting

We had a merged pull request. We had a closed issue. We had green-ish signals. By every normal heuristic, the authorship defect was fixed. Here's what we learned re-checking it anyway:

Merged isn't live. Signed isn't honest. Passing isn't proven.

Each of those is a place where a team can fool itself.

Signed isn't honest was the lesson of the first post. A receipt attests integrity — this content was not altered after generation. It does not attest honesty — these claims are true. Conflating the two is how you ship a trust system that fabricates trust signals under a valid signature.

Merged isn't live bit us this week, in the dumbest possible way. The fix for the authorship guard was committed and pushed to main. We re-ran our verification against production — and it still failed identically, as if no fix existed. For a moment that's alarming. Then the obvious: our deploy doesn't fire on push. Merged code was sitting on main; production was still running the old bundle. "Merged" had quietly become a synonym for "fixed" in our heads, and they are not the same word. We re-tested only after an actual deploy. Then it passed.

Passing isn't proven is the subtler one. We verify the guard with adversarial probes — feed it content with an injected byline and first-person experience, expect a 422. But those detectors are narrow: they were written against the exact phrasings of the original failure. A probe that replays the known attack tells you the patch holds against the past. It can't tell you the guard survives a novel generation. So the load-bearing check wasn't the replay — it was running the live generator on a topic it had never seen and watching whether anything leaked. Nothing did. That's the probe that counts.

What "verified" actually meant here — and what it didn't

Honesty, since that's the whole point of this engine: the verification this week was manual. It was a person deciding not to trust the merge, then running a handful of probes against production with a short-lived key. We did not ship a "verification layer." We don't have an automated behavioral-attestation product. What we have is a discipline and a written record — a markdown file with the probe results, the before/after, and the remaining risks. Claiming more than that would be the exact sin the first post was about.

With that said, here's the record:

That last row is its own small story: the draft model was intermittently returning empty completions when forced into a structured tool call. Left unfixed, the factory writing its own demo post would have a coin-flip chance of failing live. We filed it, the fix shipped, we re-verified against the deployed bundle (see above), and it held.

So we let it write again

Here is the part that can't be faked. The article linked below was researched, drafted, critiqued, revised, and sealed by the Evidence Engine — the same machine this post is about — on the topic "receipts as the new SEO." It carries a live, verifiable receipt.

Two things worth seeing first.

First, the critique layer visibly did its job. The generator's first draft asserted that search engines and buyers "are treating" receipts as "the primary signals." The adversarial critic — a different model family from the generator, by design — softened that to "may treat" receipts as "important signals," and inserted "industry observers expect that." It pulled certainty the sources couldn't support. That hedging isn't timidity; it's the engine declining to overclaim.

Second, and more honestly: the article is competent, not brilliant. It's a clean, well-structured survey of the topic. It is not a take you couldn't get elsewhere, and in one spot it reaches for "blockchain" where our own receipts are plain HMAC hash-chains. The receipt does not certify that the writing is good. It certifies that the content is integrity-sealed, observer-voiced, source-grounded, and honestly un-authored. Signed isn't brilliant, either — and the receipt is careful not to claim it is.

You can verify everything — the receipt chain, the source provenance (library vs. live research), and the relevance/quality scores — on its trust page:

→ Verify this article's receipt · authorshipProvenance: absent · receipt 2381cdf4…

Receipts as the New SEO: Provenance Is Becoming the Trust Signal for AI Content — researched, drafted, critiqued, revised, and sealed by the Evidence Engine. The opening, exactly as the receipt binds it:

In the rapidly evolving landscape of AI‑generated content, the question of trust has moved from the headline to the core of every publishing decision. By 2026, industry observers expect that an increasing number of search engines, content marketplaces, and enterprise buyers may treat provenance receipts and verifiable citation chains as important signals for ranking, surfacing, and purchasing AI‑driven articles, videos, and code snippets.

The italics are the critic's fingerprints — that sentence began life as a flat assertion ("are treating… the primary signals") before the adversarial pass pulled back the certainty. The full article, its citations with library-vs-research provenance, the relevance and quality scores, and the complete receipt chain are all on the trust page.

The ladder we actually climb now

Before this incident we treated the receipt as the trust artifact. After it, the trust artifact is the receipt plus the record that the thing producing receipts was verified to behave. Concretely, the rungs between "we wrote some code" and "this is allowed to face the public" are:

1. Code exists
2. Tests pass
3. PR merged
4. Deployed ← merged isn't live
5. Live behavior verified ← passing isn't proven
6. Verification record attached
7. Demo allowed

Most AI-tooling stories stop somewhere around rung 3 and call it done. The gap between 3 and 7 is where trust is actually won or lost.

The factory is allowed to write again — not because we believe it, and not because it sounds confident or shipped a receipt. It's allowed because the failure it exposed now has a live behavioral check, a written verification record, and a short list of remaining risks attached before the next public run. That's a lower bar than "we trust the AI." It's also a much more honest one.