How ReacherX decides whether someone fits

The core works with structured criteria rather than a vague request to find a good lead. Each criterion can be required, preferred, or an exclusion. The evaluation returns verdicts, confidence, a rationale, and source references.

A required criterion such as “has discussed this problem” needs different evidence from “works as a designer”. A job title cannot prove the first one.

Keep judgment separate from arithmetic

The model interprets evidence. convex/lib/qualificationScoringCore.ts reconciles the results and calculates the score in ordinary TypeScript.

The score has four components:

Those numbers are not a probability that someone will buy or respond. They are a ranking built from the workspace's criteria and supported evidence.

The final condition is explicit:

A high total cannot cancel a hard failure. A required criterion must be matched. A sufficiently confident matched exclusion blocks qualification. Likely-bot detection and having no verified evidence can also block it.

Missing evidence stays missing

reconcileQualificationCriterionResults fills absent criterion results with unknown. For non-exclusion criteria that require activity evidence, a matched or partial verdict without source IDs is downgraded to unknown.

That rule is important when an AI response sounds confident but doesn't point to a source. Raising the score threshold would not solve the underlying problem. The evidence needs to be checked before scoring.

The evidence-related helpers and tests sit beside the scoring code. Follow convex/lib/qualificationEvidenceCore.ts when investigating source handling, and convex/lib/qualificationDiscoveryEvidenceCore.ts when the original search result should contribute evidence.

Save a result only if the work is still current

The workflow uses a stored workflow ID and state checks to avoid treating stale or duplicate work as a fresh result. It records qualification activity and a memory event, then starts enrichment for eligible qualified results.

A provider failure is different from a valid decision that someone doesn't fit. The recovery code and failure metadata preserve that distinction. Don't “fix” an outage by marking every affected person disqualified.

For a contribution, capture the criterion, evidence, expected verdict, and actual verdict. Read convex/lib/qualificationScoringCore.test.ts, convex/qualificationDiscoveryEvidence.integration.test.ts, and convex/qualificationFailureRecovery.integration.test.ts for the relevant boundaries.

The next article follows a qualified person into enrichment, where the system builds a fuller profile for the user and later planning.