Why a candidate pool is needed
Without a candidate pool, AI matches that fail automatic notification rules can simply disappear. That is clean, but it may lose high-score leads that need review or later data.
The candidate pool handles the middle state: not clearly successful, not clearly irrelevant. It saves the reason so the system can use it later.
| Situation | Why email should not be automatic |
|---|---|
| High AI score but different broad category | Could be upstream/downstream fit, or could be a false positive |
| Same keyword but different use case | Leather care products and leather goods manufacturing are not the same demand |
| Buyer fields missing | Supplier may fit, but certification, quantity, or market are unclear |
| Supplier profile too broad | The system cannot confirm the supplier serves the specific request |
Candidate pool versus automatic email
Automatic email means the system believes the pair has met notification conditions. Candidate pool means the pair is a possibility, not something that should interrupt both sides.
A candidate record should keep demand, supply, score, conflict reason, and review status. If rejected, it should not become a successful match or send duplicate mail; the original intents can still match future counterparts.
| Feature | Notifies both sides? | Purpose |
|---|---|---|
| Automatic successful match | Yes, after duplicate checks | Help both sides start contact |
| Candidate pool | No direct notification | Save high-score but uncertain leads |
| Human review alert | Internal/admin only | Decide whether to release or reject |
| Unmatched email capture | No supplier notification | Let a user wait for future matches |
How human review should work
Human review does not negotiate for the parties. It decides whether the candidate can move to notification or should stay as a rejected/held record.
A rejected candidate should keep a reason such as use-case mismatch, capability gap, missing certification, MOQ mismatch, or more information needed.
- Check whether the product use case matches, not just keywords.
- Check whether supplier capability covers the buyer's key fields.
- Check whether this pair has already been emailed.
- When not suitable, keep the reason for future matching.
- Only released candidates can enter duplicate-safe email notification.
Why duplicate email protection matters
B2B matching should not repeatedly send the same lead. Duplicate protection should consider match pair, emails, demand ID, supply ID, and send status.
Candidate re-review, score recalculation, or text re-parsing should not bypass duplicate checks. Only a new valid match relation or explicit release should enter notification.
| Deduplication signal | Role |
|---|---|
| demand_id + supply_id | Avoid resending the same intent pair |
| buyer_email + supplier_email + category | Avoid repeatedly disturbing the same parties |
| match_pair_id | Track generated match records |
| sent_at / skipped_reason | Know whether mail was sent or skipped |
| candidate_review_status | Prevent unreleased candidates from becoming successful matches |
FAQ
Does the candidate pool automatically email buyers and suppliers?
No. It stores high-score but uncertain leads. Only released candidates that pass duplicate checks can notify both sides.
Should rejected candidates be deleted?
Usually no. Keeping the reason helps future matching when new demand or supply appears.
Is unmatched email capture the same as candidate pool?
No. Email capture is a user waiting for future results; candidate pool is a high-score but uncertain demand/supply pair found by the system.