Two Meeting Transcripts Both Claim Authority After Handoff: Choose and Reconcile One

Two meeting transcripts can both claim final authority because capture and later handling are separate events. The word final often describes where a file landed, not whether another system relied on a different version.

Treat the conflict as an evidence problem. Preserve the original files and their metadata first. Then establish what generated each version, what changed between them, who approved either one, and where each version was used.

Google Meet can create a separate transcript file each time transcription is stopped and started in one meeting. Its notes feature also creates a generated notes document after the meeting. Those are different artifacts with different purposes, so a file name alone cannot establish authority. Google Meet transcript guidance and Google Meet notes guidance describe those flows.

Why do two transcript objects both claim to be final for one call?

Start with generation provenance. One version may be an automated transcript captured during the call. Another may be a later export or corrected copy, including one produced after capture restarted. A summary or meeting-notes document can be useful evidence, but it is not automatically the authoritative transcript.

Storage paths can make the collision worse. Google says meeting transcripts are saved in the organizer's Google Drive, and notes are generated in the organizer's Drive after the meeting. Microsoft says Teams recordings are processed and saved in OneDrive for Business or SharePoint, with locations depending on meeting type. A handoff can therefore produce different links, owners, access rules, and storage paths for records tied to the same call. Google Meet, Google Meet notes, and Microsoft Teams document those platform-specific behaviors.

Do not infer priority from creation time alone. A later transcript may omit an earlier segment. An earlier transcript may have reached the CRM before a corrected version did. Authority comes from a recorded decision backed by the comparison and the list of consumers.

• Capture provenance: platform and meeting identifier. Record the start and end times. Also record the language, initiator, and whether capture restarted.
• Transformation provenance: export and cleanup. Record speaker labeling and redaction. Also record summarization and any human edits.
• Approval provenance: reviewer, decision time, scope of approval, and the evidence reviewed.

What should the dual-transcript authority ledger contain?

Build one ledger before changing access, deleting files, or overwriting CRM fields. Give the two records neutral labels, such as T1 and T2. Use their real immutable IDs and hashes in the working ledger. Do not replace missing evidence with a guess.

The ledger is a recommendation for operational control, not a claim that a hash proves semantic accuracy. RFC 3161 describes time-stamping a hash representation of a datum as evidence that the datum existed before a particular time. Use a hash to identify the exact file you reviewed, then keep the approval and downstream trail beside it. RFC 3161 provides the protocol context.

W3C PROV-O models entities, activities, and agents, including derivation, generation, association, and attribution. That structure is useful here: the files are entities, capture and cleanup are activities, and the reviewer is the responsible agent. W3C PROV-O is a reference model for recording that chain.

Which summaries, tasks, or CRM fields consumed each version?

Search by artifact ID or file URL. Also search the calendar event. Use the meeting identifier or distinctive phrases from both transcripts. Search the summary and task systems. Search the CRM activity timeline and contact or account fields. Also search follow-up emails and shared folders. Record direct links in the ledger.

Classify each consumer by consequence. A copied meeting summary can usually be corrected and reissued. An assigned task may need its owner and due date checked, with its source note reviewed. A CRM field can affect routing, forecast, or follow-up, so compare its current value to both transcripts before changing it.

Keep the original source note on each correction. State which transcript supplied the old value and which approved record supplies the replacement. Also state who made the change and when. NIST's log-management guidance covers developing and maintaining log-management processes across an organization. It supports keeping a reviewable operational trail rather than relying on memory. NIST SP 800-92 was published in September 2006.

• Summaries: locate the source link and author. Also locate the distribution list and any copied decision or action item.
• Tasks: locate the task URL and owner. Record its status and due date. Also review its description and source reference.
• CRM: locate activities and notes. Also locate contacts, accounts, and opportunities. Review next steps and fields updated from the call.
• Messages and documents: locate follow-ups and shared briefs, plus proposals and handoff notes that quote either record.

Can one transcript survive, or must a reconciled third version replace both?

Let one transcript survive only when the evidence shows it is complete and approved for the required scope. The other record must add no approved material content, and every identified consumer must be tied to the survivor or corrected without ambiguity. Record why the withdrawn file is no longer authoritative. Preserve it according to the applicable retention rules.

Create a reconciled third version when each source contains material content that must remain, or when the source records disagree on a decision or owner, or a commitment or customer fact. Label it as reconciled, link both source IDs and hashes, identify each resolved difference, and obtain explicit approval. Do not silently merge text.

If a conflict cannot be settled from the available evidence, mark the point unresolved. Keep both source records non-authoritative for that point, route the question to the meeting owner or accountable reviewer, and prevent new downstream updates until the decision is recorded.

• Survivor decision: one source is complete, approved for the needed scope, and the other source adds no material approved content.
• Reconciliation decision: both sources contain material content or their differences change what a downstream consumer should do.
• Escalation decision: the evidence cannot settle a material disagreement, so an accountable reviewer must decide.

How do you withdraw the losing record without creating another split?

Make the authority decision visible where people will encounter the old version. Add a withdrawal notice with the approved record link and decision time. Name the reviewer and the reason for replacement. Do not delete the source before the reconciliation trail and retention requirements have been checked.

Reissue corrected summaries, tasks, and CRM updates to every identified consumer. The notice should say what changed and what action is required. State separately whether a prior task or field value was reversed. Mark each recipient or system complete in the ledger.

Finish with a second review. Open the surviving or reconciled record and sample every changed downstream item. Confirm the old link is labeled or access-controlled as appropriate. Verify that no new record was generated during the cleanup.