Companies, not people.
Pursiva researches Polish companies and returns a ranked list with the evidence behind it. This page says what that means for the data: what is stored, where it came from, what is never touched, and which of those rules the code enforces rather than the policy promises. Questions: hello@usepursiva.com.
This is a description of how Pursiva works in practice, written by the person who built it. It is not legal advice, and nothing here tells you whether your own use of a list is lawful.
What does Pursiva store about a company?
Company-level facts, and the sources they came from. Nothing that identifies a person sits in any of it.
- Company name, website and the normalised domain it is keyed on.
- City, and the registered address as the public register states it.
- PKD activity codes, legal form and registration status.
- An employee estimate, when a source states one or clearly implies it.
- A short description, and the text of the pages we read, kept so a claim can be re-checked later.
- NIP, REGON and KRS, when a registry record could be matched to the company.
- Signals: what happened, the date the source states, a short snippet, and the URL it was read from.
Everything a list shows about a company resolves to one of those rows. If it cannot be traced to a stored source, it is not in the product.
What does it never store or return?
- No individual's name, email address or phone number — not for a decision maker, not for anyone else. People are described by role: “the new CFO”, “the plant director”. The one exception is a person's name that is part of a company's registered name, which is how the register itself writes it.
- No sole trader register entries. A one-person business's entry is that person's name and often their home address; those search results are discarded before any detailed record is requested.
- No contact list of any kind. Pursiva returns companies, reasons and sources — it does not build an address book, and there is nothing in it to send a message to.
- No purchased data. There is no bought contact database behind the product and no data broker in the chain.
- No outreach. Pursiva sends nothing to anyone on your behalf.
Where does the data come from?
- The company's own website, fetched through Cloudflare Browser Rendering and stored as text, capped per page.
- Public web research through Google Search grounding: news, trade press, announcements, job boards. Every claim that survives keeps the URL it was grounded on.
- The GUS REGON register (BIR 1.1), the official API of Statistics Poland. Commercial use is explicitly permitted and the register is public under the Public Statistics Act.
Three sources, all public, all named on the page where their output appears. Anything a source does not say, the product does not claim.
What is enforced in code
Four of the rules above are not statements of intent. They are properties of the system, and breaking one would take a schema change or a rewritten module, not a careless afternoon.
- 01
Sole traders are dropped before their record is ever opened
Every registry lookup goes through one adapter. A search result of REGON type F — a natural person — or LF, their local unit, returns nothing before any detailed report is requested. Only legal entities are enriched, so a one-person business's register entry, which is a private individual's name and often their home address, never enters the database at all.
- 02
There is no column that could hold a person
The database schema has no field for a target person's name, email address or phone number. A company row holds a name, a domain, a city, activity codes, an employee estimate and a description; a signal row holds a title, a snippet, a date and a source. Storing a contact would require adding a column and running a migration — it is not something a prompt or a bad day can produce.
- 03
A claim with no source cannot be written down
The source URL on a signal is a not-null column, so a signal that cannot cite where it came from fails to save rather than saving weakly. Every “why now” bullet has to cite one of those signals by id. Provenance is not a quality bar the model is asked to meet; it is the shape of the record.
- 04
A tax number has to prove itself
A NIP sitting in a footer or on a contact page can belong to the company's web agency, its accountant or a payment operator named in its terms. When the number was scraped from a page, the registry record it opens is attached only if that record plausibly describes the same company — the names have to match, and matching cities alone is not enough. Otherwise the record is discarded and the company simply stays unverified. The same care picks which page to read for a tax number: only the last part of a URL is scored, so a company's contact page is fetched and a named colleague's profile page is not.
Where the rule is hard, and where it is soft
The people rule is structural for stored fields: the column does not exist. For free text — a description, a signal snippet, a “why now” line — it is an instruction plus review: every prompt that writes seller-facing text carries the rule to name no individual, and every list is read and approved by hand before it is delivered. There is no automatic redaction pass in the code, and we do not claim one. If you ever find a name in a delivered line, hello@usepursiva.com reaches the person who wrote the prompt.
Data taken from somewhere other than the person usually has to be disclosed to them. How does that work here?
It is a real duty and the hardest one in this market. Where personal data is obtained from a source other than the person themselves, GDPR art. 14 requires telling that person who holds the data, what is held and from what source — and in Poland a supervisory decision against a company that had reused a public business register, upheld on appeal, rejected the argument that reaching everyone would cost too much.
Pursiva's answer is narrower than a defence. The duty runs to a data subject, and these records describe companies: sole trader entries — the case where a business record is a person — are never read, and no individual's name, email address or phone number is stored or returned. A product built on a database of people has to answer this question every day. Pursiva answers it by not holding one.
That is a statement about what Pursiva processes, not a legal opinion, and it stops at delivery. If you take a list and add contacts of your own, that is your processing, on your basis, with your duties.
Who is responsible for actually contacting the companies?
You are. Pursiva finds companies and the evidence for approaching them; it contacts nobody on your behalf and hands you no address list to do it with. The channel you choose, and whether that contact is lawful, are yours as the sender: in Poland, direct marketing by phone or email has needed the recipient's prior consent since the Electronic Communications Law came into force in November 2024, and business recipients are covered too.
That points at the rule. It is not advice, and nothing in a result says that a message you send is lawful.
My company appeared in someone's list. Can I have the record corrected or removed?
Yes. Write to hello@usepursiva.com with the company name and its domain — no form, no account. We answer within 30 days.
Correction means the stored record and the signals attached to it are fixed or dropped. Removal means the company and its signals are deleted. There is no automated suppression list yet, so a removed domain is kept out by hand; if you ever see the company come back, one reply is enough to have it taken out again. A list already delivered to a seller sits behind a link that expires 30 days after delivery.
What about my own data, as a seller using Pursiva?
That is collected from you directly — your website, your email, the offer text and the profile you confirm — and it is covered by the privacy notice, which says what is kept, for how long and how to have it deleted.
Who else touches the data
The list is short, and this is the whole of it.
- Cloudflare — hosting, page fetching, and the AI gateway every model request passes through.
- Google — the Gemini models that read pages, research the market and write the summaries, reached through that gateway.
- Supabase — the Postgres database. The project runs in Frankfurt.
- Resend — the “your results are ready” email and the weekly watch digest.
- PostHog — product analytics, EU instance.
That is the list as it stands, named honestly. What contractual transfer mechanism sits behind each vendor is not something this page can state from the code, and a wrong characterisation is worse than a blank: ask at hello@usepursiva.com and you will get the paperwork rather than a guess.
Ask a person
Pursiva is run by its owner, and this page is answered by the same person who wrote the code it describes. If procurement needs something this page does not cover, write to hello@usepursiva.com and say what you need it for.