Your team chat is a QA knowledge base nobody indexes

Part four of the series on classic → AI-assisted QA. Earlier parts made the case that AI test design is only as good as its context, and that the richest slice of that context is the pull request. This one is about the slice everyone has and nobody indexes: the team chat.

Ask a simple question about almost any product: "do we support paying with an expired-then-renewed card?" The answer usually isn't in the ticket, or the spec, or the test suite. It's in a Slack thread from four months ago where three people worked it out, decided "no, we explicitly don't handle that case," and moved on. That decision is real, it's binding, and it is effectively unfindable.

Negative requirements live in chat

Formal artifacts — tickets, specs, acceptance criteria — are good at capturing what a feature should do. They're terrible at capturing what it deliberately shouldn't. "We decided not to support X." "That's out of scope for now." "We'll assume the upstream service never returns null there." These are negative requirements, and they almost only exist in conversation.

For QA this is a big deal, because negative requirements are exactly the boundary of what you should and shouldn't test. Without them, you get two failure modes: writing tests for behavior the team consciously chose not to build (false failures, wasted effort), or missing that a "won't happen" assumption is load-bearing and untested (a real gap). The knowledge exists — it just evaporated into a channel nobody scrolls back through.

Why keyword search doesn't save you

"Just search Slack" doesn't work, for the same reason keyword search fails on a test portfolio. Chat is context spread across messages: the decision is in one line, the reasoning is three messages up, the caveat is in a reply an hour later. Search "expired card" and you get the one message that happens to contain those words, stripped of the thread that gives it meaning — or forty unrelated hits. The signal is real; it's just not retrievable the way it's stored.

The pattern: pull chat into the same searchable layer

The fix is the same architecture from part one, extended to chat: bulk-ingest the relevant channels — messages and their threads — into the same local, semantically-searchable context store as your cases and tickets. Two things matter in how you do it:

• Chunk with surrounding context, not per message. A lone message is noise; a whole thread is often too much. A sliding window — the message plus the few around it — keeps the decision attached to its reasoning.
• It's a retrieval source, not a source of truth. Chat is opinions, half-decisions, and jokes mixed with the real calls. You're making it findable, so a human or an agent designing tests can surface "here's where the team last discussed this," then verify. You are not treating a random message as spec.

Do that, and "did we ever decide anything about X?" stops depending on whoever's been there three years. When an agent drafts tests for a feature, it can retrieve the actual decisions and exclusions instead of inventing plausible ones. When you triage a bug, you can pull the thread where this exact edge case was first argued.

The caveats worth stating

Two, honestly. First, privacy and scope: you index the channels where product and engineering decisions happen, not people's DMs or off-topic chatter — and you keep it in the same access boundary as the rest of your QA data. Second, noise is real: chat has a low signal-to-noise ratio, so this is worth doing when the cost of losing decisions is high (regulated, fast-moving, high-turnover teams) and overkill when your whole team fits in one room and remembers everything.

Where it fits

This is the least glamorous source in the series and often the highest-leverage, because it's the one holding the decisions that were never written down anywhere else. Classic automation ignores it entirely — chat isn't a "QA tool," so it never enters the picture. Wiring it in is a quiet but real part of moving a team from classic to AI-assisted QA: you stop losing the reasoning behind your own product.

If your team's real decisions live in threads nobody can find, that's a gap worth closing.