DEV Community: Yana Li

Subtitle readability: why a valid file can still be unreadable

Yana Li — Tue, 21 Jul 2026 03:21:17 +0000

I publish the same scripted show in five languages: Spanish, English, Japanese, German, and Chinese. Every episode ships with subtitles, and every language has taught me the same lesson from a different angle: a subtitle file that passes every technical check can still be genuinely hard to read.

Validators catch broken timestamps, overlapping cues, and malformed syntax. Those checks matter, and you should run them — a free subtitle checker does it in your browser in seconds. But validators catch none of the things that actually make viewers give up on subtitles. Those live in a different layer, and this article is about reviewing that layer without any special tooling.

The validation gap

A subtitle file is two promises at once. The first is technical: timestamps are legal, cues do not overlap, the syntax parses. The second is human: a person watching at normal speed can read every line comfortably while also watching the video.

File formats only encode the first promise. Nothing in SRT or VTT stores "this line is comfortable to read." That is why a file can be simultaneously perfect and unusable, and why the readability layer needs its own review.

Four failure modes account for almost everything I catch in my own episodes.

1. Line breaks that fight the sentence

A subtitle line is not a text box that happens to wrap. Where the line breaks is where the viewer's eye pauses, and a break in the wrong place makes the brain re-parse the sentence.

Bad break:

He said he would never
sell the company.

Better break:

He said
he would never sell the company.

Same words, same timing, same valid file. The first splits "never sell" across a visual boundary right at the point of emphasis. The second breaks at a natural speech pause.

The check: scrub through the video and read only the line breaks. If a break lands inside a tight phrase — verb and object, negation and verb, a name and its title — fix it. Most auto-generated subtitles break lines purely by character count, so this check almost always finds something. When the problem is mechanical (a long line that just needs re-wrapping at word boundaries), the line break rewrap guide shows what can be fixed automatically without touching timestamps.

This gets harder outside English. German compounds resist breaking. Japanese and Chinese have no spaces, so a naive break can split a word in half without anything looking wrong to a validator.

2. Reading speed the eye cannot match

Every serious subtitling operation sets a reading-speed ceiling. Netflix's English style guide caps adult programming at 20 characters per second and children's content at 17. Broadcast practice has long worked to a similar ceiling expressed differently, commonly around 160–180 words per minute. For dense scripts like Japanese, the limits are tighter still — Netflix's Japanese guide works with much shorter lines because each character carries more information.

Two things follow from those numbers. First, the exact threshold is a style decision, not a legal one: WCAG requires captions to be synchronized and equivalent, and it deliberately does not set a characters-per-second figure. Second, whatever ceiling you choose, the failure mode is identical — a line flashes by faster than a person can read it, and the viewer either rewinds or gives up.

The check: find your three fastest lines. They cluster in predictable places, where the narration accelerates or where two sentences got merged into one subtitle. Play those spots at normal speed with the audio muted and try to read your own subtitles cold. Muting matters: when you can hear the narration you already know what the line says, and you will believe it is readable when it is not.

3. Rhythm: lines that flash or linger

Reading speed has a partner problem that gets less attention: display rhythm. A line that is on screen for 500 milliseconds registers as a flicker even if it is only one word. A line that lingers for eight seconds makes the viewer read it twice and wonder if playback froze.

The mechanical half of this is checkable — minimum durations, and lines too short to read, are exactly the kind of thing a pre-export review should flag. The editorial half is not: sometimes a one-word subtitle deserves to stay long for emphasis, and sometimes it should be merged into its neighbor. A tool can point at the anomaly; deciding is your job.

4. Subtitles that compete with the picture

The fourth failure mode has nothing to do with the subtitle file at all. Subtitles sit on top of a picture that often contains its own text: titles, lower thirds, on-screen quotes, interface recordings. When the subtitle and the picture demand the same eyeballs at the same moment, the viewer reads neither.

The check: watch the video once paying attention only to the bottom third of the frame. Note every timestamp where a subtitle overlaps burned-in text, a chart label, or a face during a moment that matters. Sometimes the fix is repositioning, sometimes it is shifting a cue by half a second, and sometimes it is a note to future-you about where not to put on-screen text.

Why this layer gets skipped

Nobody owns it. The editor treats subtitles as an export setting. The captioning tool never sees the final picture. The reviewer checks that subtitles exist and match the words. Readability falls between those chairs precisely because it requires looking at the words, the clock, and the picture at the same time — which is exactly what none of the individual tools do.

There is also a deeper reason: most subtitle problems enter the file before readability is even in play. If the text itself was produced by speech recognition guessing at your words, you are proofreading a transcription before you can even think about line breaks — the auto captions accuracy guide covers why that happens. Starting from the approved script instead, with forced alignment deriving only the timing, removes the wording problem entirely and leaves readability as the one human layer left to review.

The ten-minute review

Pulling the four checks together:

Breaks pass. Scrub and read only the line breaks; flag any break inside a tight phrase.
Speed pass. Find the three fastest lines; play them muted at normal speed and read cold.
Rhythm pass. Look for flickers under a second and lingerers past several seconds; merge, split, or retime.
Picture pass. Watch the bottom third once; note every collision with on-screen text or faces.

If you publish in more than one language, run it per language. The failures move around — my German lines run long, my Chinese lines run dense — and that movement is the most convincing evidence I know that subtitle readability is a design problem, not a file-format problem.

The compact checklist version of this review lives in the caption readability check guide, and the five-language production story behind these lessons is its own article. For the mechanical layer — validation, long lines, format conversion — the free browser tools handle it locally without an account.

Stop AI Video Pipelines Before a Bad Render Gets Expensive

Yana Li — Tue, 14 Jul 2026 11:49:44 +0000

I was testing a faceless Shorts pipeline when a job reached the end without producing a video I wanted to publish.

The incidents and measurements here come from my own build records. I checked every technical claim against those records before including it.

Nothing had crashed. The script had become narration, the images had become scenes, and the scenes had become an MP4. The failure was less convenient: the visual direction changed from scene to scene, so the video felt assembled rather than directed.

That is a difficult failure to represent in a generation system. A worker sees completed jobs. A creator sees a video that does not belong on their channel.

The fix was not another retry button. I needed review gates that could stop the pipeline while the wrong decision was still cheap to change.

A successful job can still be a failed outcome

A basic AI video pipeline is easy to draw:

prompt
  -> script
  -> voice
  -> images
  -> captions
  -> render
  -> export

