AI meeting notes with timestamps: how we pick each moment

We never ask the language model what time something was said. Asked for a time, it can write one that looks right and isn't, and a wrong timestamp is worse than none, because people stop checking. So our AI notetaker timestamps follow one rule: the model picks a line, the server checks it.

A timestamp is only useful if it lands on the line the note came from; that is the whole point of a note that points back to the recording. Here is how ours are chosen and checked (sources read 21 October 2026).

Why AI notes get timestamps wrong

AI notes get timestamps wrong in three ways: they cite a source that doesn't back the claim, invent a time, or land one line off. These studies explain the risk; none measures a notetaker.

• Unsupported citations. Auditing four generative search engines (not meeting tools), Liu, Zhang and Liang found "a mere 51.5% of generated sentences are fully supported by citations and only 74.5% of citations support their associated sentence." (arXiv 2304.09848, 2023)
• Invented times. A preprint notes that asking the model to generate a timestamp "can produce unsupported or invalid timecodes." (Yılbırt, Litvak and Färber, arXiv 2606.20890, June 2026) If you prompt a chatbot yourself, give it a timestamped transcript and ask it to copy the time of the line each point comes from, as our minutes prompt that cites each line's timestamp does, then check that each time exists.
• Near misses. "Off-by-one errors form a distinct category, showing models understand the task but misplace boundaries." (McCammon, arXiv 2511.11594, preprint, 2025)

Simon Willison, testing a model on a 3.5-hour council meeting, judged that a transcript that wasn't close to an exact match, with incorrect timestamps, meant "it's very hard to trust the output." (Hacker News, 18 November 2025)

Step 1: number every line, and let the model pick one

The model sees the transcript as numbered lines, one per stretch of speech (a segment), each with its time and speaker. It answers with a line number, never a time:

L21 [02:14] Omar: A prepaid block of five hundred hours with a ten percent discount, valid for twelve months.

Every bullet, decision, open question and action item must carry a line: a whole number that the reply's required format (its JSON schema) demands. One note in the reply looks like this (the text is from our sample meeting's notes, which we wrote by hand):

{
  "text": "Proposal: a prepaid block of 500 hours at 10% off, valid for 12 months.",
  "line": 21
}

Notes are written per chapter, from that chapter's lines only; a merge step then writes the overview, decisions and open questions, each still citing a line. Why: "Lost in the Middle" found that, on average, performance "significantly degrades when models must access relevant information in the middle of long contexts" (Liu et al., TACL, arXiv 2307.03172). That motivates the design; it doesn't prove it for meetings.

Yılbırt, Litvak and Färber's Topic-to-Timestamp preprint reached the same idea independently: the model selects a timestamped chunk of transcript instead of writing a time. On "420 topic-timestamp queries from 200 municipal meeting transcripts", the share of queries where the right moment fell inside one of the top five chunks (their Recall@5) rose "from 31.9% to 50.0%". That is a different task, and those are their numbers, not ours.

Step 2: the server checks the line against the note's words

The server keeps the model's line when the words roughly agree, and moves it only on clear evidence:

1. Normalise. Lowercase, Arabic-Indic digits to 0 to 9, accents and Arabic diacritics removed, أ إ آ ٱ folded to ا, ى to ي, ة to ه.
2. Keep key words. Arabic prefixes such as ال and و are stripped. A word counts if it is longer than two characters or has a digit, and isn't on a seven-language stop list: "all" and "are" count; "agreed" and "discussed" don't.
3. Score. +1 per shared key word, or +3 instead if the word has a digit, because numbers are strong evidence.
4. Decide. Keep the citation if any line from two before to three after it scores 2 or more, so an off-by-one pick survives. Else move to the best line if it scores 4 or more (earliest on a tie). Else keep the model's line. A line that doesn't exist counts as no citation.
5. Scope. Chapter bullets and action items are checked within their chapter, the rest across the call. With no result, a note keeps the model's line if it exists anywhere in the call, else the chapter start, or 0:00.

Simplified from our code (the comments repeat the rules):

function anchorLine(lines, note, cited) {
  const n = lines.length;
  const bad = cited !== null &&
    (cited < 0 || cited >= n);
  if (bad) cited = null; // no such line
  const want = keywords(note);
  // nothing to check with
  if (want.size === 0 || n === 0) return cited;
  // +1 a word, +3 a word with a digit
  const scores = lines.map((line) =>
    overlap(want, keywords(line.text)));
  if (cited !== null) {
    // two lines before to three after
    const near = [-2, -1, 0, 1, 2, 3]
      .map((d) => cited + d)
      .filter((i) => i >= 0 && i < n);
    const best = Math.max(
      ...near.map((i) => scores[i]));
    if (best >= 2) return cited; // keep
  }
  const top = Math.max(...scores);
  // clearly better line: move
  return top >= 4
    ? scores.indexOf(top)
    : cited;
}

