Meeting knowledge base architecture: from transcript to trusted record

A transcript is chronological evidence. It captures discussion, abandoned ideas, uncertainty, disagreement, and side comments. A knowledge record has a different job. It must tell a later reader whether an outcome is proposed, approved, superseded, completed, or still open.

Copying the whole transcript into a search index collapses those two roles. A search result can surface an early proposal after the group rejected it. A model can quote a confident speaker without knowing that another person owned the decision. The source should remain inspectable, but it should not automatically become approved company guidance.

The complete meeting knowledge base guide defines the operating model. This architecture guide focuses on the records, transitions, and tests needed to implement it.

Post-meeting files are not always ready when the call ends. Google Meet exposes transcript states and a file-generated event, while its transcript entries have their own identifiers and availability rules. An integration should therefore wait for the final artifact state rather than ingesting the first incomplete object it can fetch.

Google documents that Meet applications can subscribe to transcript events and later retrieve recordings, transcripts, and transcript entries through the Meet REST API. The event identifies that something changed. The workflow still needs to fetch the current object, record the source identity, and handle retry or delay.

Store the conference ID, transcript ID, artifact version or modified time, participant identity, and source timestamp. Use a stable processing key so the same event can be received twice without creating two knowledge records. If a transcript is edited after generation, retain which representation supported the reviewed outcome.

Do not store one meeting summary and expect it to support every later question. A decision, action, commitment, objection, risk, and open question have different owners and end states. Give each one a type and status that matches its role.

A decision record might include the subject, selected option, rationale, decision owner, effective date, scope, source excerpt, and superseded decision. An action needs an owner, due date, destination, and completion state. An objection should preserve whose objection it was and whether it was resolved. An open question must remain visibly open.

Use the downloadable meeting knowledge base record model as a starting structure. Remove fields the workflow does not use, but do not remove source identity, ownership, status, access, or review merely to make ingestion easier.

An extraction model can propose that a sentence is a decision or commitment. The proposal should carry the source excerpt and confidence or review reason, then enter a bounded review queue. The model should not publish policy, change a customer commitment, or overwrite a project state because the wording sounded decisive.

Review effort should follow consequence. A routine internal action with a named owner may need only confirmation by that owner. A contractual promise, personnel decision, pricing exception, or safety instruction needs the accountable role and the original context. Low-confidence extraction is not the only review trigger. A high-confidence but high-impact statement still deserves review.

Record edits made during review. The approved wording may be clearer than the transcript, but the system should show that a person changed it and preserve the supporting passage. This lets a future reviewer distinguish source evidence from organizational interpretation.

Meetings often revise earlier decisions. Updating the old record in place can hide why the business changed direction. Leaving both records active can make search return incompatible answers. Use an explicit relationship such as supersedes, confirms, narrows, or reopens.

When a later meeting changes an outcome, mark the previous record as superseded for new work while keeping it available for historical questions. The current record should link backward, and the old record should point forward. Retrieval for a current-state question should prefer the active record and disclose the change when it matters.

A contradiction without an accountable resolution is not a freshness problem. Return the conflict, the affected subject, and the owner route. Do not let recency alone decide that the newest speaker was authorized to change the rule.

A promoted record can be shorter than the transcript and still reveal restricted information. Copy the relevant access boundary into the knowledge record, but retain a link to the source policy or group that governs it. If membership changes, the searchable derivative must stop appearing for that user as well.

Google states that Meet transcript entries returned by the API are available for 30 days after the conference, while transcript files stored in Drive follow the file destination and its controls. Its artifact documentation also warns that API transcript entries may differ from an edited transcript file. Retention and version choice therefore belong in the design, not in a cleanup task after launch.

Define what deletion means. Removing a meeting should remove or tombstone searchable chunks, generated summaries, promoted candidates that have no independent retention basis, cached answers, and embeddings. A reviewed business record may need a separate retention rule, but that exception should be explicit and auditable.

A useful evaluation asks questions that expose the record model. Which decision is current? What did the customer actually commit to? Who owns the next action? Which objection is unresolved? Why did the team reverse the earlier approach? Every answer should return the right record type and a source trail.

Then break the route. Deliver the transcript event twice. Delay file generation. Edit the transcript after ingestion. Use two participants with the same display name. Revoke access. Delete the source. Create two contradictory decisions. Ask a user from another department. Confirm that the system limits the answer, preserves identity, and does not leak an obsolete record.

Measure accepted records, material reviewer corrections, source-link failures, duplicate candidates, unresolved subject matches, access defects, stale active decisions, and time from meeting end to reviewed knowledge. Counting summaries or indexed words measures processing volume, not team memory.

A meeting knowledge base may feed a CRM, project tool, service desk, or policy workflow. Each destination has its own field authority and duplicate behavior. The shared knowledge record can propose an update, but the destination adapter must still match the correct object, respect field ownership, write idempotently, and verify the saved result.

For customer records, use the separate meeting notes to CRM guide. Microsoft also documents saving AI-generated meeting notes to a selected CRM record or configured field. That capability does not decide which facts should overwrite current CRM values or which changes require approval.

If the architecture needs implementation and acceptance testing, review the meeting knowledge base service. Start with one meeting type and one reusable outcome before indexing every conversation.