Each step can be healthy in isolation. The script can match its schema. The voice provider can return audio. Every image request can succeed. The renderer can exit with code 0.

None of those checks answer the creator's question: would I publish this?

The pipeline therefore needs two kinds of validation:

machine validation for shape, availability, duration, and state
human review for taste, coherence, and publishing risk

Treating the second kind as a final QA task is expensive. By then, every downstream artifact depends on a creative choice that may already be wrong.

Put gates before irreversible work

The useful gate is not simply "ask the user for approval." It has to accept a specific artifact and control which work is allowed next.

I now think about four checkpoints.

Gate	Accepted artifact	Decision	Work still blocked
Direction	Hook and script	Is this idea worth producing?	Voice, images, rendering
Visual plan	Scene list and visual intent	Will these scenes feel like one video?	Final keyframes and motion
Timing	Real narration duration	Does the script fit this voice and target length?	Full visual generation
Final preview	Rendered MP4, cover, metadata	Would the creator publish this version?	Export or upload

The table matters because "review" is otherwise too vague. If the user approves a script but the worker later renders a regenerated script, the UI gate is theatre. The accepted artifact must be the artifact used downstream.

Real voice timing broke my estimate

One sample made the timing gate concrete.

The script contained 127 words and targeted a roughly 50-second Short. After segmented voice generation, the narration lasted 59.08 seconds.

At that point the system had enough evidence to stop. Generating images, transitions, captions, a cover, and a final MP4 would only have wrapped more work around a duration I did not want.

I changed the script target and voice route before image generation.

The broader calibration made a single words-per-second constant look even less useful. Across five sample niches, the same voice ranged from 2.08 to 2.70 words per second. A suspense script with short lines and dramatic pauses reached 62 seconds against a 50-second target.

Sentence structure, punctuation, niche, and delivery style all changed the result. The correct validation point was not the initial word count. It was the real audio artifact.

This also changed the retry rule. If timing fails, rerunning the renderer is not a retry. It is repeating unrelated work. The pipeline should return to the script or voice decision that produced the timing failure.

Invalidations should travel downstream

Review gates only work when changes invalidate the right artifacts.

A few examples:

editing the script invalidates voice timing, caption alignment, visual beats, and the final render
changing the voice invalidates timing and caption alignment; if the new voice changes the accepted pacing window, it also reopens script acceptance
changing visual direction invalidates keyframes and motion planning, but should not force a new voice
changing one scene should allow a scene-level retry instead of rebuilding the entire video
choosing a different final cover should not invalidate the MP4

This is where a review-first product becomes a state-management problem.

The orchestration layer needs durable artifacts and explicit statuses, not a single generation_progress number. A useful record says which version of the script produced which audio, which timing manifest produced which visual plan, and which scene failed.

Without that lineage, partial retry becomes guesswork. Worse, the interface can show an approved state while the worker is rendering stale inputs.

Schema validation is necessary but not enough

Structured outputs still matter. A script package should fail fast if it is missing a hook, scene list, visual intent, target duration, or other required fields.

But a schema cannot tell you that five valid images look as if they came from five different videos. It cannot tell you that a clean voice is emotionally flat for the story. It cannot decide whether a creator is comfortable putting the result under their own name.

Those are not excuses to make every pipeline manual. They are reasons to place human attention at the few decisions where it changes the cost of everything after it.

When I would skip the review gate

This pattern is not automatically better.

I would consider fewer gates when the output is disposable, regeneration is nearly free, variation is the point, or the user has already approved a stable template for repeated runs.

I would keep the gates when downstream work is expensive, the output is public, taste matters, or a failure needs a recoverable explanation.

The design question is not "human in the loop or full automation?" It is narrower: which decision becomes costly if it is discovered one step later?

For AI video, I found that hook, visual direction, real timing, and final preview each crossed that line.

Where I am applying this

I am applying this pattern in CreateFaceless, where a creator reviews the script and shot direction before the full media pipeline runs. Real voice timing can stop the job before image generation, and the finished MP4 still needs a final preview before export.

I wrote up the visual-consistency failure and timing measurements in the original CreateFaceless production note. The product is one implementation of the pattern; the review-gate problem is broader than video.

Builder checklist

If you are building a multi-step generation workflow, I would check:

Is the reviewed artifact versioned, or does approval point to a moving target?
Does the next provider call load the accepted version rather than the latest draft?
Which edits invalidate timing, captions, visuals, and the final output?
Can stale input fail before another paid provider call?
Can a retry rerun one failed scene without discarding accepted work?
Does the final public or export action have its own confirmation boundary?

Which artifact would you make the last cheap place to stop?

I Wanted My Pet’s Photo to Dance to the Beat, So I Built a Music Visualizer

Yana Li — Mon, 13 Jul 2026 05:54:00 +0000

This is a submission for Weekend Challenge: Passion Edition.

Disclosure: AI coding and editing tools helped me build and review this weekend project. The demo, screenshots, tests, and product behavior below are from the working app.

I wanted to see whether a still photo could move with music without turning it into a fake talking face. More specifically: could I make a pet photo dance to the beat?

For DEV's Weekend Challenge, I gave myself one weekend to build a music visualizer around that question.

I am working toward a bigger idea: personalized songs and videos for the people and pets we love.

But there was an uncomfortable product question underneath it: if the visual moment is not worth replaying, why build the rest of the pipeline?

So for this weekend I cut the idea down to one photo, one song, and one button.

What I Built

PostLullaby is a browser-only music visualizer for personal photos. Choose a JPEG, PNG, or WebP photo, pick a track, and press Enter the beat. The original photo dissolves into a particle portrait made from its own pixels, then dances to the music through breathing, waves, flashes, and shock rings before returning to the untouched photo.

There are three ways to add a pulse:

Original Spark: a 15-second test track made for the prototype.
Energetic Dance Pop: a 30-second royalty-free preview for a stronger drum test.
Your Song: a browser-supported audio file from your own device.

The last option matters to me. Your selected photo and local song stay in your browser as local object URLs. There is no account, upload, database, analytics event, or server-side media processing in this prototype.

It is not pretending to animate a face. It is the real photo, temporarily redrawn as light.

Demo

Try PostLullaby live — use your pet, your dad, your partner, or anyone who deserves a little main-character energy.

And this is the moment I built the whole spike to test: the dog is still recognizable, but the photo has become a field of particles responding to the song.

A static frame only catches one beat. The live version has sound and pointer interaction, so move your mouse or finger through the portrait while it plays.

