3-02 / Series
3-02 № 02 · 2026

Check the vendor's story
against primary sources.

AI leans toward the story too — so design the checking, not just the asking

A vendor's narrative is not, by itself, material for a decision. You check it against primary sources first, then use it. 3-01: Companies Don't Write Their Own Code showed office and core standing in parallel, with the tax levied twice over. What decides whether to keep paying that tax or to leave is not the story a vendor tells; it is the primary sources. This chapter lays out the procedure for that check. The conclusions of 3-03 and 3-04 were all obtained with it.

AI Leans Toward the Story Too

Checking a narrative was long the work of reporters, researchers, and lawyers, because it takes time and effort. AI lowers that effort considerably. Arrange five years of statements in chronological order; see whether a 2020 claim and a 2024 claim sit on the same line — that kind of sweep is genuinely fast.

But AI leans toward the story too. That is the starting point.

There is one more. AI also matches its questioner. A model trained on human feedback leans toward answers the user will be satisfied with. Ask "is this claim correct?" and affirmation comes back; ask "isn't this exaggerated?" and the opposite comes back. The shape of the question sets the direction of the answer.

So You Design the Checking

When an AI drawn from one body of training data checks that same body, the same lean stays on both sides. AI checking AI only reinforces the shared assumption (2-17). So you design the checking first.

The four cases below were checked with this procedure. In all four, the shape of the narrative is different.

Case: WordPress — When Authority Concentrates in One Person

Matt Mullenweg — co-founder of WordPress and CEO of Automattic — has been publicly at odds since 2024 with WP Engine, a major hosting company. Public statements, court filings, blog posts, and conference talks exist in volume, so the material for checking is there.

His narrative's main claims come to roughly four. WP Engine free-rides on the WordPress ecosystem. WP Engine distorts the form of WordPress. WordPress.org is his personal property. Blocking WP Engine is a legitimate act to protect the community.

Run the procedure. First, separate the claims into claims of fact, opinions and evaluations, and figures of speech. "Free-riding" is an evaluation; "improper use of the trademark" is a claim of fact; "protecting the community" is an evaluation. Only claims of fact can be checked.

Next, apply primary sources. The WordPress Foundation's trademark policy, ten years of community discussion, statements at WordCamps. Lay out the timeline too — 2014, when WP Engine brought in Heather Brunner as CEO; 2018, when Lee Wittlinger of Silver Lake joined the WP Engine board; and the 2024 block. There were periods when WP Engine was welcomed as a WordCamp sponsor, and periods when it was listed on the WordPress.org recommended-hosting page.

Finally, apply third-party records. In WP Engine v. Automattic (from October 2024), both sides file their claims under oath. The preliminary order of December 2024 made Automattic's blocking of WP Engine from WordPress.org subject to injunction. That draws a different line from the claim that "WordPress.org is my personal property, so I decide freely."

What comes into view is that the boundary between the individual and the foundation — the relationship among WordPress.org, Automattic, and the WordPress Foundation — is re-placed with each telling. This is not a conclusion that makes anyone a villain. Everyone tells a story shaped to their situation. The more influence a person has, the further that story reaches. Which is why you check.

Case: Node.js — When No One Holds the Whole

WordPress was the shape where authority concentrates in one person. There is an opposite shape: no one is placed to hold the whole. Take whether to adopt Node.js for production work, and it becomes visible.

Checking gives this.

WordPress is the shape where one person holds too much; Node.js is the shape where no one is placed to hold the whole. Both are questions about the shape of governance, pointing in opposite directions.

Case: Linux Distributions — When the Promise Changes Mid-Way

The third shape is a corporate steward changing the promise partway through. It bears directly on choosing a Linux distribution for server use.

WordPress is the shape where one person holds too much; Node.js is the shape where no one holds the whole; Linux distributions are the shape where the promise changes mid-way.

Case: Microsoft's "Return to Native Apps" — Measuring the Slogan's Reach

The fourth is the shape where the owner of the information infrastructure tells the story. The subject is the "return to native apps" that Satya Nadella announced on April 29, 2026.

Checking makes the scope visible.

So the "return to native" is genuinely happening, within the limited scope of the OS shell layer. The reach of the slogan and the reach of the implementation are not the same size. When you hear "100% X" or "return to Y," first ask what the 100% applies to.

Gemini Pro Leaned Toward Microsoft's Story

This case contains a moment where AI's lean appeared directly.

A document Gemini Pro produced on "the technical maturity of .NET 10 Native AOT" contained the statement that *AOT support in Entity Framework Core and Microsoft.Data.SqlClient had become nearly perfect*. On the same point, Microsoft's own official documentation says something else — using EF Core's NativeAOT in production is something it will "recommend against," and the state is written as "highly experimental." Putting the same question to Gemini Deep Search, with citations to primary sources required, is what made the gap visible.

The sources are the Gemini Pro document on that subject, and Microsoft's official documentation. The former was part of a study following the 2026 "return to native"; the latter is text still present in the EF Core documentation.

