Turning Coffee Data into Coffee Knowledge

04Why this is possible now and was not before

Shared reference bases used to take a decade to negotiate. A standards committee argued about field definitions, published a specification, and then discovered that nobody in the field could be bothered to fill in the forms.

Three things changed.

That finding shaped our architecture more than any other. The entry point is a messaging app people already use daily, not an application to download. Input is free-form text or voice, not a form. When the system is unsure it asks one short question rather than silently guessing. And the original message is preserved before anything is interpreted.

The aim is to keep typing to an absolute minimum. Photograph the drying beds in the afternoon. Record a voice note saying how long the ferment ran. Take a short clip while the pile is being turned. Or let the meter at the collection point report its own readings. Every one of those routes reaches the vault — the system does the work of turning them into structured knowledge, not the person.

Nobody should have to become a data-entry clerk to get their own knowledge on the record.

Structure used to be cheap and contribution expensive. That has inverted. Contribution is now easy; getting the structure right is the hard and valuable part.

The picture above is the whole idea in one frame. Every box is a thing that exists — a person, a place, a batch of coffee, a measurement, a term from a controlled vocabulary. Every line has a name and a direction. A conventional database would store the farm's altitude in one column and the cupping score in another table, and the connection between them would live only in whatever query someone happened to write. Here the connection is the data.

That is what makes a question like "farms at a similar altitude and soil to mine — which processing method gave the highest cupping scores?" answerable at all. To answer it a system walks from a farm to its conditions, out to comparable farms, from those farms to their lots, from each lot to its processing method and its score, and back with a ranking. That is a multi-hop relational query. Keyword search cannot do it. Vector similarity cannot do it reliably either, because retrieving passages that sound related is a different operation from following a verified chain of relationships.

We call this approach mission-driven ontology design, and it has one governing rule: nothing enters the schema without a competency question behind it — a real question a real participant needs answered. If no one is asking it, we do not model it. That rule is what keeps a knowledge base from becoming an elegant, expensive, unused taxonomy, which is how most of them have died.

There is a practical note for anyone worried about cost. In a property graph, query cost comes from the volume of instance data and the depth of traversal, not from how rich the schema is. A broad, well-designed structure with a modest amount of data is fast and cheap to run. You can be generous with structure and disciplined with data at the same time.

05What each participant deposits, and what each one withdraws

A commons only works if the exchange is real for everyone in it. Here is our account of it, stated plainly enough to be argued with.

And everyone withdraws the compounding. The tenth roaster's cupping data makes the first farmer's benchmark better. The hundredth farm record makes every altitude comparison sharper. This is the property that makes a commons worth building rather than a product worth buying: the value of your deposit grows because of deposits other people make.

06Trust is what makes deposits from strangers usable

A shared vault has a problem a private database does not. If contributions come from many parties with different interests, why should anyone believe what is in it?

The answer is not to trust contributors more. It is to record how we know each thing.

A statement from a person is a claim, stored with its provenance: who said it, when, extracted from which original message, by which model, at what confidence. The original message is stored before extraction, always. If the model misread it, or the extraction improves later, the contributor's actual words are still there and can be reprocessed. Nothing anyone contributed is lost to a parsing error.

A sensor reading — near-infrared moisture at a collection point, satellite deforestation monitoring — is evidence. Its interpretation is a separate observation claim.

When claim and evidence agree, the claim is promoted from asserted to verified. When they conflict, it is flagged as contradicted, and nothing is deleted. A flag does not mean someone lied. Instruments drift and processes vary. The system marks an inconsistency for a human to look at; it does not pass judgment.

This is the mechanism that makes an open vault usable commercially. A roaster does not have to trust a farmer they have never met. They can see that a claim about honey processing was corroborated by a moisture reading, and decide accordingly. Verification, not credulity, is what lets strangers transact on shared knowledge.

We also make a deliberate choice about instruments. Not on every plot. Sensors belong at bottlenecks — the cooperative's collection point, the satellite pass — where one device validates hundreds of claims. Per-farm sensor deployment has never made economic sense for smallholder agriculture and still does not.

07Vocabulary is a contribution, not a constraint

One design decision looks small and turns out to matter a great deal for a commons.

The standard flavour wheel is built on reference fruits that make sense to a North American or European palate: blueberry, blackcurrant, cranberry. Ask a farmer at 1,200 metres in Chiang Rai to describe her coffee in those terms and you have asked her to describe her own crop in a language borrowed from a place she has never been.

So the vault supports pluggable, versioned flavour schemes with curated mappings between them. A Thai farmer describes her coffee in lychee, longan, mango, tamarind and roselle; a buyer who needs the international vocabulary reads it in mapped equivalents. Both are correct. Neither loses precision.

Framed as a commons, this stops being a local accommodation and becomes a contribution. A Thai or Asian flavour scheme is a piece of sensory knowledge the coffee world does not currently have in structured form. So is an Ethiopian one, and a Colombian one. Every origin that describes its coffee in its own terms and maps those terms into the shared structure makes the whole vault more expressive.

The general principle runs well beyond flavour: a knowledge system that forces people to describe their world in someone else's vocabulary collects worse knowledge. That is not a cultural nicety. It is a data quality argument.

It helps to picture the vault geographically. Any mapping tool can already show where a farm, a washing station, a warehouse and a roastery sit. What it cannot show is that this sack in that warehouse came from those three plots, was processed on a particular day, and carries a moisture reading consistent with what the miller recorded. Switch the knowledge layer on and the pins stop being pins. They become a chain anyone can walk in either direction — forward from a plot to the café that poured it, or backward from a bag on a shelf to the farm and the person.

Every new participant is a new node type attaching to a Lot that is already in the graph. That is the payoff of designing the ontology properly: the second stakeholder is far cheaper to add than the first, and the tenth is nearly free.