BlogEngineering

ENGINEERING

The claim that survived four rewrites and was still false

A false sentence about a competitor sat on our homepage through four commits that touched it. Every one of them was careful. None of them re-checked the fact.

SAGARISEngineering7 min
The claim that survived four rewrites and was still false

The claim that survived four rewrites and was still false

Until late in the evening of 13 August 2026, the SAGARIS homepage carried this sentence:

The second half is false, and it names a company. Salesforce announced Agentforce Contact Center on 10 March 2026, describing a product that "unifies voice, digital channels, CRM data, and AI agents natively in a single system", and stating that it "is generally available as an add-on to all Agentforce Service customers in the U.S. and Canada". A caption on the same page reads: "A Salesforce Service Console displaying an inbound support call for a customer." Salesforce also publishes a Trailhead unit called "Optimize Inbound Call Management with Omni-Channel Flows" inside an Agentforce Voice module. Both were fetched on 14 August 2026.

The component that rendered our sentence is the one whose own name promises that the claims inside it are provable.

The number in the title is derived, not rhetorical

The obvious question about a mistake like this is how long nobody looked. The answer is in the git history, and it can be recovered with one command: git log -G "ships inbound AI voice".

The sentence was written on 12 August 2026 at 15:50 Eastern, in a commit whose message begins "honest proof". It was then handled four more times before anyone questioned it:

- 13 August, 15:04. A copy-editing feature moved the sentence out of the component and into a structure an editor could reach. The sentence itself was re-quoted and split across array elements. - 13 August, 20:06. The content management system replaced an interim storage bridge, and the sentence moved again. - 13 August, 21:45. The landing hero was rebuilt to match an approved design, and the sentence was rewritten a third time. - 13 August, 23:47. The name was removed.

Four commits touched the false sentence. The ordering is worth stating carefully, because one of those commits carries a +0500 author timezone and reads as 14 August at a glance; git merge-base --is-ancestor confirms it landed before the fix.

Every one of those four commits was careful work. Each has a diff you could review. Each was reviewed. And in each of them, the load-bearing question, does Salesforce ship inbound AI voice, was never asked, because nothing in the diff was about that.

Rewriting reads like verifying

This is the mechanism, and it is more general than one sentence.

Review reads a diff. A diff shows what changed. When a claim is being restructured, moved into a CMS, or reflowed to fit a new layout, the diff is full of evidence of attention: quotes rebalanced, strings escaped, a component decomposed. It looks exactly like somebody thinking hard about that text. And it is, but about the wrong property. The reviewer is checking that the sentence still renders, still reads well, still fits. Nobody is checking whether it is true, because truth is not in the diff.

There is a worse version of the same problem, and it is the reason this class of claim needs a different control rather than a better habit. A claim about a competitor can become false with no edit at all. On 9 March 2026 our sentence would have been closer to defensible. On 11 March it was not. Nothing in the repository changed. A sentence with no author and no date sitting in a source file has no way to know that the world moved, and no reviewer reads a file that nobody touched.

So the sentence was false when it was written, and stayed false through four passes of genuine attention, and no process in place could have caught either fact.

What the guards were actually watching

We already had honesty controls, and they were working. They were pointed elsewhere.

The main rule set polices what we say about our own customers, usage and results. That is the failure that burned this company in August, so it is where the effort went. It says nothing about claims we make about other people, and a false negative claim about a named competitor is arguably the more expensive kind, because there is somebody on the other end of it.

A second guard exists for exactly this genre of drift, where one page says a capability is live and another says it is gated. It did not fire either. It was scoped to SSO, SAML, OIDC and Okta, and it works by requiring a qualifier on a line. The drift it missed was in a different acronym and a different sentence shape. A guard scoped to a vocabulary catches drift inside that vocabulary and is blind one word outside it, and nothing about a green result tells you which case you are in.

What was built, and what it deliberately does not do

There is now a register of every vendor named in a negative claim, and a retraction list. Naming a retracted vendor in a negative claim fails the build, and is refused on the CMS read path, so it cannot come back through an editor either.

The header of that file spends more space on its limits than its function, and the limits are the interesting part:

It cannot verify that a vendor lacks a capability. That needs a person reading the vendor's current documentation. No amount of code closes that gap, and code that pretended to would be the same defect one level up.

What it can do is make the claims enumerable. A negative claim naming a company is no longer invisible prose. The names are extracted from the sentence and matched against a register, and a name nobody registered fails.

It also puts a date on the whole set. The expiry is a constant, currently 2027-02-09, and it fails the build rather than raising a note. The reason is written in the file: this specific claim was already false on the day it was written, so "we will keep an eye on it" is demonstrably not a control.

And the retraction entry records its own provenance honestly. The Salesforce fact reached the session that wrote the entry as a relayed decision rather than a fetched page, and the entry says so, in the file, rather than presenting a citation it did not have. The verification in the front matter of this article was done afterwards, against Salesforce's own pages, on 14 August.

Two things that are not fixed

The correction is live. A fetch of the homepage on 14 August 2026 returns the sentence without Salesforce in it and zero occurrences of the word anywhere on the page. The rest of the sentence, naming six other vendors, is unchanged, and the ruling was deliberately to remove one name and add no new claim.

That leaves the six. Every one of them traces to an internal capability note, which records where this office wrote the claim down, not evidence that the claim is true. The register says that in those words. Somebody has to open six vendors' documentation before that expiry date, and until they do, the honest status of those six names is registered, dated, and unverified against the vendors themselves.

The safe phrasing, incidentally, already existed in the same repository, on a comparison page written days earlier: "Inbound AI voice is a category none of the mainstream dialing or engagement vendors ship today." It scopes the claim to a category instead of enumerating companies, so it cannot be falsified by one vendor shipping one product. Nobody looked for it. That is its own small version of the same failure: the answer was in the codebase, and the question was never asked.

SAGARIS

Written by the SAGARIS team.

See the engine run on your pipeline.

Thirty minutes, your own data, no setup.

Book a demo

Get the next one in your inbox.

SAGARIS opens fully in October 2026. Join the waitlist and we will be in touch before launch.

We use these details to contact you about SAGARIS. See our privacy policy.

Book a demo