What Google covers and Microsoft doesn’t

Sooner or later somebody in the room reaches for the other framework. “Google’s PAIR guidebook covers errors, we should follow that instead” — offered as an alternative to a HAX point, as though the two were competing lists and you had to pick one.

There are two things wrong with that, and the second one is the more interesting. The first is that they are not competing lists. Microsoft’s eighteen guidelines describe behaviours an interface should exhibit. The People + AI Guidebook is a sequence of decisions a team should make, most of them before an interface exists. Different objects.

The second is that there is a good chance the person quoting it is quoting a version Google replaced. That is not a hypothetical; it very nearly happened to this lesson.

Three editions, and search hands you the first one

The Guidebook has been published three times. Its own contributor record for the current edition states the original publication date as 8 May 2019 and describes the current release as the third edition, updated April 2025, with the 2025 work explicitly being the generative-AI update. A second edition existed in between: Google’s own PAIR Guidebook codelab introduces it at Google I/O and says the first edition had come out two years earlier.

Here is the trap. The first edition is still live on the same domain, at /old-gb/ and at a set of /chapter/… URLs, and those chapter URLs are the ones listed in pair.withgoogle.com/sitemap.xml. The 2019 pages carry no date, no edition marker, and nothing to indicate they have been superseded. They look exactly like current documentation.

The chapter names changed between editions, which is how you tell them apart at a glance:

Small differences, and that is exactly what makes them dangerous. If somebody says “the Explainability and Trust chapter,” they are reading the 2019 edition — the current one is Trust + Explanations. If they say “Data Collection and Evaluation,” same. You now have a two-second test for whether the person arguing with you has opened the current document.

Six chapters, and the three HAX has nothing for

The current six chapters run: User Needs + Defining Success, Data + Model Evolution, Mental Models + Expectations, Trust + Explanations, Feedback + Controls, and Errors + Graceful Failures. Alongside them the site carries patterns, workshop material, case studies and a glossary — the workshop kits are downloadable PDFs, and since the whole thing is licensed CC BY-NC-SA 4.0 you can run one inside a portfolio company, with attribution, as long as nobody is charging for it. The Trust + Explanations worksheet is a fair sample: brainstorm where users would under-trust the feature, where they would over-trust it, then decide which interactions need an explanation and what kind.

Note that word — calibrating. Not maximising. A framework published by a company selling AI, telling you that too much trust in the AI is a design failure, is worth being able to quote.

Three of the six have no counterpart anywhere in the eighteen.

Whether to use AI at all

The first chapter is about deciding whether this should be an AI feature and what success would even mean, including where to draw the line between automating a task and augmenting the person doing it. The eighteen guidelines never ask this. They begin from the premise that the system exists and describe how it should behave.

Data

Data + Model Evolution covers requirements, sourcing, preparation, and how the model is evaluated and evolved. There is nothing about data anywhere in the eighteen — not one guideline. That is not an oversight; the eighteen are about runtime behaviour by construction. But it means “we followed the HAX guidelines” is not a claim about a system’s data, and people do hear it as one.

The user’s mental model as a design object

HAX G1 and G2 tell you to make clear what the system can do and how well it does it. Those are behaviours to implement. Mental Models + Expectations treats what the user believes about the system as something you are actively shaping, correctly or otherwise, from first contact onwards. For an agent — where the user’s belief about what it will do next is the entire safety story — that is the more useful framing.

The genuine overlap is the other three. Trust + Explanations, Feedback + Controls and Errors + Graceful Failures cover roughly the territory the eighteen cover, at finer grain and with worksheets attached.

Why “different objects” is the useful framing

HAX tells you how the interface should behave. PAIR tells you what the team should have decided. Neither tells you what to do once the agent has already acted. Said in that order, it is a compliment to both documents and a precise statement of the gap — which is a much better position to hold than being the person in the room who dislikes frameworks.

It is also the framing that survives contact with the work. On a portfolio-company engagement, the question that unblocks things is rarely “which framework do we follow.” It is “which of these decisions did this product make by default two years ago, and is it still the right one now that the thing takes actions.” Only one of the two documents is organised to answer that.

What this does not cover

Both frameworks are now on the table with their contents stated accurately and their editions pinned down. What is still missing is the question of what kind of machine either was written about. That is the provenance lesson, and it is the one that turns all this reading into something you can argue from: the twenty products the eighteen were validated against, the dates that make “this predates tool-calling” checkable rather than dismissive, and what Microsoft published instead of revising the guidelines.