Short summary cards connect to colored passages on a video time line. One unsupported card waits for review.
Check each summary claim against its source passage.

The main condition is that captions represent speech, not all on-screen evidence. A diagram, code change, gesture, or silent demonstration may be essential. Inspect that part of the video before including a visual claim. The caption Actor does not inspect frames or create the summary. A scraper tool collects caption rows, but the reader does the manual work of checking technical video notes.

Understanding the Transcript Tool and Limits

An Actor is a hosted data collection program. A Task is a saved input preset. You can view the saved preset at YouTube Transcripts for LLM Analysis and the main tool at YouTube Transcript Scraper. The default text+llm preset has no timed segment evidence. You must add json to preserve segment times.

Exact source fields include videoId, videoUrl, transcriptLanguageCode, isAutoGenerated, segments, text, llmText, status, and scrapedAt. Each segment has startSeconds, endSeconds, durationSeconds, and text. A successful unique video creates one row, not one summary.

The tool provides direct known public video URLs and IDs only. It does not provide audio transcription, video search, channel collection, translation, visual analysis, or model invocation. Use one video first. Leaving preferredLanguages empty selects an available track. A chosen unavailable language fails rather than returning a translation. Missing caption source, auto-caption error, or absent visual detail can limit the answer. The transcriptSpanSeconds and videoCoverageRatio fields do not measure faithful meaning. Preserve the original row before notes or model input.

Complete Method for Checked Summaries

  1. Write the purpose: Write the purpose of the summary and the intended reader. Choose what they need to know after reading. A study note and an executive decision note may retain different details; neither can invent a conclusion.
  2. Acquire the transcript: Acquire the readable transcript plus JSON timing. Review source identity, language, and failure status. Scan the start, middle, and end for obvious caption defects. Mark unclear words rather than silently fixing them.
  3. Map the main points: Read the whole transcript once. Make a main-point map with claim, source range, required condition, example, and any visual check needed. Repeated claims can be combined, but their meaning and conditions must remain. Keep two unrelated source ranges distinct rather than inventing a continuous support interval.
  4. Draft the summary: Draft your summary yourself or ask a chosen language model to use only those source passages. This is a separate reader step. A prompt can require the main point, condition, source range, and 'not supported' when text is missing. It cannot guarantee accuracy. Keep personal or confidential source data out of tools that are not authorized to receive it.
  5. Compare sentences: Compare every summary sentence with the source. Mark supported, changed meaning, missing condition, or no support. Check numbers, negation, uncertainty, and who made the claim. Do not turn one speaker's proposal into a proven general fact.
  6. Check main points: Check each main point against the summary, not only each summary sentence against the transcript. Sentence support finds invented claims; main-point coverage finds important omissions. Both checks are needed. Check source visual scenes when a caption points to them.
  7. Revise the summary: Revise the incorrect sentences and add omitted central points. Keep the final note shorter than the source only when it still serves the purpose. Do not add invented precision or generic background to make it longer.
  8. Save the final note: Save the final summary plus a small source-support table. If a point cannot be checked, keep it uncertain or exclude it. The final action is a checked note with passage pointers, not an accuracy percentage promised by a model.

A cache is stored data kept for reuse. A stale value is a stored value older than a changed source. Expiry is when stored data must stop being reused under that rule. A cache hit is a request served from stored data.

Fictional Worked Example

To show how this method works, here is a fully fictional five-minute teaching video. All spoken text, video identity, times, and summary scores are invented.

  • Part 1 at 00:20–00:45: 'Use a local cache for repeated reads when stale data is acceptable.'
  • Part 2 at 01:10–01:35: 'Set an expiry time. The right time depends on how fast the source changes.'
  • Part 3 at 02:00–02:20: 'Remove a cached value after a confirmed update. Expiry alone may be too slow for that case.'
  • Part 4 at 03:00–03:25: 'Track cache hits and stale responses separately. More hits do not prove correct answers.'
  • Part 5 at 04:10–04:30: 'For our small demo we use ten minutes. That is an example, not a rule for every system.'

The reader's purpose is to understand when the method is safe. The main-point map keeps four decision points: stale-data condition (Part 1), expiry depends on source change (Parts 2 and 5), confirmed-update removal (Part 3), and hits versus stale responses (Part 4). Parts 2 and 5 use two distinct source ranges (01:10–01:35 and 04:10–04:30), never a continuous 01:10–04:30 support passage.

A bad fictional draft might say: 'Use a cache for all reads. Set expiry to ten minutes. A high hit rate proves the cache works.' It changes Part 1 by dropping the condition, turns the demo time into a universal rule, omits Part 3, and contradicts Part 4. It is fluent but unfit for the stated purpose. Do not report all three sentences as supported just because they share source words.

A completed revision says: 'A local cache can reuse repeated reads when stale data is acceptable. Choose expiry from the source's rate of change; ten minutes was only the demo choice. Remove a cached value after a confirmed update when expiry would be too slow. Track hit counts and stale responses separately, because more hits do not prove correct answers.'

Attach Part 1, Parts 2 and 5, Part 3, and Part 4 pointers to these four claims in the support table.

Fictional Worked Example
Revised ClaimSource Range(s)Required ConditionSupport Result
A local cache can reuse repeated reads when stale data is acceptable.00:20–00:45Stale data is acceptableSupported (Fixture P1)
Choose expiry from the source's rate of change; ten minutes was only the demo choice.01:10–01:35 and 04:10–04:30Expiry depends on source change rate; 10 min is demo onlySupported (Fixture P2 and P5)
Remove a cached value after a confirmed update when expiry would be too slow.02:00–02:20Confirmed update occurs and expiry is too slowSupported (Fixture P3)
Track hit counts and stale responses separately, because more hits do not prove correct answers.03:00–03:25Hit counts and stale responses tracked separatelySupported (Fixture P4)

Fictional Check Table

Fictional Worked Example
Check MetricValue
Main points required4
Present with condition in bad draft0
Present with condition after revision4
Coverage score (bad draft)0/4
Coverage score (revision)4/4

Coverage of 0/4 versus 4/4 is only this invented checklist, not a model accuracy score, real benchmark, or proof of the complete five-minute video. Sentence-support review after revision shows 4 of 4 supported under this fixture. Visual claims equal 0. No external benefit, speed claim, or measured customer result follows. The final note uses the corrected four statements and the separate passage ranges. Preserve the main-point map so another reader can review it.

Sources & further reading

By Chronometrica · Updated

Back to top ↑