How a draft stays honest
Pricing is settled. The catalog and rules docs grounded every number. The cover paragraph is composed in your voice. Now the drafter is one model call away from rendering a PDF that will end up in front of a customer. This is the part where small errors become expensive: a fabricated SKU in the cover sentence, a casual “in stock” in a paragraph that wasn’t fact-checked, a discount that’s allowed by the rules but shouldn’t be auto-applied without a manager seeing it. Four guardrails sit between the model and the rep’s review queue. None of them are in the model. All of them run as plain code.
Key takeaways
- Four guardrails between the model output and the rep’s queue: citation required, no fabricated SKUs, no commit on availability, discount cap.
- None of the guardrails are themselves model calls. All four run as cheap deterministic checks.
- A draft never auto-sends. The rep’s approval is the only path to the customer.
- Drafts unactioned trigger a 24-hour reminder; 48-hour escalation.
- Every approval, edit, and rejection is written to the audit log for later review.
Four guardrails in a row
Gate 1: citation required on every priced line
Pricing wrote a citation for each applied rule, line by line. The first guardrail checks that work. For every line on the draft, the gate walks the applied-rules list and confirms each entry has a citation pointing into the catalog or the rules doc. If any line is missing a citation — this shouldn’t happen in a healthy run, but it can if the pricer hit a bug or stopped halfway — the draft is rejected back to the pricer for a redo, with the offending line flagged. The rep is never paged on a draft with even one uncited number. Being able to check every number is what makes the rest of the system trustworthy. One uncited line breaks that trust for the whole quote.
Gate 2: no fabricated SKUs in free-text
The cover paragraph is the riskiest part of the draft. The pricer’s output is structured and grounded; the cover prose is the model’s creative space. Most of the time the model writes something safe: “Thanks for the request — here’s our quote for the brackets you outlined; pricing reflects our preferred-customer tier.” Sometimes the model gets clever and writes a SKU it shouldn’t. Maybe the buyer’s message mentioned a competitor’s SKU and the model echoed it. Maybe the model made up something that looks like one of yours.
Gate 2 runs a strict regex against the cover prose to find anything that looks like a SKU. Your SKU pattern is small and well-defined — a letter prefix, a dash, two-to-four digits, sometimes a letter at the end — so the regex is short. Every match is checked against the catalog index. If the model wrote “A-15” and you don’t make an A-15, the draft is rejected back to the composer with the offending text flagged. The composer rewrites the cover with explicit instruction to avoid that string. After two failed attempts, the gate gives up and falls back to a plain cover paragraph from the voice doc — safe, simple, and human-edited.
Gate 3: no commit on availability
The drafter does not check inventory. Inventory lives in the customer’s ERP or warehouse system and is its own integration. This drafter sits upstream of that. So the cover paragraph must never claim that an item is in stock, that it ships today, or any other availability promise. The voice doc tells the model not to write phrases like that. Gate 3 is the enforcement. A small block-list of phrases — “in stock,” “ships today,” “available now,” “on hand,” “ready to ship,” and a few others, all set in the rules doc — is matched against the cover prose. Any hit rejects the draft back to the composer with instruction to rewrite without that claim. The lead-time field on each line is fine; that’s a planning estimate straight from the catalog. The rejection is on customer-facing language that promises something the drafter can’t actually check.
Gate 4: discount cap (passive)
Gate 4 doesn’t reject anything. It reads the requires_manager_approval flags the pricer set on lines whose total discount exceeded the cap. If any line carries the flag, the draft is allowed through to the queue, but the rep’s review surface displays it differently: a red strip across the top of the draft (“manager approval required”), a per-line discount summary, and the “Approve and send” button replaced with “Send to manager for approval.” A manager who clicks that button gets the same review surface and can either approve-and-send or reject with a note. Either action is logged.
The rep can also still edit the line, change the quantity (which might drop it below the discount cap), and re-render the draft — the pipeline runs again from Stage 4 onward and Gate 4 re-evaluates.
The send loop: a draft never auto-sends
Once the four gates pass, the draft lands in the rep’s review queue with three buttons. Approve renders the PDF, sends it to the customer, and writes the conversation thread plus a link to the PDF into the CRM. Edit opens the draft for line-level changes; saving runs the gates again. Reject archives the draft with a reason and an optional note for the audit log. On approve, the customer gets the quote within a couple of seconds — the PDF is rendered on demand by a small Lambda when the rep clicks, not pre-rendered for every draft. Reject is for drafts the rep doesn’t want to send: the buyer changed their mind in a follow-up, the RFQ turned out to be from a customer the rep wants to call directly, or the line items are right but the rep wants to write a different cover paragraph.
If a draft sits without action for 24 hours, the system pings the rep again with a reminder. At 48 hours it escalates to the sales lead. Weekends still count; the timing is forgiving but the alert chain matters because RFQs are time-sensitive. A draft that nobody reviews for three days is a draft the customer probably gave up on.
Next post: the cost breakdown. The whole pipeline above runs in coffee-money territory at SMB volume, and Part 6 explains exactly where the dollars go.
All posts