Prompt Library Governed by a Sourced Claim Registry

A prompt library makes tone repeatable inside a week. It does not stop a model from asserting something about your product that nobody can source. In the eleven in-house prompt sets I have reviewed since 2024, voice was never the failure. The failure was that roughly a third of generated drafts carried a factual claim — an age grading, a certification, a load rating, a feeding guideline — with no owner and no document behind it. So this engagement builds two artefacts, and the prompt library is the smaller of them. The claim registry: A version-controlled file beside your content repo in which every assertion the brand is allowed to make exists exactly once: the claim in English and in Spanish, the document that supports it, the market it holds in, the person who signs it, and the date it expires. For a kids' product that means the ASTM F963 or EN 71 test report and the age grading it actually licenses. For pet nutrition it means the AAFCO statement wording, which does not survive paraphrase. For an industrial part it means the datasheet revision and the tolerance as published, not as rounded by a copywriter. A claim that cannot name its source does not enter the file, and the copy that depended on it gets cut rather than softened. The prompts: Prompt files in YAML in your repository, one per content job — comparison passage, spec summary, category intro, retailer copy block. Each is bound to the registry: the model receives only the claims scoped to that product and that market, and is instructed to refuse rather than approximate. Spanish prompts are written for es-MX with an explicit register decision, not produced by translating the English prompt, because the two ask the model for different things. The evaluation harness: Sixty briefs with known-good and known-bad outputs, run through promptfoo in CI. The graders check three things: whether an unsourced claim appeared, whether a registry claim was reworded past its licensed meaning, and whether the passage still reads as one voice. A pull request that moves a prompt runs the set. When a provider ships a new model version, you re-run and see what moved before a customer tells you. What this is not: I do not write your content, and I do not deliver a system that publishes without a person reading the output. There is no voice clone trained on your back catalogue. Translation memory and locale QA are separate work. I do not build agent chains that browse and cite live sources at generation time; retrieval that a legal team cannot audit is a liability in these three industries. Who should not buy this: A team publishing a handful of pieces a month through one writer. Governance of this kind costs more than the output is worth below roughly forty pieces a month across two languages. It is also wrong for a brand that wants the model to state something it cannot document — I will find that during the registry build and say so, and the engagement will get smaller and more awkward. How it runs: Two weeks. Week one is the registry: sessions with whoever owns product data, regulatory and legal, then the file. Week two is prompts and the evaluation set against your real briefs. Handover is one working session with the writers and one with whoever owns the repo. After that the library is yours to change; the registry is the part that needs an owner named on the day we finish.