Two days running now, the ask has been the same shape: take a naval-history article, condense it into 140-170 words of spoken narration for a Ken Burns-style short documentary. Third person, measured, authoritative. No greeting, no headings, no quotation marks. And the constraint that actually matters: use only facts that appear in the source article, never add or embellish.
That last line is the whole ballgame. Most narration prompts fail quietly — the model reaches for a plausible-sounding date, a ship's tonnage it half-remembers, a battle outcome that sounds right. None of that shows up as an error. It shows up as a documentary voiceover stating something wrong with total confidence, and nobody catches it until a viewer who actually knows the history does.
So the fix isn't a better prompt, it's a narrower one. "Condense" is doing a lot of work in that instruction — it's explicitly not "research" or "contextualize" or "bring to life." The model is told, in effect: you are a compressor, not a generator. Every fact in the output has to trace back to a sentence in the input. If the article doesn't say how many guns the ship carried, the narration doesn't either.
Running this twice in two days is what turned it from a one-off request into something worth writing down. The second time, the same rules applied cleanly with no adjustment — word count, tone, and the ban on invented detail all held. That's the signal that the prompt has actually converged on something durable rather than something that happened to work once.
Everything else in this stack — the DynamoDB tables tracking charters, the launchd jobs that run the deterministic pipelines overnight, the Python scripts that build PDF proposals — shares one design principle: the model does the part that requires judgment, and a script does the part that requires correctness. Charter dates, guest counts, pricing lines — those get computed, not generated, because a hallucinated charter date is a business problem, not a stylistic one.
Narration for a short documentary looks like a different kind of task — softer, more editorial — but the same principle applies. The "don't invent facts" instruction is really just fact-grounding, expressed for a copywriting context instead of a data pipeline. It's the same discipline as validating a DynamoDB write, just aimed at prose instead of a record.
The general lesson: when a generation task has a hard correctness requirement buried inside a soft creative one, say the requirement twice — once as tone guidance, once as an explicit constraint that reads almost like a test assertion. "Measured, authoritative documentary tone" is a vibe. "Use ONLY facts that appear in the article — never add or embellish" is a check a human reviewer can actually run against the output line by line.
narration spec: - length: 140-170 words - pov: third person - tone: measured, authoritative, documentary - source of truth: input article only - forbidden: invented facts, embellishment, headings, quotes, greeting
Small thing, but it's the difference between a prompt that works today and one that still works the tenth time someone runs it against an article they haven't read closely enough to fact-check themselves.