What Recall Is

"Where did I say that?"

The Question That Built an Engine

Dad has thousands of videos. Years of talking to a camera — teaching, thinking out loud, telling stories. Somewhere in that pile is the exact two minutes where he explained a specific idea, in specific words, and he wants to use it again. A folder can't answer that. Even a folder with perfect filenames can't answer "where did I say the thing about the afogato being a dot product?" Files know their names. They don't know their contents.

Recall is the engine that makes a video archive answer that question. Point it at the archive and it inventories every video, turns speech into searchable text, remembers the exact timestamp of every sentence, and — this is the part that matters — opens the original video at that second so you can actually use the moment you found.

Search Is an Editing Workflow, Not a Text Lookup

This is the reframing the whole product hangs on. In most tools, search returns text and you're done. In Recall, a search hit is a doorway back to the source. Every hit carries the video's identity and an absolute timestamp, so a single click can open the original in a player and seek to the exact second, or reveal it in Finder to drop into a video editor. The transcript isn't the deliverable — it's the index into memory. The deliverable is the frame you were looking for.

That one decision ripples everywhere. It's why timestamps have to be exact and absolute. It's why a hit stores a video identity, not a copy of text. It's why the browser is never allowed to hand Recall a file path (Track 7 shows the security seam that grows from this). Hold the idea: you are not searching text; you are searching your own memory, and the answer is a place in a video.

What Recall Owns

An engine is defined by what it owns, not by what it shows. Recall owns:

Inventory — which videos exist, where, and whether they've changed.
Evidence — immutable speech-to-text output, treated as a permanent record (Track 3).
Releases — versioned, correctable transcripts derived from that evidence.
Search — a timestamped full-text index over the current release of every video.
Summaries and titles — derived artifacts that always name the exact transcript they came from.
The handoff — opening the source video at the hit for editing.

The web console — Overview, Archive, Search, Word Cloud, Operations, Video Detail — is just the first client that talks to that engine. Swap the console and the engine is unchanged. The model is the product.

Code

A search hit is a doorway, not a paragraph (shape sketch)·json

{
  "video_id": "stable-archive-id",
  "source_id": "cwk",
  "path": "2026/07/talk-about-dimensions.mov",
  "timestamp_ms": 754000,
  "text": "...an afogato is really a dot product of food...",
  "content_sha256": "release-content-hash",
  "rank": 1
}

// The text tells you what was said.
// The video_id + timestamp_ms let you OPEN the video at 12:34
// and actually use the moment. The text was only ever the index.

Exercise

Think of a personal archive you own that you can't actually search — a photo library, years of chat logs, a folder of recordings, a pile of notebooks. Write down one real question you'd ask it ("when did I first mention X?"). Then decide: is the answer you want a piece of text, or a place you'd want to jump back to? Notice how often the honest answer is 'take me back to that moment,' not 'show me the words.'

Hint

If the useful answer is 'open it right there so I can use it,' then your archive doesn't need a search box — it needs an index that remembers where things are and a doorway back. That's the difference between a transcript tool and a memory engine.