I. One Sentence Stopped Us Cold

When we decided to turn factory sourcing into a conversation, the team was optimistic about the difficulty. The database was already ours, the models were already smart enough, and what remained looked like little more than connecting the two ends.

What actually stopped us was a line from a customer, copied onto our whiteboard: "I'm looking for a factory that makes seals."

The sentence looks perfectly clear. Take it apart and it says almost nothing. Seals for automobiles, for hydraulic equipment, or for food processing machinery? Nitrile rubber, fluororubber, or PTFE? Is he buying a batch, or trying to sell his own raw materials to these factories? Where is the size threshold, and does he need someone who accepts small orders?

A ten-character request with at least five forks hidden behind it. And the customer does not feel he was being vague — in his experience, that sentence is entirely sufficient for an experienced salesperson who knows the trade. That person would ask two questions back, and then know exactly what to do.

What we set out to build was, in the end, software capable of asking those two questions.

For the past six months the loudest conversation in our industry has been about models: who topped the leaderboard again, who cut prices again. Our own six months went almost entirely into what sits behind that ten-character request. One thing has to be said up front, because it is the whole point of this article: not one ounce of that effort went into adding data. All of it went into making the AI worthy of the data we already had.

II. First, What We Actually Have

Tianxia Gongchang's database covers 4.8 million real, actively operating factories.

"Actively operating" is the dividing line. The manufacturing companies findable in business registration records, and the factories that are genuinely still running production, still holding capacity, still able to take an order, are two sets that differ by an order of magnitude. Most commercial company databases build the former — pull the registration records, clean them up, make them queryable. Identifying the subset that is still producing is a completely different kind of work. We have been at it for many years, and it is the only real moat we have.

Drawing that line means grinding through one field at a time: operating status, insured headcount, products and business scope, actual operating address, export records, certifications and government-published lists, and phone numbers that actually connect. Every field needs a source, needs continuous updating, and needs to survive the test of a customer picking up the phone — "the information exists, but the line is dead" is, in this business, the same as no information at all.

Harder still, the line is a moving one. Factories shut down, relocate, change names, and drift from one category into another. Whether a given plant is still producing today is not a conclusion you reach by collecting data once; it is something that has to be done repeatedly and kept up indefinitely. Which is also why it resists quick replication: it is not one act of collection, it is years of maintenance.

In use, this database can be interrogated in a structured way: geography down to the district, categories down to sub-processes, plus size, years in operation, export activity, and inclusion in national programs such as the ministry's specialized-and-sophisticated lists. Combine those dimensions and, in principle, every condition in a customer's head has a column waiting for it — "Zhejiang, medical-grade injection molding, three hundred insured employees and up, with export records" maps onto four dimensions that can be matched directly, with no guesswork involved.

The problem lies precisely in the words "in principle."

Every single "not found" we hit over these six months, reviewed afterward, was never once because the database lacked the answer. Every time, it was because we had failed to translate what the customer said into the right question to ask of it.

The four obstacles below are four faces of that one problem.

III. AI Understands Chinese, But Not the Trade's Own Language

The first obstacle showed up earliest and caught us most off guard: the AI's Chinese is excellent, but it is not the same Chinese that factories speak.

There is a category of consumer product that became popular very quickly. When customers come looking for it, they use the name that circulates on social media. On the factory side, not a single company registers itself under that name — what they write down is the name of the material and the name of the process, terminology the trade has used for twenty years. Both sides are talking about the same object, and not a single character overlaps.

The database holds several thousand of these factories, clustered densely in two or three specific counties, with products, size, and contact details all in place. And the first version of our product, facing that request, answered "no results found."

The data was there the whole time. We asked the wrong question.

Another kind of trouble runs in the opposite direction: one word pointing at two entirely different groups of factories. Take "molds." A company making automotive body panel molds and a company making molds for plastic household goods share almost nothing — not equipment, not customers, not the way they quote a price. The database separates the two cleanly, and the customer saying the word has only one of them in mind. It was the translation in between that never happened, so both groups were served up together.

The most telling case involved a manufacturer of industrial lubricating grease looking for customers. What he wanted were "factories that consume a lot of grease" — manufacturers in food machinery, metallurgical equipment, wind power equipment, all of them well represented and clearly classified in our database. The system read the sentence as "factories that produce grease," and diligently handed him a list of his own competitors.

Read literally, the interpretation was not wrong. Read commercially, every company on that list was a rival.

We later gave this class of error a name: direction reversal. What it exposes is something more fundamental: within an industry, the meaning of a word depends on where the speaker stands in the chain. An upstream salesperson, a downstream buyer, and a trader in the middle can all say the same category term and each need a completely different list. And that positional information is something customers assume you already know; they never volunteer it.

