An Accepted Meeting Transcript Points to the Wrong Participant Roster: Rebuild Presence Provenance

An accepted transcript can still point to the wrong people. Acceptance only says a transcript passed the workflow that accepted it. It does not prove that the roster attached to it came from the same meeting session.

Stop downstream writes when that mismatch appears. Keep the transcript bytes and hash unchanged, identify the authoritative meeting record, bind the transcript to the correct roster, then rerun only the claims affected by the old binding.

Google Meet exposes transcript metadata within a conference record and identifies each transcript as a one to one mapping to a unique transcription session. Its participant records also expose participant identity forms and first and last join times. Those fields give a useful basis for an evidence-led reassociation, rather than a name match alone. Google Meet transcripts, September 16, 2026 and Google Meet participants, September 16, 2026 describe those records.

• Freeze automated writes that rely on speaker attribution, consent status, summaries, tasks, or CRM records for the disputed transcript.
• Capture the observed transcript-to-roster edge, including the IDs and timestamp of the faulty binding.
• Rebuild the edge from the meeting record and retain enough evidence for an independent reviewer to repeat the decision.

Which roster belongs to the accepted transcript?

The authoritative roster is the roster tied to the same meeting or conference record as the accepted transcript, with participant sessions that fit the transcript window. Do not choose a roster because it has familiar names, more rows, or a nearby import timestamp.

Start with immutable identifiers. Record the transcript resource ID with its hash. Record the provider meeting or conference ID with the roster ID. Record source retrieval time with transcript start and end times. A hash lets you prove that the content stayed the same while its association changed.

Then test time overlap. Google Meet defines a participant session as a unique join or leave session, and assigns a new session ID whenever a user joins a conference, including when that user rejoins from the same device. Treat a person and each of that person's sessions as different evidence objects. Google Meet participant sessions, April 2, 2025 documents this behavior.

• Require an exact meeting or conference ID match when the provider supplies one.
• Check that the transcript window fits inside the authoritative meeting window.
• Check participant session start and end times against the transcript window.
• Use display names only as supporting evidence because names can repeat, change, or be absent.
• Mark the case unresolved if IDs and time evidence disagree. Do not substitute a likely roster.

How should you rebuild the provenance edge?

Create a new explicit association. Do not overwrite the old edge without recording it. The ledger should show both bindings, the evidence used, who made the decision, when they made it, and why the observed binding failed.

Use provider-native identifiers first. For Google Meet, the transcript resource belongs under a conference record, while participant resources and their sessions are also scoped to that conference record. For Microsoft Graph, a call transcript is associated with a scheduled online meeting or an ad hoc call, and attendance records can include an identity and role, along with joining and leaving intervals. Microsoft Graph callTranscript, December 3, 2025 and Microsoft Graph attendanceRecord, December 3, 2025 describe those boundaries.

Make the repaired edge immutable after approval. A later import may add better evidence, but it should create a superseding decision rather than silently alter provenance.

• Write a correction event with the old edge, new edge, evidence references, and approval state.
• Version the roster snapshot used for the correction.
• Attach the transcript hash to the correction event.
• Block any automatic merge that would reattach the transcript solely on display name or email text.

• Require a reviewer when the correction changes an identity-dependent downstream record, including consent, task ownership, CRM contact data, or a customer-facing summary.

Which speaker claims must be corrected after the roster changes?

Correct every speaker-attributed utterance whose label came from the wrong roster. A label is not safe merely because the words are accurate. The identity claim is separate from the transcript text.

Microsoft Graph can return speaker-attributed WebVTT content with speaker tags, but tenant settings can disable speaker attribution and require an unattributed transcript format instead. If attribution is unavailable, keep the text unattributed. Do not infer a speaker from a mismatched roster. Microsoft Graph callTranscript, December 3, 2025

Rebuild speaker labels from the corrected roster and session evidence. If the provider only supplies anonymous or phone participant labels, preserve that limitation. Google Meet participant records distinguish signed-in users, as well as anonymous or phone users, so a display name does not always establish a verified person. Google Meet participants, September 16, 2026

• Remove incorrect person names from quotes, excerpts, and speaker timelines.
• Regenerate attribution-dependent summaries.
• Flag uncertain attribution instead of assigning it to the closest matching attendee.
• Record whether the corrected transcript is speaker-attributed or unattributed.

What happens to consent, summaries, tasks, and CRM claims?

A bad roster can turn a valid sentence into a bad claim about who said it, who agreed to recording, who owns a task, or which contact belongs in a CRM. Review those outputs by dependency, not by convenience.

Consent records need the strictest treatment. If consent was attributed to a person from the wrong roster, mark the consent claim unresolved until the corrected attendance and session evidence supports it. Do not carry the old status forward because the transcript text itself did not change.

Summaries should be regenerated if they make participant-specific claims, such as assigning positions, attributing objections, stating commitments, or identifying the next speaker. Tasks must be reassigned or reopened when their owner came from the bad roster. CRM writes need correction when they created or updated a contact, meeting activity, owner, stage note, or relationship based on the wrong identity.

• Speaker claim: either replace it or remove it; otherwise mark it unattributed.
• Consent claim: revalidate from the corrected binding or mark unresolved.
• Summary claim: regenerate when it contains participant-specific statements.
• Task claim: correct ownership and assignee details, due context, and linked meeting evidence.
• CRM claim: reverse or amend identity-based updates and retain the correction trail.

How do you retest the corrected record?

Retest from the corrected association outward. First verify that the transcript ID, hash, meeting ID, roster ID, and participant session evidence all appear together in the ledger. Then run downstream jobs in a controlled order: attribution and consent checks, followed by summary generation, task creation, CRM synchronization, and notifications.

Compare each rerun against the old outputs. The target is not identical wording. The target is that no output still relies on the rejected roster edge. Store rerun IDs and approval evidence next to the correction.

Do not close the incident because a job completed successfully. Close it when a reviewer can trace every person-specific claim in the accepted outputs to the corrected meeting and roster evidence.

• Verify the transcript hash did not change.
• Verify the corrected meeting and roster IDs are used by every rerun.
• Search generated outputs for names and IDs from the rejected roster.
• Check that unresolved attribution or consent remains visibly unresolved.
• Approve the ledger only after all affected outputs pass review.