Cold start is not a blank page

A few weeks ago I argued that the Semantic Web didn’t fail because ontologies were wrong. It failed on three costs. Designing the schema, populating it, and keeping it current. Maintenance is the one people name, and it’s the last of the three. The first two are easier to miss, and plenty of projects never got far enough for maintenance to become the problem.

I left two questions open there: whether a schema can be learned, and whether it can be populated without somebody typing it in.

We’ve now prototyped a simple subset of the first two. Here’s what we learned doing it.

The mistake in the phrase “cold start”

Cold start implies a blank page. No entities, no types, nothing to build on, and someone has to sit down and type the first thousand records. That framing is why populating a model looked so expensive, and it’s why every enterprise pitch for an ontology of your own business ended with a services quote.

Almost no company is actually starting cold. An entity list almost always already exists, it’s in the CRM, but it’s bad: duplicated, half-abandoned, with three records for the same account and a field nobody has filled since 2023. On DAFFIE, the entity database behind the question answering Google shipped in 2005, we faced a richer version of the problem, because the open web has no seed list. A business does.

So the first move is import, then correction.

What we did

We tackled customers first, because it’s the type every business has and the one with the most existing structure to lean on.

Import the seed. Pull the account list out of the CRM. Accept that it is wrong. What it gives you is a starting point: the set of names the business thinks it deals with.

Correct it from the message stream. Messages are a byproduct of doing the business, and updating a CRM field is a separate job somebody has to remember. So for an account you’re actively working with, the stream is usually ahead of the record. Titles, addresses, who actually works there now, which deals are live, what was agreed. The stream is the source and the CRM is the stale cache.

Find what the seed missed. Companies you deal with constantly and never created a record for. Somebody goes looking, finds nothing, and moves on. Incompleteness is half of why a CRM frustrates people and staleness is the other half. The stream has those companies, because the business has been talking to them the whole time.

Read staleness as a signal about the list. An account nobody has exchanged a message with in eighteen months is probably an ex-customer. The CRM still calls it a customer, but the stream can say otherwise, so a record the stream never touches is a reason to ask whether it belongs on the list at all.

None of that required anyone to type a record from scratch. It did require people to correct what came back, which is a much smaller job. Reacting to a filled-in record takes seconds and you can do it while you work. Producing one from nothing made populating a model expensive in the first place.

The part I did not expect to work

Customers were the easy type. The harder question, the one I said in the last piece that nobody had solved, is which types a business runs on at all. Customers and competitors and products for one company; venues and artists and promoters for another.

We didn’t solve that. What we found is that a machine doesn’t have to do it on its own.

Run over the message stream and clusters of proper nouns behave differently depending on what they are. The things a company treats as customers get talked about in one set of patterns; suppliers in another; the tools they use in a third. Those patterns are strong enough to propose a type, which is a much smaller ask than deciding on one.

So the system proposes and a person answers. Is this a type you care about? The nos turned out to be as useful as the yeses, because a rejected type needs no further analysis.

Call it schema suggestion with a human in the loop, and the loop is short enough that nobody minds.

Why this does not collapse into the old failure

What killed hand-maintained ontologies wasn’t the idea of types. It was rigidity: every customer must fill in these eleven attributes, and someone owns keeping that list right. Unisys wrote their SharePoint metadata up for Dublin Core in 2005, and the controlled vocabularies were maintained on a spreadsheet by a Corporate Knowledge Architect.

What we build is lighter. Types are load-bearing: knowing that Acme is a customer rather than a competitor changes what an agent should do with a message from them. A fixed attribute list isn’t, and it’s what required the staffed role.

You need enough structure that an agent can act, and no more.

What is still open

Types with no seed. Customers imported cleanly because the CRM had a list. Nobody keeps a system of record for “the operational rules we follow when a client escalates,” and that knowledge is the reason this whole problem is worth solving. The proposal loop above helps, but doesn’t finish the job.

Whether the list maintains itself. We built it once, at import. A business changes after that: it starts dealing with companies that were never on the list, and stops dealing with ones that still are. Catching both without anyone watching is the part we have not shown, and it’s the same trap as the last twenty years, because the cost that never ends is the one you can’t evaluate in a quarter.

Whether it generalizes. The entity types one business runs on aren’t the types another one does, and nothing here has been tried across enough of them to say how far it carries.

Why this is worth doing now and was not in 2005

The argument from the last piece stands. Structure created this morning gets used this afternoon, because the consumer finally exists. In 2001 you wrote RDF for readers nobody had built yet, and the work sat waiting. That deferred reward is why every hand-maintained model of a company decayed, and it is exactly what happens to the wiki nobody has touched since the person who wrote it left.

An agent reads what you wrote down today. That changes the arithmetic on all three costs, and it’s why the second one turned out to be tractable when it hadn’t been before. The first got easier at the same time, once proposing a type replaced deciding on one.

Upkeep splits in two, and only half of it is answered. Keeping the data about an entity current is what the last piece argued: a workflow that corrects a field as it runs is maintenance nobody has to schedule. Keeping the list itself current is a different problem, and we have done that once, at import. Whether a company you started dealing with last week joins the list on its own, and whether one that went quiet a year ago drops off it, is still open.