Dating profile image triage
When new dating profile photos are uploaded, score for visible synthetic-image cues that suggest catfishing or fake-account risk. The decision isn't 'is this AI' — it's 'should this profile be flagged for the verification step.'
Business value
- Increases the conversion of fake-account-removal investigations. Reviewers spend their time on the profiles most likely to be fraudulent.
- Adds a layer to the catfishing defense that the existing photo-verification flow doesn't catch (photo verification confirms a live human; it doesn't catch AI-generated photos of someone the user could plausibly be).
- Triages risk before the profile starts matching, before any real user has spent emotional or financial investment.
Agent job to be done
Be a trust-and-safety triage layer. Allow profiles with low-risk photos. Queue medium-risk profiles for photo-verification prompts (the existing live-selfie flow). Hold high-risk for manual review.
format: social_postintended_use: moderatedomain: dating profile photo trust
Where this fits with photo verification and ID verification
Photo verification (a live selfie that matches a profile photo) catches one threat: 'someone is using photos that aren't of them.' ID verification (government-issued ID + selfie) catches another: 'someone is using fake identity.' Neither catches 'someone is using AI-generated photos of a person they could plausibly be' — which is the failure mode synthetic-image scoring addresses. The three controls work in sequence, not as substitutes.
When to call VeracityAPI
On new profile creation, on photo replacement, and on suspicious-activity escalation from other systems.
What image URL to submit
Public HTTPS image URL for the profile photo. For a profile with multiple photos, score each independently and aggregate.
Decision policy
- allow: low risk on all profile photos.
- revise: at least one photo at medium risk — prompt the user to complete photo verification (the live-selfie flow).
- human_review: high risk on multiple photos OR high risk on the primary photo. Hold the profile from matching until a moderator reviews.
- reject: combined with other fraud signals (new device, mismatched location, payment-fraud history).
Request template
The exact payload shape this use case sends. The sample below uses representative content for this workflow; substitute your own.
curl https://api.veracityapi.com/v1/analyze \
-H "Authorization: Bearer $VERACITY_API_KEY" \
-H "Content-Type: application/json" \
-d '{"type":"image","content":"https://veracityapi.com/demo/influencer-beauty-tonic.jpg","context":{"format":"social_post","intended_use":"moderate","domain":"dating profile photo trust"},"store_content":false}'Automation recipe
- Profile-creation worker receives the photo bundle.
- Each photo scored independently with intended_use=moderate.
- Aggregate signals: number of medium/high-risk photos, primary-photo risk level.
- Allow-tagged profiles flow into the matching pool.
- Risk-flagged profiles route to the existing verification flow or to T&S manual review.
Evidence spans agents should inspect
- 'synthetic_face' — skin smoothness, hair detail, or facial geometry inconsistent with camera photography
- 'background_inconsistency' — bokeh and depth-of-field cues that don't match the foreground subject
- 'attribute_drift' — features that subtly differ across photos in the same profile (jewelry, scars, eye color)
- 'platform_recompression' — image quality cues that don't match the platform's expected capture path
Policy pseudocode
if (result.recommended_action === "allow") continueWorkflow(); if (result.recommended_action === "revise") rewriteWith(result.evidence, result.recommended_fixes); if (result.recommended_action === "human_review") queueForHumanReview(result); if (result.recommended_action === "reject") discardOrRebuild();
KPIs to track
- profiles routed to verification per day
- fraud-account removal rate after gate deployment
- false-positive rate (legitimate users incorrectly routed to verification)
- median time-to-match for clean profiles
- user-report rate on profiles that passed the gate
What can go wrong
- The gate is not face-identity verification. It does not match the photo to a person, and it does not prove the photo is or isn't the user themselves.
- Heavy beauty filters (TikTok-style face-smoothing) can trip 'synthetic_face' on real users. Tune thresholds to account for filter prevalence in your user base.
- Pair with device fingerprinting, payment signals, and behavioral patterns. Photo scoring is one signal in the fraud stack, not the whole stack.
Cost and latency notes
Image analysis is a flat $0.02 per image. The endpoint accepts HTTPS image URLs, stores no image bytes, and logs only a URL hash plus hostname. Current v0.1 latency is vision-model-bound, so preflight balance and retry carefully.
Agent evaluation checklist
- Does this workflow have a costly failure mode from manipulated or synthetic-looking visuals?
- Can the agent store evidence categories without storing raw image bytes or full URLs?
- Should this workflow fail open, fail closed, or queue human review if image scoring is unavailable?
- Which field drives policy: recommended_action, risk_level, content_trust_score, or synthetic_image_risk?
- What local provenance check should complement the API score?