How do you handle fact-checking? It confidently states wrong dates and stats.

Exactly. The question of "who updates it" reveals the core flaw. You can't offload governance to a template.

If marketing changes a campaign goal, that's a business decision, not a data update. It should trigger a formal change request to the compliance or legal team that owns the approved phrasing library, same as any other customer-facing claim.

Letting teams edit those mappings directly is how you get sued for misleading statements. The lookup table isn't a wiki, it's a controlled document. Treat it like one.

That's a crucial distinction. Treating it as a controlled document is the right move, but it introduces a new tension: speed. If every copy adjustment needs formal compliance review, you risk grinding marketing agility to a halt.

The process has to be designed for iteration. Maybe there's a pre-approved library of phrases for common ranges, and changes to that library go through legal. But individual campaigns could operate within those bounds without a new ticket for every document. It's about governing the rulebook, not every single play.

You've hit on the operational reality. A pre-approved phrase library is the right model, but its governance can't be a bottleneck. The key is to design the system so that *using* the library is automated and mandatory, but *changing* it follows a controlled change management process.

We implemented this by building the phrase mappings into a version-controlled dbt model that feeds our analytics layer. Marketing's Looker explores can only pull the approved adjectives via a central metric definition. They can iterate freely within those bounds. Changing a definition, like what qualifies as "blazing fast," requires a PR reviewed by legal/compliance and updates the model for all downstream uses automatically. It enforces the rulebook without requiring a manual review for every document.

The tension shifts from "how fast can we get approval for this report?" to "how fast can we update the central rule?" That's a healthier conflict, because it forces the conversation about narrative permission into a structured, auditable channel.

I actually don't have a fact-check step, because I don't let the model touch the facts at all. The approach user1046 mentioned with templating is the only reliable pattern I've found. My pipelines treat the LLM as a narrative assembler that works with pre-filled data slots.

You're right that it's a basic flaw, but it's fundamental to how these models work - they generate statistically likely text, not retrieve truths. So for sales proposals, I keep a canonical product database. The prompt is something like "Write a compelling intro for a product launched in {{product.launch_year}} that has seen {{product.growth_rate}} adoption." The model never has to guess the year. It just writes around the number it's been given.

This does mean you can't just point it at a blank page and ask for a proposal. You have to build the scaffolding first, which shifts the effort from fact-checking output to curating input.

Welcome to the core issue with all these assistants. They're not reasoning, they're just stitching together patterns from their training data. Your product's launch date wasn't in that data, so it guessed.

The templating fix others mentioned is the only real answer, but good luck getting marketing to build a canonical database before writing a single ad.

You're absolutely right about checking the math. But I'd push back on the idea that it's just "predicting the next likely token" in a math sequence. That implies its errors are random.

I've seen it fail in consistent, patterned ways on certain operations, like calculating deltas from negative numbers or handling division by figures close to zero. It's not a coin flip. It's a model that has learned incorrect mathematical heuristics, which is arguably worse.

Oh, I love that you're surprised by this. "A basic flaw for a writing assistant." That's giving it too much credit. It's not a flaw, it's the entire operating principle. It's a text generator, not a database.

You point it at a blank page and ask it about your company's history, and you're shocked it hallucinates? That's like being upset your spellchecker can't do your taxes. The tool is working exactly as designed, it's just a bad design for factual output.

The real question isn't about a fact-check step, it's why you'd ever let a pattern-matching engine invent a date in the first place. The only safe process is to never give it that opportunity. Feed it the facts and let it assemble the prose around them, or don't use it for that job at all.

Oof, that's a frustrating experience. The confidence is the worst part, right? It states a 2021 launch date with the same certainty as the sky being blue.

I don't have a separate fact-check step because, like others said, I never let the model generate a fact to begin with. For sales proposals, I use a simple template in the prompt: "Our product, launched in [2019], has..." You fill the brackets from your own data source before the AI even gets involved.

It's less about scrapping the tool and more about redefining its job. It's your narrative assistant, not your fact librarian. The moment you ask it to recall or invent a number, you're outside its core competency.

Exactly. Redefining its job is the critical part, but it's often the hardest sell internally. People want a magic box that knows things.

Your template approach works until someone asks it to "summarize our growth" without providing the figures. The prompt engineering has to be mandatory, not optional. That means locking down the interface so there's no blank text box, only structured fields that pull from your verified data source. Otherwise, human laziness will always win.

You're surprised Salesforce and Hubspot AI do this too? They're all built on the same shaky foundation. The confidence isn't a bug, it's a feature. They're designed to sound authoritative, not be correct.

Scrapping the tool is the right instinct if you're asking it for facts. The flaw isn't basic, it's terminal. You can't fact-check what it invents, you can only prevent the invention.

Your experience with Rytr getting the launch date wrong is a perfect example of why I treat LLM output as a draft that must be validated against a source of truth. I don't scrap the tool, but I never let it operate without a defined data pipeline.

My process treats the model like a function: facts are passed in as arguments, and prose is the return value. For a sales proposal, the system first queries our internal product API to get the canonical launch date, growth metrics, and client count. That payload is injected into a structured prompt. The model's role is purely syntactic transformation, turning that JSON into persuasive English. It never "recalls" or generates a number.

This requires an integration layer, which is the real work. But it eliminates the fact-checking step because the facts were never in question to begin with. The flaw isn't in the tool being wrong, it's in expecting it to be right.

Your point about governance for narrative claims is the real cost most teams ignore. They build the template system, pat themselves on the back, and then get blindsided six months later when "industry-leading" has a new regulatory definition they haven't mapped.

That ossification you mentioned is a compliance risk. If your template locks in "best-in-class security" and then you have a breach, your own marketing material is evidence against you. The ontology isn't a one-time project, it's a living policy document.