These three problems are, at bottom, the same problem: the words in a customer's mouth, the words a factory registers itself under, and the terminology used inside the trade are three languages that must be translated into one another. The raw material for that translation sits in our database, and in the experience of people who have spent years close to this industry. What was missing was the layer that teaches it to the AI.

Building that layer was the least glamorous, least technically impressive, and most useful work of the past six months.

IV. A List That Is "Roughly Right" Hurts More Than No List at All

The second obstacle took us the longest to learn to take seriously.

After the product was up and running, the team felt good about it for quite a while: customers stated their needs, the system produced lists, the pages looked good, and the speed was acceptable.

Looking back, the reason we felt good is simple — we are not the ones who source factories. During internal testing, the people asking questions were the colleagues who build the product and write the code. Their phrasing was tidy, their conditions explicit, everything a request should contain was there in one sentence. On questions like these the system performed admirably. Real customers phrase things every way imaginable: one packs seven or eight conditions into a single sentence; another remembers only in the fourth exchange to add "oh, right, I only want ones that can export"; another opens by pasting a string of company names and asking "are these any good?"

It was only when we began reading through the record of real conversations, one by one, that we saw a different picture.

  • A customer named three product categories, and the final list contained only the first
  • A customer said "between eighty and three hundred employees," and the list included plants with several thousand
  • A customer said "drop the export requirement," the system replied "certainly, I've removed it," and the list did not change by a single company
  • A customer named two specific cities, and factories from the entire province came back

One thing needs stating clearly here, or it is easy to misread: every company on those lists is a real, currently operating factory, and the data itself was not wrong. What was wrong were the conditions — the customer named three categories and only one was passed through; the customer drew a range and only the lower bound was passed through; the customer named two cities and a whole province was passed through. The database was accurate. We simply did not ask it the whole question.

And the most dangerous property of this class of defect is that it never throws an error. Nothing crashes, no page goes blank, the list sits there complete. Someone unfamiliar with the industry sees nothing wrong. Only someone actually sourcing factories takes two glances and knows: "what you've given me is not what I asked for."

In a B2B setting, a list that is roughly right does far more damage than the words "not found."

The cost of "not found" is that the customer rephrases and tries again, losing a few dozen seconds. A list that looks reasonable but is subtly off gets taken to the phone. After a day of calls, the first ten are all wrong, and he will not conclude that his conditions failed to get through — he will conclude that this tool is not worth opening a second time. We sell efficiency, and what we delivered was a wasted day.

What makes it worse is that this class of problem does not surface on its own. Unlike an outage, it has no clear timestamp and no clear scene. It sits quietly among several hundred normal sessions a day, waiting to be found.

And customers rarely tell you what went wrong. One left two words in the feedback box: "not right." Another said nothing at all, tried six different phrasings in a row, then closed the page and never came back. Customers willing to spend time pointing out problems are a tiny minority, and we have come to treat them as our most valuable resource.

We never found a clever solution. What we still use today is the crudest one available: read every real conversation, every day.

Not a sample — all of them. And the reader has to understand the business of sourcing factories, because whether a list is right is not a question a machine can answer. Only a person can. Afterward, every instance of "something's off" becomes a ticket, gets categorized, gets scheduled, and the next day there are new conversations to read. This has not stopped, and shows no sign of being able to stop.

It is not an efficient process, and it is hard to explain to outsiders why it is worth it. But every change that genuinely improved the product came from here. Not one came out of a meeting room.

V. The Most Dangerous Moment Is When the AI Wants to Help

The third obstacle is the one, out of four, that puts a chill down our backs.

Fabrication never begins with lying. It begins with wanting to round the answer out.

The system finds a dozen or so factories meeting every stated condition, decides that number looks too thin for the customer, and pads it with a few from elsewhere into a list that looks respectable. A customer asks about one company's production capacity — a field our database deliberately does not carry. That is not an omission: we only record fields whose source can be verified, and figures like capacity, output value, and equipment counts, which cannot be traced to an authoritative source, are left empty by choice. The AI, wanting to round the answer out, invented one and dressed it up in respectable-sounding phrasing. Asked to verify the finding again, it replied "certainly, verifying now," did nothing at all, and returned the same conclusion as before.

Every one of these answers is impeccable as language. The tone is sincere, the structure complete, and it reads as more reassuring than the honest version would.