For the before-and-after demo images, I used a photo by Kris Tian on Unsplash, available under the Unsplash License. The bundled library track is “Energetic Dance Pop” by Tunetank under the Pixabay Content License; the source and license are recorded in the repository.

Code

🔗 View the source code on GitHub

Live app: postlullaby.vercel.app

How I Built It

The photo becomes particles without becoming fake

When a user selects a photo, the browser decodes the local File with createImageBitmap(). I downsample it once to a small working canvas, read the pixel data, and build a deterministic set of particles.

Each particle remembers:

its home position in the photo;
its real sampled color and luminance;
a small depth value for perspective;
spring velocity and temporary beat displacement.

That gives me a recognizable portrait without generating a new face or inventing motion for the subject. On desktop the renderer uses a denser grid; mobile uses fewer columns to keep the effect responsive.

The beat detector had to learn each track’s personality

The audio path is intentionally small: one HTMLAudioElement feeds one AudioContext, one AnalyserNode, and one animation loop. Every frame I read three energy bands:

const low = averageRange(20, 140);
const mid = averageRange(140, 2_000);
const high = averageRange(2_000, 12_000);

const { beat, intensity } = detector.sample(
  low,
  performance.now(),
);

My first versions treated a beat as “energy above a threshold.” That worked for one clean synthetic kick and failed on a loud, compressed pop track whose low-end energy never dropped very far.

The fix was to anchor detection to the track’s own recent range. The detector keeps a 900ms low-energy window, measures its local minimum and maximum, looks for a fast onset rise, enforces a cooldown, and only rearms after the energy falls enough relative to that same local range.

That was the least glamorous part of the build and the part that made it feel most like music instead of random flashing.

I choreographed a moment, not a screensaver

The visual runs as a short sequence:

The untouched photo settles on the stage.
The first strong beat dissolves it into its own particle colors.
Low frequencies drive breathing, mids drive waves and brightness, and detected beats launch flashes and shock rings.
Near the end, the particles return home and the original photo comes back.

Pause freezes the current frame instead of clearing the canvas. Replay resets the beat detector and choreography cleanly. prefers-reduced-motion keeps the photo visible and swaps the particle movement for a gentler glow.

What I deliberately did not build

The larger PostLullaby idea includes memory prompts, original song generation, export, and sharing. None of that is in this submission.

That is deliberate. A weekend is enough time to validate one risky product question, but not enough time to make an unfinished pipeline look trustworthy. This build asks only:

Does one photo hitting the beat create a moment you want to replay?

For the release check, 25 focused tests passed alongside lint, TypeScript, and the production build. I ran the production build at desktop and mobile sizes, including reduced-motion mode, then verified a real photo upload and playback against the public Vercel URL.

What I Learned

The fun part was not adding more technology. It was making the first three seconds understandable.

The photo stays yours. The music drives something visible. The button does exactly what it says.

If you try it, I would love to know which image you chose. A pet is the obvious answer. A classic photo of your dad is a very good answer. Your partner, your best friend, or a gloriously overconfident childhood photo all count too.

Pick one photo. Pick one song. Watch it dance to the beat — then tell me if you replayed it.

How to Create a Faceless YouTube Channel Workflow (Step by Step)

Yana Li — Sun, 05 Jul 2026 08:50:56 +0000

When people ask for a faceless YouTube channel, the real question is never “which tool,” but:

1) What is my first Short going to prove?

2) Can I review it before money, render time, and upload effort are spent?

3) Is it publish-ready after one loop?

This is a practical guide for how to create a faceless YouTube channel workflow from scratch, focused on review-first production, not autoplay generation.

Fast answer

If you want results, do one publishable loop first:

define a niche and the viewer promise
write one full Short script package
review script and pacing before expensive generation
generate voiceover, timing, captions, and visuals in sync
export one vertical MP4
publish manually after the metadata is coherent (title, description, hashtags, cover)

That is the shortest path to a real working workflow.

The workflow I use (and why this helps)

I keep this simple and strict because most “faceless AI” content fails on timing and review.

Hook with a concrete promise

First 2–3 seconds must explain the viewer’s gain.
Build one complete script package

Include narration, scene intent, cadence markers, CTA.
Review before generating assets

This blocks wasted render cost and rewrites chaos.
Voice + timing manifest

Don’t skip this. Words + timestamps drive all downstream quality.
Visual beats and motion plan

Give every segment a clear duration, shot intention, and transition.
Captions are production, not polish

Keep lines short, mobile-legible, and synchronized.
Music is optional, but never dominant

It should support rhythm, not fight narration.
Export and QA the MP4

Verify rhythm, caption sync, and cover-safe framing in 9:16.
Manual publish package

Copy title + description + hashtags + cover plan together, then upload manually.

How this relates to SEO and retention

For search visibility, people who search how to create a faceless YouTube channel are usually not looking for random theory—they’re looking for a repeatable method.

The method above maps directly to pages you can optimize around:

faceless YouTube education
niche and idea selection
Shorts production rhythm
metadata + caption workflow
publish-ready exports

If you want the page-level version we use in product strategy, use this as the canonical source:
https://createfaceless.com/en/blog/faceless-youtube-channel-starter-workflow

A 12-hour action plan (single Short)

Hour 1: Niche + one promise
Hour 2: Script + review
Hour 3: Voice + timing manifest
Hour 4–7: Visual beats + captions + render plan
Hour 8: First MP4 export
Hour 9: Metadata + cover
Hour 10: QA rhythm and mobile legibility
Hour 11: Final revise
Hour 12: Manual upload with full package

Run this once, measure retention, then batch only after one Short is stable.

I stopped treating AI memory as summaries. I now think in handoffs.

Yana Li — Thu, 25 Jun 2026 14:59:41 +0000

In my last post, I wrote that AI memory should be treated as product state, not as a prompt trick.

After publishing that post, I kept running into the next problem while working on the memory layer:

What should actually be carried into the next session?

That is a different question from what should be stored.

A summary compresses the past. A handoff prepares the next interaction.

That difference matters.

A summary has no reader

A lot of memory systems start from summarization.

At the end of a session, compress the conversation. Save the important parts. Use them later.

That sounds reasonable, but the word "summary" hides a product problem.

A summary does not have a clear reader.

It tries to compress everything for nobody in particular. It often becomes a smaller version of the conversation, with some details removed and some confidence added. But it does not answer the question that matters:

Who is this note for?

If the answer is "the next session," then the artifact changes.

