Our FAQ drafting step deliberately calls no model. It copies answers only from evidence we already have, preserves the merchant's own words, and leaves the answer blank when nothing trustworthy exists instead of inventing store policy.
October 1, 20265 min readSaytu team
A merchant sees a question the assistant has been getting wrong and asks for a Draft FAQ.
That sounds like an obvious place to call a language model. Give the model the question, show it some store knowledge, ask it to write a polished answer, and put the result in front of the merchant for review.
We deliberately do not do that.
The drafting step calls no model. It copies an answer only when we already have one to copy, and when we do not, the merchant writes it.
The problem with generating a plausible FAQ answer is not that the model will always get it wrong. The harder problem is that a generated answer can look finished before anybody has established that the store ever said it.
An FAQ is different from an ordinary assistant turn. It can become durable store knowledge. Once published, future shoppers can receive it again and again, so a confident sentence invented during repair is not one questionable answer. It can become the source used to produce later answers.
That changes what we want from the drafting step. Its job is not to demonstrate how well the model can phrase a response. Its job is to move an answer the merchant already owns towards a form they can review and publish.
Today the draft can take an answer from a merchant's note or from a scan of past chats that has already found an answer. Those sources are not treated equally. A note written by the merchant about the problem outranks the scan. The merchant's own words outrank both.
The ordering is intentional. A note written for this exact repair is a stronger statement of what the store means than something recovered indirectly from earlier conversations. And if the merchant has already written the answer in the draft, re-drafting should not replace those words with something that merely looks more polished.
There is no model call sitting after those sources to "improve" them. That absence is part of the design.
The drafting code once described a third source: knowledge that the assistant could already retrieve. The interface had a distinct state for it. Tests could exercise it. From the shape of the product, it looked as though a merchant might ask for a draft and receive an answer derived from their existing knowledge base.
No production route could actually make that happen. Only tests supplied the argument that reached the branch. On both merchant surfaces, the real drafting call passed an opportunity and a tenant, not the retrieved knowledge required to produce that third kind of draft.
We removed the branch rather than wiring it up just because the code already existed. That decision matters because connecting retrieval to drafting would have forced us to answer a product question we had not answered yet: what exactly is the proposed answer?
Retrieval gives us a piece of source material. In this path, that can be a chunk as large as 900 characters.
A chunk is not automatically an answer to the shopper's question. It may contain the relevant fact beside unrelated text. It may need interpretation. It may contain wording that makes sense in the middle of a policy page but would be misleading when lifted into a standalone FAQ.
Passing that chunk to a model and asking for an answer would solve the formatting problem by introducing a new trust problem. The final wording would no longer be something we could simply point to in the merchant's source. It would be a new statement produced by the model.
We chose not to pretend that transformation had already been designed. The unused branch went away. If real cases later show that retrieved knowledge should become a draft source, that feature can return with rules shaped by those cases rather than by an old hypothetical.
This leaves an intentionally plain outcome when neither the merchant's note nor the scan holds an answer. The system does not fill the gap.
The draft can carry the question while the answer remains the merchant's work. That may feel less magical than generating a polished response immediately, but it preserves an important boundary: absence of evidence does not become permission to invent store policy.
That boundary is especially useful in support and commerce. An FAQ can contain returns rules, delivery expectations, product constraints or other statements a shopper may act on. Fluency is not enough to make those statements belong to the store.
A blank that clearly asks for the merchant's answer is more honest than a complete paragraph nobody actually supplied.
It is easy to equate an AI feature with another model call. We found the opposite useful here. The surrounding system can still identify a recurring problem, collect the available evidence, preserve provenance and prepare a repair workflow without asking a model to write the final fact.
The absence of generation gives the draft a simpler contract. If an answer appears, it came from somewhere we can name. If the merchant wrote something more deliberate, those words win. If nothing holds an answer, the system does not manufacture one to keep the interface full.
That is the behaviour we want from a repair tool. The purpose of a Draft FAQ is not to make an empty answer box disappear. It is to help the merchant turn something they actually know into something the assistant can safely use.