Only after thinking it through did we realize the problem lies deeper: this kind of system is built for the express purpose of being helpful. Always having an answer is its default posture; returning a blank page is the outcome it most wants to avoid. Yet in factory sourcing the correct answer is often precisely "we don't record that" or "there really aren't many plants meeting all of your conditions at once." Teaching something whose whole vocation is helpfulness to stay quiet when it should is far harder than teaching it one more industry.

How serious this is depends on what the customer does with the output. For a copywriting tool or a chat companion, the behaviors above would count as blemishes at most. But our customers take these lists to approach major accounts, and take these capacity figures to decide whether to commit an entire quarter of sales resources. A number with no source is a wrong decision we made on the customer's behalf, and he has no idea he was overruled.

Worse, fabrication contaminates the clean database behind it. If a single company on a list was padded in, the other ten — the ten genuinely filtered out of 4.8 million verifiable records, every field traceable — lose their credibility along with it. What took us years to build can be undone by one respectable-sounding sentence.

One day a customer left a single line in the feedback box: "The data has to be real. Don't make it up."

No emotion in it, and no politeness either. That line was later written into our product principles as the first entry.

Today we hold several lines we will not cross: the company count on a list can only be the deduplicated number of records that genuinely exist in the database — not one more, and no company may be padded in to fill it out; capacity, output value, and equipment counts with no source are never written at all; and the system may not claim to have performed an operation it did not perform.

And the hardest line to hold: if we can't find it, we say we can't find it — and we make clear that we failed to ask the right question, not that such factories do not exist. There are 4.8 million real, actively operating factories in the database. A query returning zero almost always means we failed to understand what the customer said. Blaming the data is the easiest and least honest explanation available.

Holding these lines has a price, and the price is visible immediately: say honestly that "only five plants meet all of these conditions at once," and some customers will leave on the spot for a place willing to hand them twelve thousand. We accept that. Those twelve thousand are a category total masquerading as an answer, while each of our five survives a phone call. People who do business in industrial goods end up back on the side where things can be verified.

VI. It Is Never Simply Finished — Someone Has to Watch It Every Day

The fourth obstacle only took shape after all the features were finished.

Build a software feature and, once it is built, it is built. An AI system that people use every day does not work that way.

The things it depends on change. Upstream providers adjust, tighten quotas, and retire things that were working perfectly well, and none of these changes are negotiated with you in advance. The real trouble is never a total shutdown — a total shutdown is easy to notice, the page goes blank and everyone knows immediately that something broke. The trouble is the other case: it quietly falls back to a dumber state, keeps working, keeps answering, sentences fluent, lists tidy, only the questions it asks have gone coarse again, and the good material stays in the database untouched.

At moments like that, no alarm sounds. The only thing you can rely on is still a person reading real conversations.

The second thing is cost. Every conversation carries real expense behind it, and the bulk of it is usually not where you would look first. One in-depth read on a single company can cost dozens of times what an ordinary exchange costs. You do not think about this layer while building the product; once it runs a few thousand times a day, the ledger thinks about it for you.

The third thing is waiting. An experienced colleague who knows the trade does not fall silent for half a minute after you finish asking. Fast and slow are not decorative details of the experience here; they directly determine whether the customer asks a second question. And every verification we perform to make an answer more accurate costs time, while a customer's patience is finite — these two forces are still pulling against each other, with no permanent solution.

The distance between "building a feature" and "having someone mind a system every day" is exactly these six months.

VII. What We Believe After Six Months

Back to that line on the whiteboard: "I'm looking for a factory that makes seals."

Today, Tianxia Gongchang AI answers that sentence by asking a question first. Not by handing the customer a blank questionnaire, but by using the real industry distribution in the database as the material for the question: these factories cluster mainly in a few particular places, which one matters to you; this category comes in several materials, which is closest to your application. Two questions, and then it goes and pulls the list out of 4.8 million real, actively operating factories.

That is exactly what the experienced salesperson would do. It took us six months to teach software those two questions.

If only one sentence survives from these six months, it is this: the hard part was never whether the database had it. The hard part was how to ask.

Data compounds. Identifying, verifying, and updating 4.8 million factories took many years; it grows thicker by the day and will not depreciate through several more generations of models. Turning a customer's sentence into the right question to ask of it is a craft, and a craft has to be honed daily:

  • The language of an industry can only be accumulated by staying close to that industry over time
  • Discipline about conditions can only come from people reading them one by one
  • Honesty is a product principle that has to be held every day, not a one-time technical choice
  • Being operable means someone has to watch this system every single day

These six months went entirely into that second thing — the craft.

If you are looking for factory customers for your sales team, come and test what we built these six months; and please write whatever feels off directly into the feedback box — every improvement described above started there.

Try Tianxia Gongchang AI