It is no longer just a summary. It is a handoff.

A handoff artifact is written for a future interaction that has to pick up the work without pretending it was there the whole time.

That constraint changes what is worth writing down.

What deserves to be carried forward?

For reflective AI, I do not think the best memory is always the most detailed memory.

The goal is not to preserve everything. The goal is to preserve the few things that would make the next session more respectful, more accurate, or less repetitive.

I currently think there are at least four classes worth carrying forward.

1. Framing-change moments

Sometimes the important thing is not a fact about the user.

It is a shift in how the user understands the problem.

Maybe they came in thinking they needed a feature, and left realizing they needed a boundary. Maybe they started with a vague feeling and ended with a clearer question. Maybe the session changed the shape of the work.

That kind of moment can be worth carrying forward because it helps the next session avoid dragging the user back to an older frame.

But it has to be handled carefully.

A framing shift is not a permanent identity claim. It should not become "the user is this kind of person." It is closer to:

In this context, the user moved from this frame to that frame.

That is a safer memory.

2. Boundaries the user set

Boundaries are different from preferences.

A preference might be:

I like shorter replies.

A boundary is more like:

Do not make this decision for me.

Or:

Do not reopen this unless I ask.

Or:

This topic needs explicit consent.

These should not be buried inside a general summary. They deserve their own status.

If a user sets a boundary, the next session should not have to rediscover it through trial and error.

This is where memory starts to look less like personalization and more like trust infrastructure.

3. Unresolved tensions kept open

Not every useful session ends with a conclusion.

Sometimes the user chooses to keep something unresolved.

That can be an important state.

The system should not rush to resolve it later just because it has a saved note. It should also not erase it and force the user to rebuild the context from scratch.

A good handoff artifact can say:

This was left open on purpose.

That is different from saying:

This is unfinished.

4. Corrections from the user

This one feels especially important.

When the user corrects the system, that is not just a preference signal. It is a repair event.

The system got something wrong, and the user supplied the fix.

That should be one of the most valuable things to carry forward, because it is testable.

A framing-change moment can be hard to verify in the next session. A correction is easier to test. When a similar input appears again, the system can show whether it actually learned by not making the same mistake.

This is also a useful guardrail against vague personalization.

The system should not only remember a polished version of who it thinks the user is. It should remember where its own model of the user failed.

A handoff artifact needs a shape

The practical difference between a summary and a handoff is that a handoff needs a schema.

A loose summary can be a paragraph.

A handoff artifact needs to make the next reader explicit.

A simplified version might look like this:

type HandoffArtifact = {
  id: string;
  sessionId: string;
  audience: "next-session" | "retrieval" | "user-review";

  carryForward: HandoffItem[];
  doNotCarryForward: HandoffItem[];
  unresolvedTensions: HandoffItem[];
  userCorrections: HandoffItem[];

  consentState: "draft" | "approved" | "edited" | "rejected";
  createdAt: string;
  expiresAt?: string;
};

type HandoffItem = {
  kind:
    | "framing-change"
    | "boundary"
    | "unresolved-tension"
    | "correction";

  text: string;
  sourceExcerpt?: string;
  reason: string;
  confidence: "low" | "medium" | "high";
};

The important part is not the exact schema.

The important part is that the artifact separates several things that summaries usually flatten:

what should be carried forward
what should explicitly not be carried forward
what was left unresolved on purpose
what the user corrected
whether the user approved the artifact

This gives the next session a cleaner contract.

It also gives the product a better failure mode.

If the system gets the handoff wrong, the user can reject or edit a specific item instead of fighting an invisible memory layer.

A basic lifecycle might look like this:

session
-> draft handoff
-> user review
-> approved / edited / rejected
-> retrieval candidate
-> prompt context

That lifecycle is the part I would not skip.

Without it, the schema is just another hidden memory object. The user still has no real authority over what gets inherited.

Who writes the handoff?

This may be the hardest product question.

If the model writes the handoff artifact by itself, it may quietly preserve the version of the user it finds easiest to understand.

That is dangerous.

The model might turn a temporary mood into a stable trait. It might compress a complicated tension into a simple label. It might save the cleanest story, not the truest one.

If the user has to write the handoff artifact, the cost is too high.

Most users will not do it. And honestly, they should not have to. Asking users to manage their own memory system like a database is not a real product solution.

The middle ground seems more promising:

The model drafts. The user ratifies.

But that only works if ratification is light.

It cannot feel like reviewing a document after every session. It probably has to be closer to:

keep this
delete this
edit one line
do not carry this forward
ask me next time

The user should not have to become the system administrator of their own memory. But they should have real authority over what gets inherited.

Sometimes the right memory is no memory

This part is under-discussed.

Most memory products assume continuity is good.

More continuity, more personalization, more context.

But unasked-for continuity can create a burden for the user.

If the system carries forward the wrong thing, the user has to spend the next session undoing it. They have to refute an inheritance they never asked for.

That is backwards.

Sometimes carrying nothing forward is the more respectful choice.

It means the next session has to earn the context again. The user does not have to dismantle a stale version of themselves before the conversation can begin.

For reflective AI, this matters a lot.

A system that remembers too aggressively can start to sound intimate before it has earned the right to be. It can act as if it understands the user more than it does.

That is not continuity. That is overconfidence.

Why I care about this

I have been thinking about this while building Jung Room, a non-clinical AI self-exploration room for dreams, moods, symbols, and recurring patterns.

In that kind of product, memory cannot just be a hidden personalization layer.

It has to be something the user can inspect, correct, and choose not to carry forward.

That changes the implementation.

Memory is no longer just a retrieval feature. It becomes part of the product contract.

Memory is a governance problem

The more I think about this, the less I see AI memory as a storage problem.

Storage is the easy word.

The harder questions are governance questions.

Who decides what gets remembered?

Who decides what gets used?

Who can correct it?

Who can delete it?

When should the system choose not to remember?

And when memory moves from one session to the next, who is responsible for that inheritance?

A handoff artifact makes these questions more visible because it names the next reader.

It forces the system to ask what the next session actually needs, instead of simply compressing the last one.

That is the product shift I care about:

AI memory should not be a pile of summaries. It should be a set of governed handoffs, with the user still in charge of what gets carried forward.

AI memory should be a product state, not a prompt trick

Yana Li — Sat, 20 Jun 2026 11:07:52 +0000

I ran into a memory problem while building a reflective AI product.

The easy version of AI memory is tempting:

Save useful facts about the user.
Put them back into the next prompt.
Call it memory.

That can work for low-risk personalization.

It is probably fine if an assistant remembers that a repo uses pnpm, or that a user prefers short answers, or that a team calls its staging branch preview.

But the problem changes when the user is bringing personal material into the product.

In my case, the product lets people explore dreams, moods, relationship patterns, recurring symbols, and private reflections. I did not want meaningful sessions to disappear into raw chat history. But I also did not want every sentence the user typed to quietly become permanent memory.

That changed the architecture for me.

The question stopped being:

What can the model remember?

It became:

What does the user own?
What did they approve?
When is it stored?
When is it used?
When can it be paused, exported, or deleted?

That distinction sounds like product design, but it quickly becomes system design.

The common mistake: treating memory as one bucket

Many AI products describe memory as if it were one thing:

Memory: on/off

That is simple, but it hides too much.

In practice, "memory" usually mixes several different jobs:

short-term conversation context
a summary of the last session
facts the user explicitly wants remembered
model-inferred patterns
user-authored background context
retrieval results selected for the current turn
account data that must be exportable or deletable

If all of that becomes one invisible bucket, the developer gets a simpler implementation and the user gets a murkier product.

You also lose the ability to answer basic questions:

Why did the assistant bring this up?
Did it save that automatically?
Is this being used in future prompts?
Can I delete this one thing without deleting everything?
What happens if I pause memory?
What happens if my subscription ends?

Those are not only UX questions. They are architecture questions.

Stored memory and prompt memory are different

The biggest architectural shift for me was separating stored memory from prompt-time memory.

A user may own saved memory assets, but that does not mean the model should always be allowed to use them.

I ended up thinking about memory in two different states:

This belongs to the user.
This is currently allowed to enter the prompt.

Those are not the same promise.

A user should be able to view, export, or delete saved memory without the assistant automatically using it in every future session.

That separation led to a small but important access layer:

type MemoryAccessState = {
  userMemoryEnabled: boolean;
  planKey: string;
  entitlementState: string;
  subscriptionActive: boolean;
  canUsePromptMemory: boolean;
  pendingMemoryActivation: boolean;
  memoryExpiresAt: string | null;
};

function getCanUsePromptMemory(state: MemoryAccessState) {
  return state.userMemoryEnabled && state.subscriptionActive;
}

The important field is not userMemoryEnabled.

It is canUsePromptMemory.

That field answers the real runtime question: should memory be included in the prompt for this turn?

This avoids a confusing product promise.

For example:

a free user may have memory assets saved, but not active in future prompts
a paid user may allow long-term memory into sessions
a user may pause memory without deleting the assets
an interrupted subscription may retain memory for a defined period without letting the model call it
deletion and export can still work even when prompt memory is disabled

Without this separation, memory becomes a hidden privilege state. The data exists, the user sees some of it, the model may or may not use it, and nobody can explain the boundary clearly.

The pattern: split memory by lifecycle

I stopped treating memory as one feature and started treating it as a set of product states.

The simplified shape looks like this:

conversation
-> session note
-> user-approved memory item
-> user-authored room context
-> long-term inner map
-> retrieval evidence
-> prompt context

Each layer has a different lifecycle.

conversation is the raw exchange. It is useful for same-session continuity, but too noisy to become long-term memory by itself.

session note is a structured artifact created after a session. It can summarize themes, symbols, conflicts, and useful continuity points.

memory item is smaller and more explicit. It is the kind of thing the user can inspect and approve.

room context is user-authored background. I treat this as higher-trust than inferred memory because the user wrote it directly.

inner map is a versioned long-term snapshot of recurring themes. This layer needs caution because it can easily sound more authoritative than it is.

retrieval evidence is what the system selected for the current turn.

prompt context is the final compiled memory that the model sees.

This adds work, but it makes the system easier to reason about.

The user can own assets without every asset being active in the prompt. The assistant can use relevant memory without pretending all saved history is equally important. The product can pause, retain, export, or delete different layers without inventing a new exception every time.

Retrieval should return evidence, not vibes

Once memory is layered, retrieval should also become more explicit.

A memory result should not just be text pasted into a prompt. It should carry enough metadata to explain why it was selected.

A simplified version:

type MemoryEvidence = {
  source: "session-note" | "memory-item";
  id: string;
  title: string;
  excerpt: string;
  score: number;
  reason: string;
  createdAt?: string;
};

The reason field is not fancy, but it is useful.

It can say things like:

semantic long-memory match
strong theme/symbol overlap
partial approved-memory overlap
recent continuity evidence

This helps debugging, but it also keeps the product honest.

If the assistant brings a memory into the current turn, the system should be able to explain why that memory was selected.

For a first version, retrieval does not need to be magical. I prefer a conservative hybrid approach:

user-authored context
+ latest long-term snapshot
+ relevant session notes
+ recent notes as fallback
+ approved memory items
-> compact prompt memory

Vector search is useful, but it should not be the only rule.

For personal or reflective products, recency, explicit approval, user-authored context, and clear fallback behavior matter just as much as similarity score.

A small failure case: the creepy callback

Here is the kind of behavior I wanted to avoid.

Suppose a user once wrote:

I keep dreaming about a locked garden gate.

Two weeks later they write:

I felt ashamed today when I wanted to ask for help.

Bad memory behavior:

This connects to your locked garden gate dream.

Maybe it does. Maybe it does not.

The callback may be clever, but if the user did not invite that connection, and the system cannot explain why it surfaced the memory, it can feel creepy.

Better behavior:

There may be a threshold theme here, but I would not force it.
If it feels connected, we can compare today's shame with the earlier gate image.
If not, we can stay with what happened today.

The wording is different, but the real difference is architectural.

The system needs to know:

Was the earlier note user-approved or model-inferred?
Was it selected because of semantic similarity, theme overlap, or mere recency?
Can the user inspect it?
Can the user delete it?
Can memory be paused before the next turn?

If those answers only exist inside the model response, the product is too soft in the wrong place.

The memory boundary needs to exist outside the prompt.

Retention is also part of memory design

Another mistake is treating retention as a legal/privacy page problem only.

For memory-heavy products, retention is part of the product behavior.

I prefer making the rules boring and explicit:

Active subscription:
  memory can accumulate
  memory can enter prompts if enabled

Paused or interrupted subscription:
  memory assets are retained for a defined period
  memory does not enter prompts

Memory disabled:
  existing assets remain manageable
  new long-term memory writes stop

