A rulebook for product data
LLMs make generating text easy. The hard part is making every claim in it accurate and compliant, at the scale of a full catalogue. Here’s how we turned that into an engineering problem.
When I explain what Kito does, people often ask me why generating product data is still a problem worth solving.
It is a fair question. Models such as Fable 5.1 and GPT-6 Astra are solving increasingly demanding tasks in coding and mathematics. Surely writing a product description should be straightforward by comparison.
So why not simply connect to an LLM provider, build an enrichment pipeline, and handle it in-house?
Problem solved, right?
Verifiable vs. non-verifiable problems
It is true that LLMs make generating text easy. The challenge is making the claims in that text accurate and compliant with every applicable requirement.
LLMs are prone to hallucinations, and this is still true for frontier models. Knowing more does not automatically mean handling uncertainty more reliably.
For coding and math, a hallucination here and there won’t matter as much, since the agent is part of a feedback loop that gives it a concrete way to detect and correct failures. A coding agent can run a test, observe a failure, and revise its code.
In product enrichment, a hallucinated product feature does not trigger a compiler error. Instead, these hallucinations become false claims about the products you sell.
Why it’s a hard problem
Some mistakes are much more expensive than others.
In the UK, the Competition and Markets Authority’s (CMA) consumer-enforcement powers allow turnover-based fines reaching 10% of a company’s global turnover for infringements of consumer protection law.
Consider a hypothetical supplier record. It confirms that a jacket’s lining is made from 100% recycled polyester. It says nothing about waterproofing, certifications, or the jacket’s overall environmental impact.
A generated description might call it:
A sustainable, waterproof jacket made from recycled materials.
It sounds like ordinary product copy. But it adds an unsupported performance claim, introduces a broad environmental claim, and blurs the distinction between the lining and the whole garment. The CMA’s fashion guidance specifically emphasizes clear, substantiated claims and precise descriptions of fabrics.
Generating reliable product data hinges on deciding exactly what the available evidence allows you to say, and when to leave something out or request clarification.
Accuracy is not the only requirement. A description can be accurate and still be unsuitable for the channel where it will appear. Google Merchant Center, for example, limits title length, prohibits promotional copy in product descriptions, and specifies how colors, sizes, variants, and product identifiers must be represented. Even replacing a supplier’s color name with a more familiar term can violate its requirements.
Google Merchant Center is only one example. Add regional consumer-protection rules, category-specific requirements, and each brand’s own conventions, and the problem quickly becomes combinatorial. Part of the challenge is resolving conflicts between different rules, and verifying that the final output complies with all of them.
And all that is before accounting for inference costs, retries, human review, and reprocessing when the underlying data or requirements change.
How we solved it
Our starting point was to treat product-data optimization as an engineering problem and turn as much of the process as possible into verifiable feedback loops.
Much of the work therefore goes into preparing the environment in which the model operates.
At the center of Kito is a compiled rulebook built from regional regulations, channel specifications, user guidance, and brand voice. These requirements are connected and hierarchical: rules can reference other rules, and the agent works with the requirements relevant to the task at hand.
At build time, an agent helps compile the rulebook and the supporting tools for deterministic checks.
At runtime, an agent uses that prepared environment to work on product data.
This architecture also lets us benefit directly from improvements in foundation models. Stronger reasoning improves how requirements are interpreted. Better coding capabilities help agents build better supporting tools.
Why it’s difficult to build
The workflow that processes your product data is only the tip of the iceberg.
The larger commitment is building and maintaining the system that tells you whether that workflow is actually working.
At Kito, that means continuously improving the rulebook, tools, and agents through a feedback loop:
Human evaluations → Datasets → Graders → Improvements → New evaluations
A human reviewer identifies a specific failure: an unsupported claim, a missing qualification, the wrong feature receiving emphasis, or wording that does not fit the brand.
That judgment becomes a structured example containing the input and the expected behavior. Those examples then become evaluation datasets.
Graders then let us compare new generations against that expected behavior at scale. But graders need evaluation too. An unreliable grader can make a system appear to improve when it is merely becoming better at satisfying a flawed test.
Every failure becomes a potential new test case. Each test case makes it easier to detect the same class of failure in the future. Over time, individual mistakes become improvements to the system itself.
If you want to avoid the hassle of building and maintaining all of that yourself, try Kito.
Kito Journal / 02
Back to topA closer look