Challenge 3: Why the Same Tool Scores Differently on Narration Each
Time -- Solution Walkthrough

DemoPolish's own score on Chapter 2's narration criterion isn't fixed
by the tool itself -- it depends entirely on what the presenter
actually provided as input, since the pipeline's job is to polish and
re-voice real recorded narration, not to generate narration
independently of it. When a presenter genuinely explains their own
reasoning while recording, even roughly or with filler words,
DemoPolish preserves that explanation's own phrasing while cleaning up
delivery -- the result narrates real intent, scoring well on Criterion
3. When a presenter records with little or no real explanation (or
narrates only what they're clicking, per Chapter 2's own click-vs-intent
distinction), there's no underlying reasoning in the input for
DemoPolish to preserve, no matter how polished the resulting voiceover
sounds -- the output can only be as good, on this specific criterion,
as the raw narration fed into it.

This is exactly the nuance this chapter's own correction to Chapter
2's general category description was making: DemoPolish isn't
structurally incapable of good intent-narration the way a
purely click-driven generator would be, but it's also not
automatically good at it regardless of input -- its actual
performance on Criterion 3 is a direct function of what the presenter
brought to the recording in the first place, not a fixed property of
the tool.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader understands DemoPolish's
narration quality as input-dependent rather than a fixed tool
characteristic -- correctly explaining that identical software applied
to different quality of raw narration produces genuinely different
results on this specific criterion, unlike, say, its legibility
handling, which is unaffected by what the presenter says.