Our call: keep a weak citation rather than move it on thin evidence, so moving (4) needs more than keeping (2).

Our test case, traced score by score

This is one of our unit tests, with a seven-line transcript we wrote for it. The note "Proposed a prepaid block of five hundred hours at a ten percent discount." cites line 0, wrong on purpose. Scores are what the function returned on 21 October 2026:

Line 0's window (lines 0 to 3) scores 0. Line 4 shares eight of the note's nine key words (all but "proposed") and gets the citation.

Three more cases from the same file:

• "General agreement." cited at line 6 stays there, since neither word appears anywhere.
• The same note cited at line 99, which doesn't exist, comes back as no line.
• The Arabic note "باقة مسبقة الدفع 500 ساعة مع خصم 10٪", cited at line 0, moves to "عرضنا باقة مسبقة الدفع من ٥٠٠ ساعة بخصم ١٠٪." with a score of 10: four words plus two numbers, which match because ٥٠٠ and ١٠ become 500 and 10. "خصم" and "بخصم" don't match, though.

One note from our sample meeting, played

Here is one note from a sample meeting we wrote and voiced with text-to-speech for our demo; the people, the client and every number are invented. It is the sample sync we wrote up as minutes, notes and a transcript; the deal is meeting content, not our pricing.

2:14, Omar: "A prepaid block of five hundred hours with a ten percent discount, valid for twelve months."

The note (Client pricing): "Proposal: a prepaid block of 500 hours at 10% off, valid for 12 months."

We wrote the sample's notes by hand, then ran our check on this one (21 October 2026). Cited at 2:14, it scores 5 (prepaid, block, hours, valid, months) and stays. Cited at the chapter's start (1:49), its window scores 0 and it moves to 2:14.

No number matched, though: "500", "10%" and "12" aren't "five hundred", "ten percent" and "twelve". Words saved it; a note of only numbers wouldn't have moved.

Clicking the 2:14 chip, the small time label beside the note, plays the recording from that line's start, and the chip lights up while the line plays. A meeting link can carry the time too: add ?t= and a number of seconds, and the page opens the recording at that point. So timestamped meeting notes linked to the recording come down to two things: a line's start and a jump to it.

In MeetNotely, notes with a timestamp on every line, decision and action item all work this way; the whole flow from recording to notes shows where this step sits.

Answers from Ask follow a stricter rule

In Ask, where you question a meeting, an answer cites a passage: a stretch of transcript retrieved for that question. A time the model gives is trusted only inside the passage it cites (5 seconds of slack) and snapped to a line's start; otherwise the passage's start is used. Citations that point at no passage are dropped; in one run of eight questions (9 October 2026), none had to be.

What this check can't catch

Shared words don't make a note true:

1. Words, not meaning. "500" and "five hundred" don't match; nor do paraphrases or synonyms.
2. Where, not whether. A note that turns "probably Thursday" into "Thursday" keeps its citation. You still have to listen, and that listening is a ten-minute check of the lines people act on.
3. No cross-language match. An English note about a Spanish line shares no key words unless names or numbers match, so the check has little to go on.
4. Lenient on purpose. Two points in a six-line window keep a citation, and a note that sums up several moments still points to only one line.
5. The line's start, not the word. The time is the line's start as the speech-to-text step timed it; if that timing drifts, so does the chip. On a long line, the chip can also start seconds before the words in the note.
6. Only as good as the transcript. Misheard names and numbers can't match. If names keep coming out wrong, score the transcript with word error rate before trusting any timestamp; a short clip is enough.
7. Not who said it. The check reads a line's words, not its speaker, so a line given to the wrong person keeps its citation; how speaker labels get mixed up shows why.

Measured so far: in our evaluation on four scripted sample meetings (8 and 9 October 2026), every bullet cited a line that exists, which the fallback nearly guarantees. How often citations move on real meetings, and how often a moved one is right, we haven't measured.

Questions people ask

Why don't AI notetakers just ask the model for the timestamp?

A model asked for a time can produce "unsupported or invalid timecodes", as one preprint puts it. MeetNotely has the model pick a numbered line instead, which limits it to times that exist.

Can a timestamp be right while the note is wrong?

Yes. MeetNotely's server checks that the note and its cited line share words, not that the note means what was said. Play the moment before acting on it.

Does it work for Arabic meetings?

Yes, with limits. MeetNotely's check normalises Arabic letters, diacritics and digits, and our tests include an Arabic case, but it can't compare an English note with an Arabic line.