← Advanced course and all videos

Video 38 of 53 · 3:13 · Applications, benchmarking and evidence

Binding a video to its evidence

In this video

  1. 0:00 · Introduction
  2. 0:16 · Follow a number from data to narration
  3. 1:12 · Core explanation
  4. 2:10 · A matching hash cannot verify arithmetic
  5. 3:02 · Direct takeaways

Caption transcript

Show transcript
This overview explains how source identities connect to claims, narration, captions, scenes, and rendered outputs. A changed dependency can make downstream content stale even when another part of the evidence remains unchanged. Use a fictional two-row table with values eight and twelve. The chosen summary is the arithmetic mean, so add the two values and divide by the number of rows. This simple example makes the evidence dependency explicit. The mean is ten. A claim card records that value with its input identities and calculation rule. A narration cue and a visual scene can then display the same claim. Each depends on the derived value rather than on a hand-typed unrelated number. Change the second row to sixteen. The mean becomes twelve. The old claim card, narration cue, and displayed number now refer to the previous source. Create successors for those dependent artifacts while preserving the earlier version and its provenance. Follow a dependency from source path, locator and hash to a claim, spoken cue, scene, chapter contract and output. Each transformation needs an identity so a changed source can invalidate dependent work precisely. Imagine one retained CSV supporting a ratio in two episodes. Change that CSV while leaving an unrelated operator proof untouched. Both measured claims need revalidation; their dependent scenes and chapters need new identities. The mathematical proof does not become false because an unrelated timing file changed. Preserve the old outputs as historical artifacts and link their successors. A hash establishes an identity comparison, not mathematical truth or approval. Content adoption and production authorization are separate records. Suppose a file incorrectly states that the mean of eight and sixteen is eleven. Two exact copies can have matching hashes. The hash confirms byte identity, including the mistake; it does not evaluate the formula. Independently recomputing the arithmetic reveals twelve, so the claim of eleven is wrong. Provenance and correctness support each other but are different checks. Both are needed for a trustworthy reproducible explanation. Only artifacts that depend on the changed table need that data correction. An independent Boolean identity proof can remain valid. Track editorial adoption, production completion, and owner acceptance separately so that a generated file is not mistaken for an approved final master. Bind the rendered output to its actual inputs and tool versions. A matching hash establishes identity, not mathematical truth or approval.