Insights27 April 2026Updated 26 October 20265 min read

Team Chat Is a Knowledge Source, Not Ground Truth

Agent Grounding Dendro Logic shows digital icons flowing into a glass with a glowing fibre optic burst.

Treat team chat as evidence to inspect, not as an approved account of how the system works. For teams building a shared knowledge base, we recommend capturing selected conversations with their sources and keeping a clear distinction between a proposal, an agreement and a verified implementation. The aim is to answer a practical question: what did this team discuss, and where can someone check it?

That distinction matters when a model writes the summary. NIST's generative AI risk profile identifies confidently presented false content as confabulation and notes that generated citations can also be false. Our recommendation is therefore to treat both the summary and its citations as outputs to verify.

Capture a bounded conversation

A long river of small bubble shapes of light, with one section enclosed in a glowing frame and lifted out

Start with an explicit list of channels and an agreed purpose for collecting them. For an engineering pilot, choose a project channel containing discussions that the team already wants to retain, rather than importing the whole workspace. Keep direct messages and unrelated channels outside that pilot. Agree who owns the capture process, who can stop it and how long the collected material should remain available.

Define a capture unit before choosing a schedule. We would start with a thread and retain its channel identifier, message identifiers, participants, timestamps and source links. Include enough surrounding messages to show whether the apparent decision was questioned or withdrawn. If the conversation continues elsewhere, record the gap rather than asking the summariser to fill it.

A daily run is one scheduling option, not a promise of completeness. Record which source interval each run covered and make failures visible to the operator. Design repeated imports to update the same source records rather than creating another copy of the discussion. Before relying on a connector, test its actual access, thread coverage and handling of missed updates.

Summarise without promoting a suggestion into a decision

Many soft dim bubbles of light around one solid bright cube, clearly different in weight

Use a small, explicit summary structure: topic, proposed changes, confirmed decisions, unresolved questions, blockers and follow-ups. Allow each field to be empty. Ask the summariser to identify the message supporting each decision and to leave ownership or deadlines unspecified when the conversation does not establish them. Have a person confirm consequential decisions before promoting them into an approved decision record.

Consider a hypothetical thread in which someone proposes removing a retry, another person raises a failure case, and the team agrees to investigate. The summary should record an investigation, not an agreement to remove the retry. Keep the objection and the unresolved question attached to the proposal so a later reader can inspect the difference.

Evaluate summaries against the original conversations before deciding whether they improve retrieval. Ask reviewers to check omitted objections, invented assignments and disagreements presented as consensus. Treat shorter text as an output characteristic, not evidence that the summary is more accurate.

Keep the source relationship explicit

The W3C PROV overview describes provenance through the entities, activities and people involved in producing data. For chat ingestion, we would apply that distinction by recording the source messages, the summarisation run and any human approval separately. A message link should identify the evidence, while the summary record should identify when and how that evidence was transformed.

The publisher's contents for Continuous Architecture in Practice identify chapter 3 as covering data architecture. For this ingestion design, we recommend keeping the conversation as the source and the summary as a derived record, with a named owner for corrections. Store the source version or last observed edit time alongside the capture time and summariser version. Do not describe a source link as proof that the discussion is still current or that its proposal has shipped.

When someone asks what the system does today, check a chat-derived answer against the relevant current code, release record or maintained documentation. When they ask why an option was rejected, return the dated discussion and its reasoning instead. Make that difference visible in the answer rather than collapsing both questions into the newest matching summary.

Carry permissions and changes through the pipeline

For access control, our recommended acceptance rule is that an answer must not disclose source material to someone who cannot access it. Apply that rule before restricted text reaches the answering model, including summaries derived from multiple channels. Test the identity of the person asking separately from the permissions of the account doing the import. For answers posted into a shared channel, check the audience of the destination as well as the person who asked.

Define what happens after a source message is edited, deleted or made inaccessible. We recommend maintaining a dependency record connecting messages to summaries, search entries and cached answers so operators can locate affected copies. Choose and test the appropriate correction, suppression or deletion behaviour for each copy under the organisation's retention policy. If an update cannot be reconciled, withhold the affected answer until an operator resolves it.

Treat sensitive-data detection as an additional check, not permission to collect everything. NIST's profile also identifies data leakage and unauthorised disclosure as privacy risks. Have the responsible owners review collection scope, processing arrangements and retention before enabling sensitive channels, whether processing is local or hosted elsewhere.

Test the query surface as well as the importer

A chat bot is one possible interface for asking the knowledge base questions. Keep its answers subject to the same source and permission checks as any other interface. Return supporting links, distinguish unresolved discussions from approved decisions and say when the available evidence cannot answer the question. Avoid feeding bot-generated answers back into the index as independent confirmation of their own claims.

Build a test set containing a corrected decision, an unresolved proposal, a deleted message, a revoked membership and a question with no supported answer. Check whether the importer captures the changes, the summary preserves the meaning and the answer respects the current audience. Measure citation support and missed corrections alongside retrieval usefulness, rather than promising a particular response time. Before expanding the pilot, agree who reviews failures and what result would justify stopping ingestion.

Update, October 2026

Our engineering article on team-context infrastructure, published on 1 May 2026, includes a section on a chat interface for shared knowledge. Read it as a related implementation account, not proof that the ingestion design above is correct for another team. For a first trial, choose one agreed channel, a small set of answerable questions and the source changes that must invalidate an answer.

Sources

Want this in your team?

Tell us what you're building and where you want to get to, and we'll think it through with you.

Let's have a chat Follow by RSS →

All insights →