Find reviewable professional profiles from defined public evidence

{
    "profile_url": "https://example.com/profiles/ava-lane",
    "role": "Synthetic Data Platform Lead",
    "organization": "Example Harbor Labs",
    "observed_at": "2026-09-17T00:00:00Z",
    "evidence_url": "https://example.com/profiles/ava-lane",
    "match_status": "accepted"
}

Who this fits

This is for recruiting operations teams with a defined role brief or builders testing a sourcing workflow from public professional evidence. It fits a process that wants profile URLs, role and organization observations, source dates and an explicit identity review queue before a recruiter acts.

It does not fit a job-board listing feed, a personal contact database, inferred sensitive traits, automated suitability scoring, or a claim that a person consented to a particular use. People sourcing is about public professional evidence tied to a possible identity; job listings describe openings and are a different input and output.

What the pilot proposes

The current public offer is a pilot scoping conversation and illustrative downloads. No managed service or delivery result is being claimed. Select Request access to open a draft addressed to [email protected], then review it with the role, organization or geography, requested source list, required fields, refresh interval, output format, expected volume and acceptance rules. Opening the button sends nothing; a human reviews feasibility, scope, price and acceptance criteria before any work or purchase terms are agreed.

The sample uses example.com and example.org with fictional names and illustrative timestamps. It is a synthetic schema example, not a list of real people, measured output or source verification. One row is held for review because the evidence does not resolve identity; no private email, phone number or sensitive attribute is included.

Try the sample locally

Download /use-cases/people-sourcing/sample.json, save it beside this script as sample.json, and run it with Python. It checks completeness, timestamps and the synthetic example hosts, then routes incomplete identity records to review.

import json
from datetime import datetime
from pathlib import Path
from urllib.parse import urlparse

data = json.loads(Path("sample.json").read_text(encoding="utf8"))
assert data.get("sample_type") == "synthetic"
records = data.get("records", [])
assert records, "sample must contain records"

required = {"profile_url", "role", "organization", "observed_at", "evidence_url", "match_status"}
accepted = []
for record in records:
    issues = [f"missing {field}" for field in required if not record.get(field)]
    try:
        timestamp = datetime.fromisoformat(str(record.get("observed_at", "")).replace("Z", "+00:00"))
        if timestamp.tzinfo is None:
            issues.append("observed_at needs a timezone")
    except ValueError:
        issues.append("observed_at is not an ISO timestamp")
    for key in ("profile_url", "evidence_url"):
        parsed = urlparse(str(record.get(key, "")))
        if parsed.scheme != "https" or parsed.hostname not in {"example.com", "example.org"}:
            issues.append(f"{key} is outside the synthetic example hosts")
    if record.get("match_status") not in {"accepted", "review", "unknown"}:
        issues.append("match_status is invalid")
    if issues or record.get("match_status") != "accepted":
        print("identity review required:", record.get("profile_url", "(missing profile)"), issues)
    else:
        accepted.append(record)

print(f"{len(accepted)} record(s) eligible for recruiter review, {len(records) - len(accepted)} held back")

This validates the local synthetic schema only. It does not establish that a person exists, verify a source page, make a suitability judgment or call a ProxyLane API.

Data requirements and economics

Before delivery, agree the role brief, target organization or geography, permitted public sources, required fields, refresh interval, expected volume, output format, identity review rules, permitted use, deletion and correction process. A concrete pilot output is an evidence file with accepted rows and a separate review queue for unresolved identities or missing fields. Recruiters decide whether and how to contact anyone.

The economic case can stay explicit without a fabricated benchmark: pilot value = (accepted profiles reviewed × value of one reviewed profile) − pilot cost. Supply your own value, review capacity and acceptance threshold; no response, placement or consent result is implied.

Questions buyers usually ask

Is this a job-listing search?

Job listings describe open roles. This proposed vertical records public professional evidence about possible people and preserves the evidence needed for human review.

Will you infer a person’s private details or traits?

The proposed fields exclude private contact data and sensitive traits. Identity ambiguity remains in review, and permitted use must be scoped before a pilot.

Can an accepted row be treated as a hiring recommendation?

accepted means the row met the agreed evidence checks for review. It does not mean suitability scoring, consent, employment status or a hiring decision.

What happens if someone asks for correction or deletion?

Define the correction and deletion route, permitted sources and retention boundary in the pilot worksheet before delivery. Those rules are part of scope, not an unstated promise.

What happens next?

Select Request access to open a reviewable email draft. Include the role brief, permitted source list, required fields, geography, refresh interval, output format, expected volume and acceptance rules.