Enrich profiles

Settings → Enrichment looks things up that aren't in your database at all.

Profiles is for who a profile is, from your own tables. Usage is for what they do in your product. Enrichment is for everything else — the parts of "is this a real person with a real project" that only exist outside your database: whether their store is live, what it's built on, how long their domain has existed, whether that signup address is a throwaway.

Whatever it finds lands as an ordinary property. Your rules filter on it, your scoring models take it as a factor, your monitors read it. Nothing else has to change.

Probes, not properties

You turn on a probe — one lookup — not its individual properties.

That's deliberate, and it's about money. One read of someone's homepage answers nine questions at once. If you could enable those nine properties separately you'd either pay nine times for the same page or be relying on invisible machinery to notice they belong together. So the toggle is on the lookup, and the properties it produces are listed underneath it.

This is true of the probes you write, too. A probe you author is one input, one lookup, and as many questions as you want over it — five questions about a store cost barely more than one, because they're all answered from the same page read. Four probes ship ready-made:

Email shape and Domain record cost nothing to run — they read public records, with no vendor behind them. Turn those on first.

The list reports; the probe's page decides

Settings → Enrichment lists every probe with what it reads, who it runs on, what it costs, and whether it's on. It's a read — nothing on that screen spends money.

Everything else happens on the probe's own page: pointing it at a property, choosing who it runs on, seeing what it produces, trying it, and turning it on. The on/off switch lives there because that's the only place you can see what you're agreeing to — the estimate sits directly underneath it, and it moves as you narrow the scope.

Point each probe at one of your own properties

A probe doesn't guess which of your columns holds a store URL. You tell it, once, on the probe's own page: "Where their project lives" → your store_url property.

That's why there's no separate "field mapping" screen to configure first. The binding happens where it's explained, and it's per probe — so if you keep both a store URL and a portfolio URL, you can point Site read at one and a question at the other. Uptend preselects a likely property to save you the work; change it if the guess is wrong.

Probes can also read what other probes produce. Site read collects social_links; point Social profile at that key and the chain works with nothing special to configure. Each link in a chain runs one cycle after the one before it.

Who it runs on

This is the setting that decides your bill, and it has two parts.

Include profiles you already have. Off by default on anything that costs money. Turning a paid probe on with this off means it runs on profiles that arrive from now on — nothing is charged for your back catalogue, and the estimate on the page says so. That's almost always what you want the first time: a workspace with 50,000 profiles, most of them long since churned, does not want its first act to be 50,000 outbound lookups about accounts nobody is going to sell to again.

Turn it on when you've seen what the probe returns and decided the history is worth paying for. Free probes start with it on, because there's nothing to protect you from.

Which profiles. On top of that, narrow to the profiles worth the money:

The count under the control is live: narrow the scope and watch the estimate shrink before you commit to it.

Try it before you turn it on

Try it runs the probe on a handful of real profiles — 5, 10 or 25 — and shows you every property it produced, the evidence behind each one, the ones it dropped and why, and what the calls actually cost.

Each result is headed by the profile and the value that was actually sent — the email, the domain, the store URL the lookup read — so you can check the input before you trust the answer. The profiles it reads are drawn from the scope you've set, so what you see is what the rest of the run will look like. Nothing is saved: no properties land on those profiles, no ledger entry, no state. The calls are real and really charged, which is why it's a button and not something that happens as you type.

Twenty-five lookups costs a few cents and is the cheapest question you can ask about a probe. A probe that reads nine out of ten of your customers' sites and nothing at all for one segment shows that at twenty-five and hides it at five.

What a probe produces

The probe's page lists every property it produces, each with what it actually holds — the key your rules will use, its type, whether it's meant for scoring, filtering or reference, and a line saying what the value means. Read that list before you turn a probe on: these keys are about to become part of your profile vocabulary, visible in the scoring editor's picker, the profiles table and every rule.

Coverage: the number worth looking at first

The count under the scope control is the number of profiles in scope — the one that moves when you move the control. When the probe's input is the problem rather than the scope, a second line says so above it:

You don't have a property for this yet. Ask for it at signup and this probe becomes useful for everyone.

or, with the number attached:

Runs on only 1,100 of 12,000 profiles (9%).

