Here is the uncomfortable truth about buying data: the file is not the product. Nobody buys firmographics to admire two million company rows — they buy them to join against a CRM export. Nobody buys foot-traffic data on its own — they buy the moment it lines up with their revenue table. The value of any dataset is realized at the JOIN, and everything before the join is cost.
Data scientists know this cost intimately. You acquire a promising dataset,
and then the real work starts: reverse-engineering which column is the key,
discovering that its “domain” column includes www. and yours doesn’t, that
one side has ISO alpha-2 country codes and the other alpha-3, that a
“per-company” table is actually per-subsidiary. Data fusion — combining
several sources into one coherent dataset — is where most of the effort of
using purchased data actually lives. Industry folklore says data scientists
spend the majority of their time preparing data rather than analyzing it;
whatever the true number, anyone who has done a cold merge of two vendors’
files knows it wasn’t the fun part.
The traditional data economy externalizes this cost completely. A marketplace sells you an opaque file; whether it joins with anything you own is your problem, discovered after payment. Every buyer of the same dataset re-derives the same keys, re-writes the same normalization, and hits the same surprises — redundantly, forever.
Fusion is a knowledge problem, not a compute problem
The merge itself is trivial — a single JOIN in DuckDB. What’s expensive is
the missing knowledge: what one record represents, which columns are join
handles, and exactly how their values are formatted. The seller knows all of
this. The buyer pays to rediscover it.
So we moved that knowledge to where economics says it belongs: declared once by the seller, verified by the platform, and readable by every buyer before they pay. We call it a join card:
{
"row_represents": "one company",
"join_keys": [
{
"column": "domain",
"description": "website domain, lowercase, no www"
},
{
"column": "hq_country",
"description": "ISO 3166-1 alpha-2 country code"
}
],
"grain_notes": "one row per company, ~2.1M rows, monthly"
}
A few free-text lines — no ontology, no registered vocabulary. The platform
checks, deterministically, that the declared columns really exist in the
listing’s response schema; a verified card earns the ⧉ Fusion-ready badge.
Lookup APIs declare both directions instead (accepts a domain, returns
traffic stats), which turns them into composable enrichment steps.
What changes for a buyer: plan, then pay
Agents buying on datapoint.market can now search by join handle:
search_marketplace(joinable_on="domain")
returns only listings whose card offers a matching handle — with the card, the schema, and a free sample inline. An agent holding a CRM export can plan the entire fusion before spending a cent: which listings join, on which key, what normalization each side needs (“lowercase, no www” is a spec, not a vibe), whether the grain matches. Then it buys, streams the file, and executes a merge it already understands. Fusion goes from “buy and hope” to “plan, then buy.”
Every listing also shows how many other listings share one of its handles —
joins_with — which quietly maps the catalog as a joinable graph rather
than a shelf of disconnected files. Each new carded listing makes the ones it
connects to more useful.
What changes for a seller: two minutes, more surface
A card costs a seller almost nothing — one join_card argument if your agent
lists for you, or two minutes in a guided form with the likely handles already
detected from your sample. What it buys is visibility where it matters most:
join-handle search only surfaces carded listings, fusion-ready listings
rank higher, and buying agents plan multi-source fusions in which your data
either participates or doesn’t exist.
Notably, there is no AI in the middle of any of this: sellers (or their agents) write the cards, buyers’ agents read them, and the platform only validates, indexes, and displays. The intelligence is bring-your-own on both sides — which means the whole mechanism gets better as agents do, at no cost to anyone.
Why this matters beyond one feature
Data has a network property that files-in-a-shelf marketplaces never exploit:
datasets are worth more together than apart. A firmographics table and a
traffic API are two products; joined on domain, they’re a third, better one.
Making joinability explicit is how a catalog starts compounding — and it’s the
foundation everything else can build on: verified match rates, reusable fusion
recipes, one-click composite datasets. First, the knowledge had to exist.
It now does, one card at a time.
Try it: the data fusion guide walks an agent through a full fusion — search, plan, buy, join, measure — and the join cards guide shows sellers how to become part of it. Can’t find data that joins with yours? Post the handle you need on the requested-data board and let a vendor build it.