Deletion:
  individual memory items can be deleted
  account-owned data can be exported or removed

The important part is not the exact number of days. The important part is that the product does not blur ownership, access, and usage.

A user should not have to guess whether saved memory is currently active.

They should not have to delete everything just to stop the assistant from using it.

Guardrails I would keep

For sensitive or reflective AI products, I would start with these guardrails:

Do not treat the raw transcript as the long-term memory layer.
Create a structured session note before creating smaller memory items.
Require explicit approval for strong long-term memory items.
Separate stored memory from prompt-time memory.
Show memory state in account or session UI.
Let users pause memory without deleting saved assets.
Let users delete individual memory items.
Keep export and deletion paths boring and reliable.
Record why retrieved memory entered the prompt.
Make retention rules explicit when billing or account state changes.

None of this requires a complicated agent framework.

It requires treating memory as product state instead of prompt decoration.

Where this is probably overkill

This pattern is too heavy for some products.

I would not build all of this for:

a throwaway demo
a stateless assistant
a tool that only remembers harmless UI preferences
a private local prototype where the user and developer are the same person

It becomes worth it when:

users bring sensitive or personal material
memory changes future model behavior
the product has accounts, billing, export, or deletion promises
users may reasonably ask why the AI remembered something
continuity is part of the paid value

That last point matters.

If memory is part of what people pay for, it cannot just be a prompt trick.

How I am applying this

I built this pattern while working on Jung Room, a non-clinical AI self-exploration room for dreams, moods, symbols, and recurring patterns.

The product-specific version has:

session notes
+ saved memory items
+ user-authored room context
+ inner-map snapshots
+ account memory controls
+ subscription-gated prompt-time memory
+ retention and deletion paths

The general lesson is broader than this product:

Memory should be inspectable before it becomes powerful.

Builder checklist

If you are adding memory to an AI product, these are the questions I would ask early:

What exactly is being stored?
Which parts were written by the user?
Which parts were inferred by the model?
Which parts require explicit approval?
Which parts can enter future prompts?
Can the user pause prompt-time memory?
Can the user delete one memory without deleting the account?
What happens when billing state changes?
What is the fallback when retrieval fails?
Can you explain why a memory was selected?

If those answers are unclear, the memory feature may work technically while still feeling untrustworthy.

Open question

How are you handling memory in your own AI apps?

Are you treating it as private prompt context, user-owned product state, retrieval evidence, or something else entirely?

AI summaries need receipts: how I built evidence-bound reports from comments

Yana Li — Fri, 19 Jun 2026 04:10:28 +0000

A mistake I keep running into with AI feedback tools is treating the summary as the product.

Getting a model to write a confident paragraph is no longer the hard part.

The hard part is making every useful claim traceable back to the messy source rows that produced it.

I ran into this while building a tool around YouTube comments. Before building this, I spent a lot of time reading YouTube comments manually as a creator, and that probably shaped how I think about this problem.

A creator, founder, or marketer does not just need "people liked the video" or "viewers want more tutorials." They need to know which comments support that claim, whether the signal came from one loud comment or a real pattern, and whether the model invented a clean story that the comments do not actually justify.

While testing the report flow, the trust question mattered more than the model question.

Not "which model writes the best report?"

More like:

Why should I trust an AI report about messy comments?

That is the technical problem this post is about.

The common mistake: summarize first, source later

The simplest AI report pipeline looks like this:

comments
-> prompt
-> summary
-> display

That can be useful for quick reading. If the goal is a private note, a rough digest, or a first-pass brainstorm, a loose summary may be enough.

But it breaks down when the output is supposed to guide action.

For example, imagine three comments:

c1: "Can you make a beginner version? I got lost halfway through."
c2: "The advanced part was useful, but I need a slower setup walkthrough."
c3: "Please share the template you used."

A reasonable summary might say:

Viewers want more beginner-friendly setup material.

That is fine.

But now imagine the generated report says:

Viewers are asking for a paid course and a downloadable starter kit.

Maybe that is a good business idea. Maybe it is not. The important part is that the comments above do not actually say it.

The report moved from evidence to interpretation without showing the bridge.

What plain summaries are good at

I do not think every AI summary needs a citation system.

Plain summaries are good when:

the reader only needs a rough orientation
the source set is small enough to inspect manually
the output is not used for a customer-facing or business decision
the model is helping with brainstorming, not evidence

The stricter requirement starts when the summary becomes a decision surface.

If a report suggests a reply idea, a content idea, a positioning change, a risk review, or a product decision, then the user should be able to ask:

Show me the comments behind this.

If the system cannot answer that, the report may still be useful, but it is not very inspectable.

A better unit: the evidence-bound claim

The shape I prefer is not "summary first."

It is closer to:

source rows
-> candidate claims
-> evidence binding
-> validation
-> report sections

At the data level, the basic object is boring:

type EvidenceBoundClaim = {
  title: string;
  summary: string;
  evidence_comment_ids: string[];
};

That small field changes the product contract.

The claim is not just text. It is text plus a list of source comments that the user can inspect.

In a comment report, the same pattern can apply to:

repeated questions
demand signals
objections
praise
confusion
risk signals
content ideas
reply ideas

The report can still be written in normal language. It just cannot float away from the comments.

Why messy feedback needs stricter binding

YouTube comments are not clean survey answers.

They include jokes, sarcasm, spam, repeated questions, one-word reactions, language mixing, replies to replies, creator-specific context, and comments that are useful only because of where they appear in a thread.

That creates several failure modes.

One comment becomes a pattern

A model sees one strong complaint and writes it as if the audience broadly agrees.

Evidence binding does not solve this by itself, but it makes the weakness visible. If a "major concern" has one evidence row, the user can judge it differently from a concern backed by twenty comments.

A pattern loses its source

The model correctly detects that many people are confused, but the report does not show which comments created that impression.

That makes the report hard to use. The creator cannot quote the comments, answer the right thread, or decide whether the confusion is about the video, the product, the title, or the viewer's prior knowledge.

Multi-source reports mix context

If the input includes multiple videos, a playlist, a channel, or a URL list, the model can accidentally blend sources.

That is why source metadata matters. A compact shape like this is enough:

type CommentForAnalysis = {
  comment_id: string;
  text: string;
  source_key?: string;
};

Then source context can be sent once, while each comment carries the source key it belongs to.

The guardrail is simple:

Do not claim source-level differences unless the evidence IDs support that source_key.

