LEE-ISMS

A curation engine, not a writing engine. It finds passages from what was actually said, reproduced unchanged from the available captions, with a receipt you can click, and it tells you when it doesn't know.

Engine: LIVE
— videos
— passages
Runs on a private server I operate — public YouTube material only
Demo corpus = Lee's public YouTube videos only, harvested from the open @HoldenQiGong channel. Nothing private has been touched: the course transcript library plugs in only after written authorization. Every receipt below jumps to the exact second of the real video.
▸ THE LEE-ISMS GLOSSARY: phrases he keeps saying, counted across all 50 videos
How the matching works

Every passage gets a meaning fingerprint. A small AI model on this server reads each transcript passage once and turns it into a list of 1,024 numbers. Passages that mean similar things get similar numbers, even when the words are different. Your question gets the same treatment.

The match score compares fingerprints. The number next to each passage (like match 0.66) says how closely the passage's meaning lines up with your question. 1.0 would be a perfect overlap. Nothing here searches keywords, so "healing sounds" can find a passage that never uses either word. Similarity measures closeness to the stored captions, not factual truth, and not creative fit.

The engine refuses instead of guessing. Every search lands in one of three honesty bands, based on the best match found:

below · returns nothing
warns
and up · strong match

Ask it something Lee never talked about and it says so. It cannot make up a quote, because it can only return passages that exist. The same floor applies to each passage individually, so a strong answer never drags weak ones onto the page with it.

"Pairs with" is the same comparison between passages. For each result, the engine looks for the closest-meaning passages from other videos. That surfaces cross-connections a person would have to remember. It finds "talks about the same idea." Whether two moments pair well creatively is taste, which is what the thumbs are for.

The thumbs re-rank the current search. Mark a few passages up or down, then re-rank. Passages similar to what you liked get a score bonus and climb. Passages similar to what you disliked get a score penalty and sink, and because only the best few are shown, a sunk passage can drop off the visible list. The arrows on the left show each move. The engine never writes a word: every passage reproduces the available YouTube captions unchanged, and should be checked against the linked video before anything is published.

Honest status: today, taste lives inside one search. The re-rank is real, but the engine does not remember it. Start a new search or reload the page and the taste starts fresh. What you are seeing is the mechanism, demonstrated live. Where it goes next is the section below.

Honest limits today: the corpus is public videos with YouTube auto-captions, so transcription errors like "chiong" for qi gong come from YouTube, not from Lee. Proofread transcripts would remove those.

Taste that remembers: the pilot feature ROADMAP · NOT RUNNING TODAY

Everything above works now, but forgets. The pilot version remembers. Here is how it would work, step by step.

1. Every thumb gets saved under a name. When Joey thumbs a passage, it lands in Joey's pile. Jeffery's calls land in Jeffery's pile. Two people, two piles, they never blend, because what makes the save-worthy cut for an editor is not what makes it for the person writing the emails. And it is not capped at two: if more reviewers should have a say, each one gets their own pile at the pilot stage.

2. Each pile becomes a taste direction. Every saved thumb already has a meaning fingerprint (the same 1,024 numbers from the section above). The engine averages the liked ones into a "more like this" direction and the disliked ones into a "less like this" direction. That pair becomes a simple personal ranking signal, not a complete model of the person's taste.

3. Every future search starts pre-sorted. You ask a new question next week. The engine finds the matches as usual, then applies your standing ranking signal on top, the same bonus-and-penalty re-rank you can try live today, applied automatically, before you touch a single thumb. Down-ranked passages sink, and because only the best few are shown, they can drop off the visible list. Nothing is deleted from the corpus.

4. The page always says whose taste is on. A visible label, something like: ranked with Joey's taste, 14 calls remembered. One click switches the person or turns taste off to see the raw ranking. No silent filtering, ever.

5. It accumulates more examples. Every session's thumbs join the pile. The pilot would measure whether those examples actually improve later rankings, that is a hypothesis to test, not a promise. And because the pile is just a list of your own past calls, you can open it, see every thumb, and remove one you no longer stand behind. The signal is inspectable, not a black box.

Why it is not in this demo: remembering taste means storing people's judgments, and that belongs inside an agreed pilot, not a public-video demo. The mechanism it builds on is the one you can already try above.

Directed pairing: you pick the anchor PASTE-A-LINE SEARCH WORKS TODAY · PASSAGE-ANCHOR PAIRING IS A PILOT FEATURE

The "pairs with" chips under each result are automatic candidates: cross-video passages nearest in meaning, offered for an editor's judgment, not answers. Directed pairing flips the direction. You choose the anchor, and the engine returns the cross-video candidates nearest in meaning to it.

Two ways to aim it. Paste a line you already have, a quote from the email backlog, a sentence from a brief, into the search box and get back candidate Lee moments, receipts attached; that works today. One-click anchoring from any passage is the pilot version. Either way the candidates are raw material: which pairing actually works is an editorial call.

Straight to the timeline: the pilot feature ROADMAP · NOT RUNNING TODAY

The pull list below copies your thumbed-up passages as text. Someone still has to go find that footage. This version hands the editor a file that opens as a timeline.

1. The thumbs become an editor file. Every passage already knows its video and its start and end time, that is what the receipts under each result are made of. Those become an XML file that Premiere imports directly, using the Final Cut Pro 7 interchange format Adobe supports.

2. The file points at the masters, it never contains them. It is a few kilobytes of text holding one file path per clip plus in and out points. No video moves and no video is copied. If a path is wrong the editor right-clicks once and relinks.

3. The editor opens it and scrubs. Each thumbed moment arrives as its own clip in a bin, labelled with the passage it came from. Their first action is watching, not searching.

4. It never assembles the cut. The system hands over candidates in a bin. It does not lay a sequence, choose an order, or make an edit. That call stays with the editor, the same as every other judgment call in this system.

What it needs first. Two things. The masters reachable as files on disk, Joey’s raw footage in Google Drive already is, once it syncs to a folder. And their frame rate, because this engine counts in seconds and the editor file counts in frames. Guess the frame rate and every marker drifts further the longer the clip runs.

One thing to check before promising it. These timecodes come from the public versions. If the Drive masters are a different edit , a different intro, a different trim, every timecode is offset from them. That is measured once per video and corrected, or the transcripts get rebuilt from the masters. It is a known step, not a surprise, and it is worth an hour of checking before anyone commits to a turnaround time.

Why it is not in this demo: it needs your media, and no source material has been requested or received. The timecodes it would use are the same ones already showing on every result above.

0 marked