What a cited lead brief contains
The anatomy of a cited lead brief: identity, a deterministic fit score with the rubric visible, evidence citations, masked contacts, and a ledger entry.
A cited lead brief is a lead record that carries its own justification: who the person is, the deterministic score that ranked them (with the rubric visible), the evidence the match was built on, what is missing, and contact fields that stay hidden until a metered, verified reveal. It is the unit CitedLeads works in, and it exists because a row in a spreadsheet cannot answer the only question that matters a week later: why is this person on the list?
Most lead tools produce rows. A row says that someone exists: a name, a title, a company, a column of icons hinting at data you cannot inspect. A brief says why they are there, and lets a colleague check the reasoning without asking you. The sections below are the anatomy.
Identity
The person and the account: name, role, company, and the firmographic facts the ICP matched on (segment, size band, geography, funding stage where the provider reports it). Identity is the minimum viable field set. It answers who, and on its own it is worth about what a CSV row is worth.
Everything below the identity block is what turns the record into a brief.
Fit score, with the rubric visible
Every brief carries a score, and the score is not a black box. The rubric is deterministic (the same inputs always produce the same score) and it decomposes into components you can inspect:
| Component | Points | What it measures |
|---|---|---|
| Title fit | 25 | How closely the person's role matches the roles in your confirmed ICP |
| Industry fit | 20 | Whether the company sits in the segment you described |
| Company-size fit | 15 | Whether headcount falls inside your range |
| Pain signal | up to 30 | Provider-backed signals that suggest the timing is right: hiring patterns, stack changes, and similar |
| Evidence completeness | 10 | How much of the record is actually sourced rather than inferred |
Two briefs can score 80 for completely different reasons (one on firmographic strength, one on a strong pain signal) and the rubric shows you which. A score you cannot decompose is just a number next to a name.
Two honest boundaries on what a score means:
- It is deterministic, not predictive. The rubric measures fit against your stated criteria. It does not predict conversion, reply rate, or willingness to buy, and no score anywhere does; treat any tool that implies otherwise as selling past its evidence.
- It is only as good as the ICP. A confident score against a vague ICP is a confident wrong answer. That is why the workflow puts a confirmation gate before any run.
Evidence citations
The defining section: the "cited" in CitedLeads. Each brief lists the evidence the match was built on:
- ICP criteria satisfied: which of your confirmed criteria this record meets ("B2B SaaS, 50-200 employees, North America").
- Provider-backed signals: the observations behind the pain-signal component, with the source and a freshness timestamp ("3 open platform-engineering roles, observed this month").
- What is missing: fields the evidence does not cover, shown rather than silently blank.
- Negative evidence: observations that count against the match, surfaced for the same reason a good analyst mentions them: so you can weigh the lead instead of trusting it.
Evidence comes from licensed provider data and your own inputs. There is no scraping path in the product (no browser automation, no extensions, no cookies, no personal-account sessions), and evidence explains the match. It is not an archive of someone's posts or private activity.
A brief that matched on segment and a hiring signal reads differently from one that matched on geography alone. The citation block is where you see that difference before you spend anything.
Masked contact fields
Email fields are present on the brief but hidden by default: m***@northwind.dev, not the real address. Revealing a contact is a metered, verified action:
- 1 credit = 1 verified, cited contact reveal. That is the only metered action in the product.
- If the provider path returns no email (a miss, an invalid, or an unknown), the reveal does not happen and the credit is not consumed.
- Catch-all (accept-all) results come back flagged as lower-confidence rather than marked verified. A reveal that returns an email is charged; the flag is honest labeling, not a free pass.
- If a verified contact later hard-bounces, report it and support credits the reveal back; the adjustment is a ledger entry like every other credit event.
- Revealing the same candidate again (in the same run or a later one) never consumes a second credit. Dedup happens at the candidate level.
Hidden-by-default is a posture, not a paywall trick: the product does not present unverified contact data as a deliverable. Reveals cover business email only; there is no phone reveal.
The ledger entry
Every credit event (monthly grant, LTD pool release, reveal, support credit-back) is written to an append-only credit ledger you can inspect in the product. Balances are derived from the ledger, not stored beside it, so the number you see is always the sum of entries you can audit. The brief's contact state and the ledger's accounting are two views of the same action; there is no off-book spend.
This exists because credit-metered pricing has a trust problem: buyers cannot verify what a vendor's counter actually did. A visible ledger turns "trust us" into a record.
What a brief is not
- Not a data-broker export. A brief is bounded to your run and your confirmed ICP; it is not a slice of a bulk resale database.
- Not a claim of intent. Evidence supports the match; it does not mean the person wants to hear from you. Qualification is what the evidence is for; the conversation is still your job.
- Not permanent. People change roles and companies change shape. Monitored briefs are re-verified on a cadence and change events are recorded; a brief is a maintained record, not a snapshot you re-buy.
- Not the product of scraping. Every external record arrives through licensed provider adapters. The sourcing story for any lead fits in one sentence, which is the point (see the data posture for the full list of what the product does not do).
The practical test
Hand a brief to a colleague. If they can answer "why is this person on the list" without asking you, the brief did its job. That is the bar the format is designed around, and it is why a run returns 50-100 briefs rather than 10,000 rows: the output is meant to be read, not dumped into a sequencer.
FAQ
Is the score an AI prediction? No. The stage-1 score is a deterministic rubric (title fit, industry fit, size fit, pain signal, evidence completeness), and it is reproducible for the same input. It ranks; it does not prophesy.
Does evidence mean the lead agreed to be contacted? No. Evidence explains why the record matched your ICP. It is not consent and it is not a guarantee of interest.
What does a reveal cost when it fails? Zero credits. Misses, invalids, and unknowns do not consume the credit. Catch-all results are flagged lower-confidence and are charged when they return an email (see how verification states work).
Can I see why my credits moved? Yes. The append-only credit ledger lists every grant, reveal, and support credit-back. If the meter cannot be audited, it is a claim, not a mechanism.
Is the product live? CitedLeads is in early access and currently runs on synthetic demo data while provider contracts clear. The workflow is real, the lead data is not yet live. Contact us to get on the list; the printed rate card locks what a credit buys at your activation.