# Build a memory, not an archive > Source: > Published: 2026-09-08 10:22:25+00:00 # Build a memory, not an archive *Part three of UXR for AI-native teams, a six-post series.* [Last week's map](https://www.thevoiceofuser.com/everyone-knows-the-uxr-hiring-market-is-bad-how-bad-is-it-though/) ended on a requirement hiding inside all five doors: a unit of knowledge that a tired human at 11pm and an agent mid-generation can both actually use. Today is about why the unit we've all been using, the report, the deck, the repository full of documents, has failed that job for a decade, and what replaces it. By the end you'll have a schema you can stand up in a spreadsheet tomorrow morning, and a sixty-second test that tells you whether your organization has a memory or an archive. ## Slide 14 Somebody on a payments team, about to scope a study on older users and document capture, does the responsible thing first. She asks in the team channel: do we know anything about this? The answer exists. It lives on slide 14 of a readout from March, one sentence, solid evidence behind it, exactly what she needs. And she will never find it. The deck has a title nobody remembers, the drive search returns forty documents containing the word "capture," the researcher who wrote it is on leave, and the question dies in the channel with two shrug emojis, which is how most organizational knowledge dies, quietly. The study gets scoped, run, and paid for, and it rediscovers March's finding in September, often one floor away from where it was already known. (Slide 14 is not a hypothetical, by the way. Mine was in a deck whose title I've genuinely forgotten, which proves the point better than the slide ever did.) The field's response to this, for a decade, has been tool migration: wikis, then purpose-built repositories, then AI search over everything. The failure followed us through every migration, because we kept the unit. The unit was the document, and the document was the problem. ## Why documents die Three mismatches, and none of them is fixable with a better tool, because all three live in the unit itself. The unit mismatch: a document is write-optimized. It exists to persuade a room, to walk an audience from context to conclusion, in order. Every future use is read-optimized and looks nothing like that. September's question needed one sentence with a receipt; March's deck offered forty slides with a narrative arc, and nobody needs the arc at 11pm. Documents are performances, and performances don't answer questions. The time mismatch: a document is true on the day it's presented and then rots silently, with no way of saying which parts died. Slide 14 might still hold in September. Slides 15 through 22, about a flow that got redesigned in June, are now confidently false, and the deck can't tell you which is which. The composition mismatch, the expensive one at AI-native speed: fifty documents don't add up to anything. You can't lay them side by side and compute across them, can't ask what do we collectively know about first-time users, can't even reliably discover that deck twelve contradicts deck thirty-one. ## The claim So change the unit. A claim is one falsifiable sentence about users, with a receipt stapled to it. Every word earns its place. One sentence, because retrieval and citation happen at sentence scale. Falsifiable, because a statement no conceivable evidence could contradict isn't knowledge. About users, because that's the boundary; opinions about the roadmap live elsewhere. And the receipt, because a sentence without provenance is a rumor, and the difference between a memory and drift is that every sentence can show its work. One consequence deserves its own line, because teams trip on it for a week and then never again: a study that ships a deck and zero claims shipped a performance. ## Why one sentence, exactly The one-assertion rule looks like a style preference. It isn't, and one example shows why. Take a finding straight from a real-shaped readout: "Users find identity verification confusing and want to complete it later, especially on mobile." Reasonable sentence. Now try to use it. Someone asks about deferring verification; the search matches, but half of what comes back is about confusion, and the reader digs. A later study shows the timing barely matters but the confusion is real; the compound is now half true, and a half-true sentence can be neither kept nor retired honestly. And the two halves aren't even the same kind of evidence: the confusion is observed behavior, the "want to complete it later" is stated preference, and what people do and what people say they want have embarrassingly little to do with each other. Split it into two sentences, each scoped, each carrying its own evidence type and its own clock, and everything works: each retrieves cleanly, each can be confirmed or retired on its own merits, and each can accumulate corroboration over time, which compounds can never do because you can't recognize when two paragraphs approximately overlap. ## The schema, ready to steal Here's the claim as spreadsheet columns, simplified from the full version I run, and enough to start tomorrow: - **id** : a stable address that survives reorgs - **statement** : the one falsifiable sentence - **scope** : who, where, which surface, when in the journey - **evidence type** : observed, stated, or inferred, because the say-do gap deserves its own column - **source** : what produced this, with a link to the full artifact - **anchor** : one verbatim sentence quoted from the source, never paraphrased - **method and n** : how it was made, honestly sized - **confidence** : established, supported, indicative, or conjecture - **decay class** : how fast this kind of truth rots (next section) - **dates** : when the evidence was made, and when reality last confirmed it - **owner** : a person's name, not a team (Eleven columns will feel like bureaucracy for about two weeks. I wish I could tell you it feels lighter sooner. It doesn't, and then one retrieval pays for a month of it.) Two structural notes. This lives in a spreadsheet until it can't; the schema is the asset and the tool is a detail, and buying software before you have two hundred claims is how this dies as a procurement project. And it runs in two tiers: a durable core for what the organization knows, which is what I called the Frame in my book, and a lightweight working store per bet, opened at kickoff with three columns filled in out loud: what do we know, what do we assume, and what must be true for this bet to work. That third column is the one teams skip, and if nobody wrote a premise down, nobody will notice when it fails. ## Memory that stays true The dates column is where this stops being a filing exercise, because every corpus ever built shares one weakness: it was true when written. On a Thursday, a pod ships a redesigned upload step, and somewhere a claim about uploads failing silently just stopped being entirely true. Nothing happens: no alert, no field change. Archives don't notice things. The fix is treating truths like they age at different speeds, because they do. A finding about human motivation might hold for a decade. A finding about a button dies with the next redesign. So every claim carries a decay class, and the class sets its review clock: durable truths get re-observed yearly, market truths get checked against the world every six months, interface truths get wired to releases so the Thursday deploy automatically flags every claim about the surface it touched, and campaign-level reactions simply expire. One rule keeps the whole thing safe: flag, never edit. No automation ever changes a claim; the system notices and a human decides, because automation that can edit knowledge will eventually write errors into it, and no one will see it happen. ## The move has a precedent If encoding judgment into a governed, machine-readable system sounds aspirational, look at the one function that already did it, under the same pressure. When screens became generatable, design's craft monopoly fell in about eighteen months, and design did not get sorted into overhead. The reason is the design system: tokens, components, usage rules, accessibility constraints, taste converted into a governed layer that constrains the machines at the moment of generation, automatically, because it was already machine-readable and already wired into how building works. Nobody schedules a readout to align on whether to follow the design system. Designers survived the wave by being encoded, and the claims corpus is the same move for what your organization knows about its users, one function behind. ## The sixty-second test Take your organization's most-cited research finding, the one that shows up in decks and decisions. Can you produce, in sixty seconds: its receipt, its honest scope, and the last date anyone verified it still holds? If yes, you have the beginnings of a memory. If no, you have an archive, and an archive with confident labels is more dangerous than no archive at all, because people trust it. Run the test before next week; the result is the reason the next post exists. ## Next week A memory like this changes the questions people ask it, and it turns out every question that hits a research function has one of exactly three honest prices. Most functions pay the wrong one in both directions, which is next week: the front door, the five-minute routing framework, and why not every question deserves a study, including some of the ones you're running right now. And if the schema breaks somewhere when you stand it up, my email is open, and I mean that. Field reports beat theory. See you next week. 🎯 This is part three of UXR for AI-native teams, a six-post series. [Subscribe](https://www.thevoiceofuser.com/where-user-knowledge-actually-enters-an-ai-native-team/#/portal/signup), and the rest arrives as it publishes, no algorithm required. 📖 If the fast-research layer underneath this series is the part you need first, that's my book: [AI-Powered UX Research,](https://a.co/d/05aWkwtS?ref=thevoiceofuser.com) the operating manual for running research at the speed your team actually needs. This series is what I've been thinking since.