Trust & data handling
As of 2026-08-17. Every claim below is labelled Verified Planned or Not offered — and the honest headline comes first:
LeadSmart is at the design-partner stage. No customer's data has ever entered the system. The platform is built and tested end to end — the collection edge runs in production on this domain — but every behavior described below has been verified with our own synthetic and dogfood data, not with a customer's. We would rather tell you the stage than imply a maturity we have not earned; the same instinct runs through the product, which labels an unmeasured number rather than dressing it as a measured one.
What LeadSmart is, in one paragraph
LeadSmart measures fiber-ISP marketing at the household level: which campaigns created serviceable-address checks, orders, and durable installs. The unit of identity is the service address, not the person and not the cookie. That choice shapes everything on this page — the sensitive thing we hold is a list of addresses and what marketing touched them, so the controls below are built around addresses.
Where data flows
01
Your website tag VerifiedA ~3KB first-party script sending explicit events over POST. Addresses travel in the request body, never in URLs. Identity is a first-party HttpOnly cookie; the tag sets nothing before the edge authenticates the site.
02
Collection edge (Cloudflare) VerifiedAuthenticates the site's write key and origin, strips any identifier not on a short allowlist, truncates IP addresses to /24 before anything is stored, and queues each accepted event durably before storage.
03
Raw event store (Cloudflare R2) VerifiedAppend-only plain files (NDJSON), per-tenant prefixes. This is the exportable source of truth — a tenant can take these files and walk away.
04
Warehouse & models VerifiedAddress resolution, household stitching, attribution. Everything here is a rebuildable projection of the raw files — and every rebuild path re-applies erasures first.
05
Batch files you upload VerifiedCRM, mail-house and knock-list files enter through one console door with per-row receipts: a row that cannot be loaded is quarantined with a reason and your file's own line number, never silently dropped.
What we hold — and what we refuse to hold
- Service addresses Verified
- Street, unit, ZIP — normalized and keyed. This is the product's core data class and the one every control below is built around.
- Web interaction events Verified
- Explicit events only (page view, address check, plan selection, order) with campaign context. No session replay, no scroll tracking, no fingerprinting.
- Hashed email (
email_sha256) Verified - A SHA-256 digest of the normalized address — never the mailbox itself. The hash is computed in the visitor's own browser; the raw address never reaches our servers, and our collection door strips any identifier that is not on its short allowlist, by name. The digest is deliberately unsalted, because its one purpose is ad-platform audience matching: Google Customer Match and its peers match on exactly this recipe, and a salted hash would match nothing. Honesty about what that means: an unsalted email hash is pseudonymous, not anonymous. Someone who obtained our stored digests and already held a list of candidate email addresses could confirm which of those candidates appear — hashing prevents reading the list, not testing guesses against it. That is the standard trade every hashed-audience platform makes, and we would rather state it than imply the hash is unbreakable. What bounds the exposure: no phone number, no name, and no raw mailbox exist anywhere in the pipeline; IP addresses are truncated before storage; and an erasure request removes the digest along with the household it described.
- Phone numbers, names, raw email Not offered
- Structurally refused. The edge allowlist admits
email_sha256andorder_id; anything else is stripped, with only the refused key's name recorded as evidence. The batch door has no phone or name mapping path. - Precise IP, cross-site identifiers Not offered
- IPs are truncated to /24 at the edge before storage. There is no third-party cookie, no cross-site graph, and competitor-ISP reporting is aggregate-only by construction — the model carries no join key at all.
Consent, suppression, retention, erasure
- Consent on every event Verified
- Consent state travels on each event. A declined visitor is excluded from the identity graph — not merely from marketing activation — and Global Privacy Control is honored globally: a GPC signal can only ever add a decline, never remove one. A decline is honored on the visitor's own machine too: the tag's one remaining request is an identity-clearing receipt — the consent verdict and nothing else — and the collector answers it by expiring the first-party identifier it set.
- Suppression at the moment of export Verified
- Out-of-band opt-outs live in a durable register, and every audience that leaves the system passes one chokepoint that re-applies suppression and consent at export time — a merged household is suppressed across every spelling of its address.
- Erasure that survives rebuilds Verified
- An erasure purges the household from every projection and writes a permanent filter that every rebuild and re-ingest path consults — so a restore or replay cannot quietly resurrect an erased household. Raw stored files are retained under our custody terms; per-record rewriting of the raw archive is not offered, and we say that rather than imply it.
- Retention Planned
- Today retention is a per-tenant reporting preference: the system reports what has aged past it and deletes nothing on its own. Enforced deletion lifecycle is not scheduled; if a partner requires it, that is a priced roadmap conversation, not a silent commitment.
- Contract language Planned
- The pilot contract states exactly the behaviors above, and privacy counsel reviews that language before any signature. The compliance-semantics package for that review — including CPRA profiling classification — is assembled and waiting on the review itself.
Access control and tenant isolation
- Tenant isolation at one door Verified
- Every warehouse read passes a single gateway that requires a tenant scope and composes the tenant predicate itself — there is no second query path. Erasure and export operations carry the tenant in every predicate, proven by cross-tenant tests on shared addresses.
- Operator-only console Verified
- The console is for the operator's own team; people are provisioned by staff, and there is no self-serve signup or invitation flow to attack. Narrowing a membership to named properties binds on tenant settings and the audit log.
- Credential handling Verified
- Bring-your-own vendor keys never reach the browser — the edge proxies them. Admin credential fields are write-only. CI scans every push for leaked secrets.
- Production access boundary Planned
- In-app MFA is not offered; the ruled boundary for hosted deployments is Cloudflare Access in front of the console, enforced when the production host stands up. Per-service credential splitting is a named release gate for the same milestone.
Hosting and subprocessors
- Cloudflare — the collection edge: Workers, Queues, R2 object storage, KV configuration. This is the one subprocessor in the data path today. Verified
- Warehouse and console hosting — pre-production; no hosted deployment holds customer data, because no customer data exists in the system. Host standup is the current critical path, with named security gates (credential split, independent recovery copy, edge rate limits) that close before real data arrives. Planned
- Ad platforms (Google, Meta) — only ever receive a hashed audience an operator explicitly exports, and only after that operator's own counsel has signed off in writing — the console refuses the export until the attestation is recorded. Verified
Backup, recovery, export, offboarding
- Backups and restore Verified
- Control-plane backups resolve to a credential family independent of the data path — a production deployment refuses to boot without one — and the restore procedure is drilled into a scratch database: a restore has been practiced, not merely scripted. Every documented rebuild re-applies erasures before data moves.
- Second raw copy Planned
- The raw store currently has one copy; an independent second copy is a named release gate that closes before customer data arrives.
- Export and offboarding Verified
- Raw events are plain NDJSON files under your tenant's prefix — exportable in full, auditable by your own analyst, and the basis for walking away. Nothing we compute is withheld from recomputation.
- Availability commitments Not offered
- No SLA or uptime number is offered at the design-partner stage. We publish what the pipeline's own monitoring sees rather than promise what operations cannot yet staff.
Security reporting and open questions
Security reports, privacy questions, and unanswered procurement questions all go to one accountable person — the founder, who builds the system: hello@leadsmart.io. Please do not include subscriber, household, or credential data in a first email.
LeadSmart is operated by its founder at the design-partner stage; a formal operating entity, published privacy terms, and DPA material arrive with the first signatures, after the counsel review named above — until then, this page is deliberately the inventory of what is true, not a substitute for those documents. Planned