What happened here is a combination of the leans listed at the start of the chapter. Weight settled on an authoritative source, the industry's repeated telling that "Native AOT has matured" passed through unchecked, and the story of the party that owns the information pathway came back via AI. The gap appeared only once an AI built by a different method — a Deep Search type that requires citations — was applied. This is where designing the checking pays.

Checking Debian — The Ground on Which 2-02 Stands

The Linux distribution case has another result from the same procedure: Debian.

What happened with CentOS was that a corporate steward could change the term of the promise. What repeated with Ubuntu was that direction changes on a private company's business judgment. In Debian that pathway is absent. What makes the promise is not the technology but the structure of governance.

Debian is on the side of Linux where you can plan in twenty-year units. What promises that is not the technology, but the 1997 social contract, the 1998 constitution, and the structure of having no owning company.

2-02: Give the AI a PC of Its Own decides to turn one company PC into Debian and hand it over, and this check is why. A foundation is better when it keeps the same shape for a long time. So you pick the one whose structure keeps the same shape for a long time. It sits there as the result of a check, not because it is pleasant to use.

The Five Practices, Generalized

The procedure common to the four cases comes to five practices.

flowchart TB N(["the narrative
(statement / article / pitch)"]) S1["1. extract and separate the claims
(fact / opinion / figure of speech)"] S2["2. apply primary sources to claims of fact
(filings / contracts / minutes / rulings)"] S3["3. lay out the timeline and check the fit
(same line as past statements?)"] S4["4. apply third-party records
(litigation / audit / testimony / academic)"] S5["5. separate what is known
from what is not known"] Out(["the decision
(don't rush the conclusion)"]) AI[("chat-type AI
(several, from different vendors)")] Deep[("Deep Research type AI
(citations required)")] N --> S1 --> S2 --> S3 --> S4 --> S5 --> Out S1 -.- AI S2 -.- Deep S3 -.- AI S4 -.- Deep classDef good fill:#e8f5e9,stroke:#7a9a6d,color:#3a4d34 class S1,S2,S3,S4,S5 good

1. Extract and Separate the Claims

Before taking a narrative in, write out what it claims. Have AI do it. Separate each claim into (a) a claim about objective fact, (b) opinion and evaluation, (c) figures of speech and expressions of feeling. Only (a) can be checked.

2. Apply Primary Sources to Claims of Fact

Take the extracted claims of fact and put them against the originals.

Kind of narrative Primary source to apply
Executive statements earnings reports, disclosures, SEC filings
Vendor pitches contract text, SLA, past deployments
Technical maturity official docs, release notes, GitHub issues
Legal disputes court filings, judgments
Industry reports primary data, methodology, sample size

News articles are secondary sources. Where possible, read the statements and numbers inside an article in the original. Asking AI where an article's quote came from gets you to the original faster.

3. Lay Out the Timeline and Check the Fit

Do past statements and present statements sit on the same line? If not, is the reason explained? Laying out Red Hat's 2014, 2019, and 2020 statements is this practice. The most checkable face of any narrative is the time axis. People speak to fit the present, and past statements stay on record.

4. Apply Third-Party Records

Beyond the parties' own statements, apply third-party records. Court filings, audit reports, legislative and committee testimony, exit interviews, citations in academic work. Applying the preliminary order in the WordPress case is this. Third-party records surface the faces a party's own telling does not touch.

5. Separate What Is Known from What Is Not Known

At the end, write separately: facts confirmed, facts that could not be confirmed, points where the opposite claim has weight, and points where information is missing. If information is missing, write that it is missing. Not rushing the conclusion is the practice here.

These five are not a tool for denouncing anyone. *Use them to keep your own judgment from going wrong.* What you write is the contrast — "the official document says this" — and nothing more or less.

The Conclusions of the Next Two Chapters Came from This Practice

The stance the Shift part takes toward vendor narratives rests on this chapter.

link:/en/ai-native-software/sovereignty/[3-03: Digital Sovereignty — The Microsoft Problem and the Trump Problem] is the result of checking the narrative that Microsoft 365 was the default on both economics and safety. The trajectory of per-seat pricing, the text of the CLOUD Act, published telemetry information, the official description of where Copilot sends content — it says the premise has inverted after applying primary sources.

link:/en/ai-native-software/sier-uneconomic/[3-04: The Structural Uneconomy of the SIer Model] does the same. It opens the narrative that "outsourcing is cheaper" into checkable form: where the upstream judgment stays, and what one turn of the loop requires.

Neither is a conclusion taken from a vendor's telling as given. Both passed through the five practices of this chapter. Which means a reader can run the same check.

Summary

This chapter laid out the procedure for checking a narrative against primary sources.

AI is good at making narratives. AI is good at checking them too. But when the AI on the making side and the AI on the checking side come from the same training data, the lean stays. Placing an AI built by a different method on the checking side is a human choice.

The next chapter applies these practices to Microsoft. Per-seat pricing, the CLOUD Act, telemetry, and dependence on the US government — it examines where the premise on the office side inverted.


Related articles