You draft a quote using an LLM-powered generator. It produces line items that read perfectly: professional descriptions, reasonable pricing, even a discount structure that looks like your normal workflow. Then your prospect asks a clarifying question about an SKU that doesn't exist, or the margin math fails review, or legal questions a warranty clause you've never offered. The AI invented all of it—and made it look real enough to slip past initial review. This is not a training problem or a better-prompt problem. It's a guardrail problem . Large language models are statistically sophisticated pattern-matching engines. They have no access to your actual product database, pricing matrix, or approved contract language. Without explicit constraints linking the LLM's output to your real operational data, it will generate plausible fiction. Why LLMs hallucinate in quote generation An LLM trained on thousands of business documents learns what quotes look like . It understands syntax: discount structures, tax handling, signature blocks. But it has zero knowledge of what you actually sell, what you actually charge, or what terms you've actually agreed to. When asked to generate a quote, it: Invents SKUs that sound plausible but don't exist in your system ("Premium Integration Tier 2A" instead of your actual "INTG-PRO-02") Hallucinates pricing based on statistical patterns from training data, not your live pricing rules, volume discounts, or customer-specific contracts Creates service descriptions that drift from what you actually deliver, sometimes adding features or warranties you've never offered Generates payment terms that contradict your actual policy (Net 60 when you only offer Net 30, or bespoke terms that bypass your finance controls) References contract language that looks official but isn't—warranty clauses, liability caps, or compliance statements you've never approved The problem is not that LLMs are "bad" at quotes. They're generating statistically probable outputs that have zero connection to your operational reality. The cost of this mistake is high. A quoted SKU that doesn't exist triggers back-and-forth with the prospect. Invented pricing gets approved by the buyer but fails your margin review. Service descriptions create expectations your delivery team can't meet. Contract language written by an LLM can expose you to liability or contradict your insurance coverage. The three-layer guardrail: templates, locked data, human review To fix hallucination, you need three things working together: a constrained generation space, immutable operational data, and a human checkpoint. Layer 1: Vector database of approved templates Instead of asking an LLM to write a quote from scratch, give it a set of pre-approved, semantically searchable templates. A vector database (built on embeddings) lets the LLM find the right template rather than invent one. Example: When you ask the system to quote "API integration for a healthcare client," it searches a vector database of your past quotes. It finds templates that match the semantic meaning (medical sector, third-party data exchange, compliance-heavy). The LLM can then fill in specific details—customer name, timeline, volume—without inventing the core structure. Store all approved quote templates (with real SKUs, real pricing, real contract language) in a vector database indexed by industry, service type, and complexity Let the LLM search this database first and return matches ranked by relevance Allow the LLM to propose one of the top three matches, but not generate new templates For truly novel requests, route to a human who creates a new template (which then enters the vector DB for future use) Layer 2: Locked line items and pricing rules Your product database and pricing engine should be read-only to the quote generator, with hard constraints on what can be generated. SKU whitelist : Every line item must reference a SKU that exists in your product database. No exceptions. If a SKU doesn't match, the quote builder rejects it. Pricing matrix enforcement : Prices come directly from your system. The LLM can recommend discounts based on customer segment, volume, or contract history—but only within guardrails you define (e.g., "max 15% discount for new customers," "volume discounts only if volume ≥ 100 units"). Service description versioning : Approved descriptions for each SKU live in your system. The LLM can adapt phrasing for tone or length, but the substance (what's included, what's not, delivery timeline) is fixed. Contract clause registry : Approved contract language (warranty, liability, IP, termination, payment terms) is stored as immutable blocks. The quote builder assembles these blocks but doesn't invent new ones. This is strict, but it works. You lose flexibility in one direction (the LLM cannot propose novel pricing or terms in the moment), but you gain certainty: every quote your system generates is operationally accurate. Layer 3: Human-in-the-loop for nove