This is the most valuable thing on the page, and it works before you turn anything on. No provider can tell you about a customer you have nothing to look up. If most of your profiles carry only an email, the highest-leverage change you can make isn't buying data — it's adding one question to your signup form: "what's your website or store?"

The coverage line tells you which input is missing and what it would unlock, on the probe it would unlock.

Write your own probe

The ready-made probes can't cover everything, so you can write your own. Add probe gives you the same thing Site read is: one input, one lookup, and a list of plain-English questions answered from it.

Say you sell to e-commerce stores. Point one probe at your store_url property and ask it everything at once:

That's one page read, one charge, and five properties. Asking them as five separate probes would read the same page five times, charge five times, and hit the store's server five times.

Five things make each answer safe to filter and score on, and they apply per question — one weak answer doesn't cost you the four good ones beside it:

1. A declared answer type. Yes/no, one of a list, a number, or a few words — never free-form prose. A column of paragraphs isn't data.
2. A declared input, shared by every question on the probe. That's what makes one lookup legitimate, and it also tells you the coverage before anything runs.
3. Evidence. Each answer cites at least one page it actually read, shown beside that value on the profile. An answer that can't cite anything is dropped, and the profile says so.
4. A confidence floor, per question. Below it that answer is dropped rather than stored. A hedge stored as a value would be filtered and scored as if it were certain.
5. A trial run on real profiles, before you save — every answer, its evidence, and what the calls actually cost.

"Unknown" is always an option on a list question and is always a real answer. A profile whose site doesn't say is different from one nobody has looked at.

Editing a probe

Changing a question's wording, adding one, or pointing the probe at a different property changes what its answers mean, so the stored answers are thrown out and the probe re-runs. That's the same price whether you edited one question or all of them — it was always going to be one call — so edit freely.

Renaming a probe, pausing it, or changing who it runs on changes nothing about what past answers meant, and costs nothing.

What it costs, and how it stops

Set a monthly ceiling in the Spend section. When the month's spend reaches it, the queue pauses: nothing further is charged, and the work that didn't run stays queued for next month. It's never a surprise invoice, and it's never silently dropped work.

Before you enable anything expensive, the probe's page shows the estimate — profiles in scope × cost per profile — and Try it shows what a handful of real calls actually cost, which is the more honest number. Turning a paid probe on asks you to confirm, with that estimate in the question.

Because a probe's questions share one lookup, adding a question to an existing probe is close to free. If you're wondering whether something is worth asking, it's cheaper to put it on a probe you already run than to stand up a new one.

Two things keep the ongoing cost down without you doing anything:

• Answers are cached until they go stale. Each probe has its own refresh window — a domain's registration date never changes, a follower count does — and nothing is looked up again until the window passes or the input itself changes.
• A dead end stays dead. A domain that doesn't resolve, a site that's gone: recorded as "no result" and left alone for months, rather than re-checked every cycle.

Beyond that, the two levers that matter are both under Who it runs on: leave the back catalogue out, and narrow to the profiles worth the money.

On a profile

Each profile's Looked up card shows what was found, when, what it cost, and — beside each value — the pages that answer came from. Questions the lookup couldn't answer are listed too, with the reason: nothing cited, confidence too low, or simply not stated on the pages read. Enrich now re-runs the lookups for that profile — including probes whose scope would normally exclude it, because asking about one profile by hand is an override on purpose.

If a value is wrong, correct it by hand like any other property. The correction wins, and no future lookup overwrites it. (This is a real difference from usage metrics, which are computed from your own database and can't be corrected — enrichment is us making a claim about the outside world, and you're entitled to know better.)

Turning facts into judgments

Enrichment gives you facts. Deciding what they mean stays with scoring:

• Legitimacy — is_disposable, name_plausibility, has_mx, site_live as factors on your fit model.
• Stage — domain_age_days, last_published_at: is this an idea, a launch, or an established business?
• Traction — product_count_band, follower_count as factors on your value model, and as the property a milestone such as "worth a person's time" watches.
• Segment — site_platform, detected_tools, or any answer from a probe you wrote, read by the rules that filter and group profiles.

Enriched properties show up in the scoring editor's property picker like any other. There's nothing extra to wire.