You get no e-mail addresses and no phone numbers. That is the whole difference.

No e-mail addresses. No phone numbers. No names of decision-makers. There is also no field where they could appear later, no setting that unlocks them, and no more expensive plan where the contacts are included.

This is not an unfinished feature. The database schema has no column for a person's name, e-mail address or phone number on the target-company side. Putting a contact into a record would take a schema migration and a rewrite of the module that queries the register — not a toggle in a settings panel.

So if what you need is a file of addresses you can mail tonight, this is the wrong product, and there is no point buying a run to find that out. If what you need is an answer to “which company do I call on Monday, and what do I open with”, read on.

• The company. Name, domain, city, legal form and activity codes, plus the Polish tax and register identifiers where a register entry could be matched to it with confidence. The record describes an entity, not a human being.
• Why it fits. What the company does, at what scale, and which part of your offer has a job to do there. A sentence you can argue with, not a score with nothing behind it.
• Why now. What happened recently and when: a new plant, a change in the management board, a job posting that gives away a project, a move into a new market. Every one of those bullets points at a stored signal, and a signal carries a date.
• The source. The page the fact was read from. The source column is required, so a signal that cannot say where it came from fails to save at all rather than saving in a weaker form.
• A way in that you open yourself. The switchboard, the contact form on the company's own site, the careers page, the public address the company publishes about itself, a letter, a stand at a trade fair, someone you both know. Those channels exist because the company chose to publish them, and it decides who uses them — which is why you open the door, not the list.

The rule has two layers and both are in the code. The first is about the register. Every lookup goes through one adapter, and a search result marked as a natural person, or as that person's local unit, dies there — before any detailed report is requested. Only legal entities are enriched, so a sole trader's entry, which is a named individual and very often their home address, never enters the database.

That distinction matters more than it looks. A limited company's entry describes an organisation. A sole trader's entry describes a person who lives at that address. Products that hoovered up both then have to answer, every day, whether they told each of those people that they hold their data — and in Poland that answer has already been expensive. Pursiva answers it by not holding the database in the first place.

The second layer is about the writing. People appear in results only by role: the new finance director, the plant manager, whoever owns IT purchasing. Every prompt that writes a sentence a seller will read carries that rule with it. The one exception is a family name that forms part of a company's registered name, because that is exactly how the register spells it.

The result is a list that tells you everything about the organisation and nothing about a particular individual. Who to ask for, and how to reach them, you work out the way you always did: from the company's own site, its own announcements and the roles it advertises itself.

At the end of a run every company goes through one more test: a deterministic check against the exclusions and legal forms in the profile you approved earlier. If you excluded sole traders, or companies under some size, that check reads the stored record and compares it with the profile you signed off.

It is code, not judgement. The check does not guess at intent and does not have good days and bad days — it looks at the legal form, the codes and the size that are actually in the record. A row that cannot clear it is held back and does not go out with the rest, instead of arriving as something you have to weed out.

The rest delivers itself. The run mints its own results link and sends its own notification, within an hour of payment, with no queue and nobody in Pursiva sitting down to the list first. If you want to see what a full set looks like, weak rows included, there is one run published whole and uncut.

Frequently asked questions

Why do I not get e-mail addresses?

Because Pursiva never collects them. There is no column for a person's e-mail address or phone number on the target-company side, and sole-trader entries are dropped before their record is ever opened. You get the company, the reason to talk and the source; the channel — the switchboard, the contact form, the careers page — you open yourself.

Can I add the contact details myself?

Yes, and in practice that is how it goes: you take a company off the list, open its site and find the route the company itself publishes. From that point it is your processing, on your basis, with your obligations. Pursiva adds nothing to it and knows nothing about it.

Is this GDPR-compliant?

That is a question about your outreach, not about this list — and only the second half of it can be answered honestly. On Pursiva's side: sole-trader entries are not read, no person's name, e-mail address or phone number is stored or returned, and individuals are described by role. On your side: it depends on who you write to, through which channel, and on what basis. The product does not settle that for you and does not pretend to.

Read next

• Data and compliance
• Buying signals
• Recruitment agencies
• A run published whole, with the rows that did not work
• Start a run