Sumitr Mardy

I build data-verification actors for people who run them inside automated pipelines — where the caller is a machine, and one unexpected null breaks everything downstream.

What I optimise for

• Schema stability. Every field present, every time. status is always one of four values, never null. No defensive null-checking in your code.
• Measured accuracy, not claimed accuracy. Every actor ships against a labelled test set, and I publish the numbers — including the rows that fail and why.
• Honest limits. Gmail mailboxes cannot be verified over SMTP. Neither can catch-all domains. Anyone claiming otherwise is guessing. I state the limit in the docs and return a verdict that says so.

Actors

Email Verification API — Bulk SMTP, MX & Catch-All Check Four layers: RFC 5322 syntax → MX with A-record fallback → disposable / role / free-provider lists → live SMTP handshake with a mandatory catch-all probe. Reply codes only; it never sends a message.

Scores 100% against a 166-address labelled set covering every branch of the decision tree — valid mailboxes, hard bounces, catch-all domains, role accounts, DNS failures and the controls that prove those groups still mean something. Unknown rate measured at 1.8% on the platform.

Open to work on data verification, enrichment pipelines and scraping infrastructure.