Without that rule, a report can say "Video A has more pricing objections than Video B" when the cited comments do not actually support the comparison.

The pipeline I trust more

The pipeline I want for this kind of product looks like this:

public comment rows
-> stable comment IDs
-> optional source map
-> AI analysis
-> deterministic semantic snapshot
-> evidence ID validation
-> report trust gate
-> cited report, export, or share page

In my implementation, the report is generated from a saved comment snapshot, not from whatever YouTube happens to return later. Once comments are saved, the analysis pass works against those saved source rows, and the report stores a deterministic semantic_snapshot with evidence_comment_ids on the claims that need support.

Before a claim becomes visible evidence, those IDs are resolved back against the saved snapshot. If an ID does not resolve, it cannot become one of the evidence examples the reader can inspect.

For multi-video inputs, each row can carry a compact source_key. The analysis prompt explicitly tells the model not to claim source-level differences unless the evidence IDs support that key.

The important product decision is where to be strict.

The system can let the model help with language, grouping, and interpretation.

But it should be strict about the things the model is not allowed to invent:

comment IDs
source keys
exact source excerpts
sentiment totals
analyzed row counts
whether a claim has enough support
whether a report is ready to export or share

In other words, the model can propose the story.

The system should verify the receipts.

Validation before calling a report ready

For feedback reports, I would want checks like these before the output is treated as ready:

comments_analyzed > 0
sentiment counts sum to comments_analyzed
every evidence_comment_id resolves against saved source rows
quoted examples are checked against the saved source snapshot
source-level comparisons are backed by source_key evidence
recommended actions include evidence IDs
export/share paths should be blocked until the report trust gate passes

Some of these checks are easy. Some are annoying. All of them make the product less magical in a useful way.

The goal is not to make the report sound more confident.

The goal is to prevent unsupported confidence from reaching the user.

What to show users when evidence is imperfect

This is where product design matters as much as backend validation.

If evidence is thin, I do not want the user-facing report to say:

Low confidence, but here is a polished recommendation anyway.

That teaches people to ignore the warning.

I prefer one of three outcomes:

Keep the report in a verifying or processing state.
Generate a conservative fallback report with smaller claims.
Show a stable source or account blocker if the data is not usable.

For a completed report, the copy should describe what is actually verified:

saved comments
analyzed sample
thread boundary
evidence rows
selected limits

That is different from promising complete coverage of every comment that ever existed.

Deleted, hidden, private, rejected, edited, unavailable, or API-limited comments can still be outside the boundary. A good report should explain its data boundary instead of pretending the boundary does not exist.

When this approach is not right

Evidence-bound reporting is not always worth the extra structure.

Use a looser summary when:

the output is only a private reading aid
the source set is small
the user will inspect every source row anyway
the goal is brainstorming, not decision support

Use evidence-bound reports when:

the output recommends an action
multiple stakeholders will read the report
the report may be exported, shared, or used later
the source data is messy enough that hallucinated certainty is dangerous
users need to audit why the system reached a conclusion

The boundary keeps the tool honest.

How I'm applying this

I am applying this to public YouTube comments in an AudienceCue sample report.

The narrow product idea is:

paste a public YouTube link
-> download comments
-> generate an audience report
-> inspect the comments behind the claims

It is read-only. It does not reply to YouTube comments, moderate a channel, delete anything, pin anything, or take action on behalf of the creator.

That read-only boundary is intentional. For now, I would rather make the evidence layer trustworthy than rush into automation.

Checklist for builders

If you are building AI tools that summarize messy feedback, these are the questions I would ask:

Does every important claim point back to source rows?
Can the system detect invented or missing evidence IDs?
Are quoted examples checked against the saved source snapshot, or are they model paraphrases?
Can users tell the difference between one loud comment and a repeated pattern?
Does the report preserve source context when there are multiple videos, files, or accounts?
Are export and share actions blocked until the evidence gate passes?
When evidence is weak, does the product reduce claim strength instead of hiding the weakness behind confident copy?

The last one matters most to me.

AI summaries are easy to make impressive. Evidence-bound summaries are harder, but they are easier to trust.

I am curious how other people handle this in production systems: do you use strict citations, approximate references, or human review when AI summarizes messy user feedback?

ASR-generated subtitles vs forced alignment: why script-first captions fail less

Yana Li — Thu, 18 Jun 2026 08:27:36 +0000

A mistake I keep seeing in subtitle tools is simple but expensive: someone already has an approved script, but the workflow still starts by transcribing the audio again.

I ran into this while working with scripted voiceovers. The script was already reviewed, but the subtitle tool still wanted to guess the words from audio.

That sounds reasonable at first. Most captioning tools are built around speech-to-text. Upload audio, get words, split them into captions, export an SRT or VTT file.

But scripted video is a different problem.

If the script is already approved, ASR should not be the source of truth. It can help with timing evidence. It can help detect mismatches. But it should not quietly rewrite the words the user already signed off on.

That is the distinction I have been thinking about while building a script-first subtitle workflow.

The common mistake: transcribing an approved script again

For a lot of videos, the script comes before the audio.

Course lessons. Product walkthroughs. YouTube voiceovers. Localization review. Client-approved ads. Studio narration. The words are not unknown. They were written first, reviewed, then recorded.

In that situation, a transcription-first subtitle flow does extra work and creates a new risk:

audio -> ASR transcript -> subtitle splitting -> export

Once the ASR transcript becomes the source of truth, every downstream step inherits its substitutions.

That means the final caption file can differ from the approved script in small but annoying ways:

product names change
API terms get normalized
numbers become words, or words become numbers
casing disappears
punctuation gets simplified
domain-specific phrases turn into more common phrases

None of those changes may look dramatic in a demo. In production, they matter because subtitle files travel. They go into YouTube, editing timelines, localization handoffs, accessibility checks, client review, and sometimes legal or compliance workflows.

The approved script should own the words. The audio should only provide timing evidence.

What ASR is good at

ASR is very useful. I do not think this is an "ASR bad" argument.

ASR is the right default when you do not know the words yet:

audio -> transcript

That is the normal speech-to-text problem. NVIDIA's glossary describes speech-to-text as converting spoken language into written text, which is exactly what you want for meetings, interviews, podcasts, unscripted videos, and rough notes.

ASR also helps in scripted workflows. It can provide acoustic evidence, approximate word timing, confidence signals, and mismatch hints.

The boundary I care about is narrower:

when the user provides a script, the system should not treat ASR output as permission to replace that script.

What forced alignment is actually doing

Forced alignment is not the opposite of ASR.

That matters. A lot of aligners still use ASR models or acoustic models internally. NVIDIA's NeMo Forced Aligner, for example, uses CTC-based ASR models to generate token-, word-, and segment-level timestamps, and it can work with user-provided reference text. The key difference is the goal: generating new text versus locating known text in the audio.

ASR tries to recover text from audio.

Forced alignment tries to locate provided text in audio.

A simplified script-first flow looks more like this:

approved script
-> text normalization
-> audio segmentation
-> forced alignment / timing evidence
-> mismatch detection
-> cue generation
-> cue validation
-> review issue surfacing
-> SRT / VTT export

The product decision is not just "which model do we use?"

The product decision is "who owns the words?"

In a script-first caption system, the answer should be boring and strict: the script owns the words.

Why source-of-truth matters for subtitles

There is a difference between a transcript and a subtitle asset.

A transcript can be approximate. A human can skim it, search it, or fix it later.

A subtitle asset has to be consumed by other systems. It has timestamps. It has formatting constraints. It has line breaks. It has cue boundaries. It may be uploaded directly into a video platform or handed to another person who assumes it is ready.

That makes source-of-truth mistakes more expensive.

If an ASR-generated subtitle changes "VTT" to "VT", or "webhook" to "web hook", the file might still look plausible. The problem is that a plausible wrong caption is harder to catch than an obvious failure.

I would rather surface uncertainty than silently make the text feel clean.

Uncertainty should become a review issue, not a silent edit.

A small failure example

Here is the kind of thing that looks minor until it gets exported.

Original script:

Deploy the VTT file after the webhook returns 200.

Possible ASR output:

Deploy the VTT file after the web hook returns two hundred.

That is not a terrible transcript. A human understands it.

But it changed the asset:

webhook became web hook
200 became two hundred
developer wording became more conversational

For some content, that is fine. For a technical tutorial, docs video, client-approved narration, or localization source file, it is not the same text anymore.

There is also the classic funny version:

Upload the SRT to YouTube Studio before 9:00.

becoming:

Upload the shirt to YouTube studio before nine.

That one is easier to laugh at, but the more realistic failure is usually not a total mishearing. It is a slow loss of exact wording.

Engineering problems in script-first subtitles

Script-first alignment sounds simple:

script + audio -> timestamps

In practice, there are several places where the system has to be conservative.

Text normalization cannot become rewriting

Some normalization is useful. You may need to compare punctuation-light text, lowercase forms, number variants, or tokenized words.

But the comparison form is not the export form.

The exported subtitle should preserve the approved script text unless the user explicitly edits it. Normalization should help matching, not become a hidden rewrite step.

Audio and script often disagree slightly

Voiceover is human.

People skip small words, add a phrase, read a number differently, or repeat a sentence after a mistake. Sometimes the script is a near-final draft, not the exact recording.

The system needs to decide what to do when the evidence is messy.

My preference is:

preserve the submitted script
flag the uncertain span
ask for review when needed

The tempting shortcut is to "fix" the subtitle text with the ASR transcript. That may look smoother in the UI, but it breaks the source-of-truth contract.

Long audio creates drift

Short clips are forgiving. A 45-second demo can have slightly rough timing and still feel okay.

Longer voiceovers are less forgiving. A small boundary mistake early in the file can make later cues feel off. Long files need sectioning, local checks, and final cue validation instead of one optimistic pass.

Word timestamps are raw material, not subtitle files

Word-level timing is useful, but it is not a finished SRT.

Subtitles need cue boundaries. They need readable line breaks. They need timestamps that players accept. They need constraints around duration and reading speed.

This is where a lot of "we have word timestamps" demos fall short. Word timestamps are ingredients. The subtitle file is the product.

Validation: turning uncertainty into review issues

I think the validator is where a subtitle system earns trust.

At minimum, I would want checks like these before calling an export ready:

start_time < end_time
no overlapping cues
timestamps within audio duration
minimum cue duration
maximum cue duration
max characters per line
max lines per cue
reading speed limit
preserve approved script text
detect skipped script spans
detect repeated script spans
flag low-confidence alignment spans
flag audio-script mismatch
valid SRT / VTT timestamp formatting

Some of these are structural. Some are readability checks. Some are source-fidelity checks.

The source-fidelity checks are the ones I care about most in a script-first workflow. If the script says webhook returns 200, the exported caption should not become web hook returns two hundred just because the audio model found that easier.

When confidence is low, the system should not pretend. It should show the user where the issue is and why it matters.

That review surface is part of the product, not a nice-to-have debug panel.

When forced alignment is not the right tool

Forced alignment is not always the right tool.

Use ASR when:

there is no script
the speaker is improvising
the audio contains unscripted Q&A
the script is only a rough outline
multiple speakers go off-script heavily

Use script-first alignment when:

the script is approved
the voiceover follows the script closely
exact wording matters
the output is a subtitle asset, not just a transcript

This distinction keeps the tool honest.

If the audio is truly unscripted, forcing it onto a reference text creates a different kind of bad result. If the script is authoritative, transcribing it again creates avoidable text pollution.

Why I am building this into TimedSubs

I am building this workflow into TimedSubs:

script + voiceover audio -> timed subtitle files with QA before export

The narrowness is intentional. I do not want it to be a generic transcription clone or a video editor. The useful part is the constraint: when a script is provided, the script stays authoritative, and the system uses audio to produce timing evidence and review signals.

Checklist for builders

If you are building captions or subtitle tooling, these are the questions I would ask:

Does the system know whether the user has an approved script?
If a script exists, does the final subtitle text preserve it?
Are ASR results treated as evidence, or as replacement text?
Can the system detect skipped, repeated, or mismatched script spans?
Do long files stay stable, or does timing drift over time?
Are cue-level export blockers checked before download?
Can the user see why a segment needs review?

The last one matters more than it sounds.

People can tolerate a system that says "I am not sure about this span." They lose trust in a system that silently changes approved words and calls the result ready.

Takeaway

ASR is good when you need to discover the words.

Forced alignment is useful when you already know the words and need timing.

For scripted video, course, voiceover, and localization workflows, that difference changes the whole product design. The caption system should not casually turn an approved script into a fresh machine transcript.

The approved script should own the words. The audio should only provide timing evidence.

I am curious how other people handle this in production workflows: do you trust ASR-generated subtitles as the source, or do you keep an approved script and align against it?