PaperlayerView exact revision on arXiv

Source-linked AI summary

An Interactive Agent for Requirement-Driven Candidate Sourcing

Yuanpeng He, Fangjing Li, Xiangyu Ru, Kexin Sun, Kun Yang, Lijian Li, Chi-Man Pun, Qingsong Wen, Wenpin Jiao, Mingkai Guo, Yirong Feng, Daiheng Gao, Zhi Jin

arXiv:2608.23501v1cs.SE

TL;DR

Vague people-search requests are under-determined requirements, while existing retrieval systems assume a finished query. This paper presents an interactive agent that elicits, validates, retrieves, and verifies requirements. Across the benchmark, it recalls the most relevant real people of any system, at 1.9× the next system.

  • Problem

    Existing retrieval and recruiting systems rank candidates against finished specifications, while vague people-requests lack explicit constraints and acceptance criteria.

    Source: §I · p. 1

  • Method

    DINQ TalentScout treats vague people-requests as requirements, eliciting and validating constraints before retrieving candidates and verifying them with grounded evidence.

    Source: §I · p. 1

  • Results

    Across the benchmark, DINQ TalentScout recalls the most relevant real people of any system, at 1.9× the next system (bootstrap-significant).

    Source: §I · p. 2

  • Takeaways & Limitations

    DINQ TalentScout is a deep sourcing engine, while precision-ranking LLMs serve as complementary verifiers.

    Source: §I · p. 2

    Precision and evidence-support results are approximate because the single LLM judge’s truthfulness judgments are noisy for concise profile candidates.

    Source: §IX · p. 10

Abstract

from arXiv · show

Finding people from a natural-language description (``ML engineers transitioning to research roles in biotech'') is increasingly delegated to LLM agents and framed as information retrieval. We argue that it is fundamentally a requirements engineering task: such a request is an under-determined requirement with implicit constraints, many valid answers, and no acceptance criterion, so useful answers require eliciting, validating, and verifying the requirement before search can matter. We present \sys{}, to our knowledge the first interactive, requirements-driven candidate-sourcing agent (it elicits, validates, retrieves, and verifies a vague people-request into a justified slate through bounded elicitation, workflow templates, a two-stage commit protocol, and bidirectional termination guards) and \bench{}, a benchmark that runs the requirements lifecycle (criteria-anchored validation, multi-model evidence-grounded oracle construction, and cost-aware verification). Across $21$ systems and all $691$ requirements, \sys{} dominates breadth ($100%$ coverage at $2.5\times$ the yield) and is \emph{near-orthogonal} to the field, with $90%$ of the people it returns are surfaced by \emph{none} of $20$ strong LLM-plus-web baselines combined. Beyond breadth, an evidence-grounded judging of every system shows \sys{} \emph{recalls} the most relevant real people: $0.241$ of the union pool, $1.9\times$ the next system, with a bootstrap $95%$ interval disjoint from every baseline. \sys{} is thus the strongest \emph{sourcing} engine (the deepest real, reachable candidate pool), while precision-ranking LLMs serve as~complementary verifiers.

I. INTRODUCTION

The paper reframes vague people-finding as requirements engineering: useful sourcing requires eliciting, validating, and verifying the requirement, not only searching. It introduces an interactive sourcing agent and benchmark, and reports that the agent finds a distinctive, high-recall candidate pool.

Motivation

  • Manual sourcing translates vague requests into Boolean queries and requires skimming hundreds of profiles, while a strong GPT-class web agent returned five people with no overlap among the 46 found by the requirements-driven agent.The paper argues that the web is not missing these people; the system is asking the wrong question.Source: §I · p. 1

Problem formulation

  • A vague people-request is an under-determined requirement with implicit constraints, many valid answers, and no acceptance criterion; prior systems assume a finished query –[3].The paper argues that the bottleneck is eliciting, validating, and verifying the requirement rather than retrieving against it –.Source: §I · p. 1

DINQ TalentScout

  • DINQ TalentScout interactively elicits latent constraints, validates requirement well-formedness and kind, retrieves from a hybrid people-universe, and verifies each person with grounded evidence.Its bounded clarification interview and one design principle address four sources of agent divergence.Source: §I · pp. 1–2

TalentTrace

  • TalentTrace evaluates sourcing agents at scale by performing the requirements lifecycle: validation, evidence-grounded oracle construction, and cost-aware verification.The benchmark addresses the absence of an existing benchmark for this task.Source: §I · pp. 1–2

Empirical findings

  • Across 691 requirements and 21 systems, DINQ TalentScout’s returns were 90% absent from all 20 baselines, and it recalled 0.241 of the union pool, 1.9× the next system (bootstrap-significant).Evidence-grounded judging found it recalled the most relevant real people of any system.Source: §I · p. 2

II. BACKGROUND AND A MOTIVATING EXAMPLE · III. CANDIDATE SOURCING AS REQUIREMENTS ENGINEERING

Open sourcing requests admit many valid answers without a practical enumeration, so useful sourcing requires eliciting and validating requirements and grounding candidate membership in evidence. The sections distinguish failures to identify the right requirement from failures to justify a delivered person.

II. BACKGROUND AND A MOTIVATING EXAMPLE

  • Closed requests define a finite, enumerable answer set with decidable membership; open requests allow many equally valid answers without practical enumeration and have no single gold answer.This distinction changes whether the deliverable is a set or ranked pool, and how the request must be elicited and validated.Source: §II · p. 2, §III · p. 3
  • For this requirement with at least six constraints, DINQ TalentScout returns 46 named, evidence-backed candidates versus 5 from a strong GPT-class web agent, with zero overlap.The example request specifies a role, transition predicate, industry, two regions, and a recency window, while leaving choices such as seniority and slate size implicit.Source: §II · p. 2

III. CANDIDATE SOURCING AS REQUIREMENTS ENGINEERING

  • Following Zave and Jackson, sourcing is a predicate R over people whose deliverable is the ranked extension A(R), with satisfaction requiring both intended-set membership and evidence-grounded acceptance.The lifecycle elicits and validates R, operationalizes it as S and W, then verifies against oracle O under W ∧ S |= R.Source: §III · p. 2
  • Open requirements need elicitation, a derived partial and probabilistic acceptance oracle, evidence-checkable predicates, and validated criteria because no answer key exists.For open requirements, abstaining on under-evidenced candidates is correct oracle behavior; criteria that infer properties from evidence are domain assertions that should be validated before use.Source: §III · p. 2
  • Validation asks whether the right requirement was elicited and operationalized, while verification asks whether delivered people are grounded against the specification.The paper assigns bounded elicitation and criteria-anchored debate to validation, and an evidence-grounded oracle with commit–defer scoring to verification.Source: §III · p. 2
  • The architecture uses bounded clarification, a fixed retrieval workflow across multiple sources, and two-stage evidence-grounded candidate commit with explicit guardrails and termination boundaries.The clarification interview uses at most four questions followed by confirmation; retrieval searches internal, professional, academic, open-source, and company sources in parallel.Source: Figure 1 · p. 3
  • Validation failures return people from the wrong R, while verification failures admit ungrounded candidates; these orthogonal errors explain why query-string search both misses and hallucinates.The paper characterizes the first as recall-oriented and the second as precision-oriented, motivating a requirements-level rather than query-string-level fix.Source: §II · p. 2, §III · p. 3

IV. DINQ TALENTSCOUT: AN INTERACTIVE REQUIREMENT-DRIVEN SOURCING AGENT · A. Problem Formulation · B. Design Principle: Four Divergences, Four Constraints

DINQ TalentScout treats open-ended candidate sourcing as a requirements-engineering task: it elicits and validates a request before retrieving and verifying a bounded, evidence-backed list of real people.

A. Problem Formulation

  • Open-ended sourcing must return a bounded, ranked, evidence-backed list of real people who satisfy a natural-language request.Source: A. Problem Formulation · p. 3
  • Before retrieval, DINQ elicits implicit constraints, validates that the requirement is well-formed and answerable, and verifies each delivered person against it.Source: A. Problem Formulation · p. 3
  • DINQ transforms the initial utterance r into a structured requirement R = (D, K, n), encoding constraint dimensions, requirement kind, and target cardinality.Source: A. Problem Formulation · p. 3
  • The resulting candidate set C contains at most n people, each with a name, organization, role, supporting evidence URLs, and calibrated confidence.Source: A. Problem Formulation · p. 3
  • The engineering objective is a bounded, verifiable, structured candidate set: the loop terminates, every person has checkable evidence, and results are machine-mergeable rows.Source: A. Problem Formulation · p. 3

B. Design Principle: Four Divergences, Four Constraints

C. Eliciting the Requirement (Clarification Contract) · D. Operationalizing the Requirement (Workflow Template) · E. Decoupling Speed and Quality (Two-Stage Commit)

DINQ TalentScout turns an under-specified request into a confirmed requirement through bounded, structured elicitation, then uses a fixed workflow and two-stage candidate submission to balance responsiveness with grounded completeness.

C. Eliciting the Requirement (Clarification Contract)

  • Every user-facing turn follows a language-locked JSON contract with masked tool names and a three-way intent router for specific-person, by-conditions, or other requests.Source: C. Eliciting the Requirement… · p. 4
  • 7 requirement dimensions—domain, compensation, location, role, education, experience, and headcount—are elicited progressively, one per turn, with quick-reply options.Source: C. Eliciting the Requirement… · p. 4
  • At most 4 questions are asked before a confirmation turn, even if dimensions remain unknown; missing headcount defaults to 20, and confirmation is the last correction chance before retrieval.The hard budget frames elicitation as time-boxed information collection, a trade-off also made by human analysts,.Source: C. Eliciting the Requirement… · p. 4

D. Operationalizing the Requirement (Workflow Template)

  • The first postconfirmation turn loads the skill and combines search and submission against an internal index limited to the headcount, surfacing candidates within seconds without a search-inspect-submit round trip.Source: D. Operationalizing the Requirement… · p. 4
  • Subsequent turns plan sources, search broadly in parallel while drafting each person, enrich and verify every draft, commit, and summarize only after the target is met and all drafts are refined.Source: D. Operationalizing the Requirement… · p. 4
  • Evidence chaining passes a tool’s name or URL to the next tool, using a dedicated LinkedIn channel or a reader for other URLs to turn thin snippets into checkable evidence.Source: D. Operationalizing the Requirement… · p. 4

E. Decoupling Speed and Quality (Two-Stage Commit)

  • Each candidate is submitted twice under one stable candidate_id: an immediate snippet-backed draft with confidence 0.4–0.6 creates a fast row, while a refined submission adds mandatory organization, role, links, and recalibrated confidence.The front end merges the submissions by candidate_id, separating sub-second responsiveness from field-complete, grounded quality without double counting.Source: E. Decoupling Speed and Quality… · p. 4
  • Verification labels each candidate verified-match, verified-mismatch, or unverifiable; evidence text records only matched aspects, while doubt is conveyed through lower confidence.Source: E. Decoupling Speed and Quality… · p. 4

F. Bounding Termination (Termination Boundary) · G. Runtime · V. TALENTTRACE: CONSTRUCTING AND EVALUATING SOURCING REQUIREMENTS

The paper bounds termination in both directions, adds runtime safeguards for stable execution, and builds TalentTrace to evaluate sourcing through a requirements-engineering lifecycle.

F. Bounding Termination (Termination Boundary)

  • A full-coverage guard keeps the agent working while candidates remain draft-only, using up to three rounds and a fallback retry for searched-but-unsubmitted candidates.The shipped runtime enforces this through the prompt and skill; the stop-hook intercept is currently inactive.Source: F. Bounding Termination (Termination… · p. 4
  • At ∼50 tool calls with no hits the agent must change strategy; at 80 it narrows, and at 100 it halts and reports honestly.These thresholds bound stopping between premature termination and unbounded search.Source: F. Bounding Termination (Termination… · pp. 4–5
  • CADA gathers independent criteria scores and stances, exits early on unanimous high-confidence agreement, and sends disagreements to an arbitrator focused on contested criteria.The early-exit consensus is confidence-weighted and must meet threshold λ.Source: F. Bounding Termination (Termination… · p. 5

G. Runtime

  • DINQ TalentScout runs the Claude Agent SDK as a subprocess and streams live candidate updates, with session resumption, stuck detection, credential isolation, and bounded tool concurrency.The runtime's full-coverage guard is a cross-layer mechanism enforcing a process property.Source: G. Runtime · p. 5

V. TALENTTRACE: CONSTRUCTING AND EVALUATING SOURCING REQUIREMENTS

  • Because sourcing requests are under-determined, TalentTrace generates diverse requirements, validates their quality and kind, builds an acceptance oracle, and verifies delivered candidates while controlling fabricated evidence.Open requirements need graded candidate pools rather than single-answer keys.Source: §V · p. 5
  • TalentTrace implements this lifecycle with query generation, CADA for requirement admission, CACJ for open-versus-closed classification, a ground-truth pipeline, and CGPS scoring.CADA is used first to assess requirement quality and then, as CACJ, to classify requirement kind.Source: §V · p. 5

A. Generating a Population of Requirements · B. Validating Requirements with Criteria-Anchored Debate · C. Constructing the Acceptance Oracle (Ground Truth)

TalentTrace builds a benchmark by generating open and closed requirements, validating them with criteria-anchored debate, and constructing evidence-backed acceptance pools for open requirements.

A. Generating a Population of Requirements

  • 1,500 generated requirements yielded 1,007 admissions: 691 open and 316 closed.Generation covers open requirements with many valid people and closed requirements with finite enumerable answer sets, rotating across four domain axes and balancing closed task types and difficulty levels.Source: A. Generating a Population of… · p. 5

B. Validating Requirements with Criteria-Anchored Debate

  • One GPT-class judge rated 86.8% of closed requirements perfect (mean 4.54/5), versus a 3.62 average for a Claude-class judge; CADA uses heterogeneous judges and arbitration for disagreements.Three LLMs score binary criteria before taking a stance; a deterministic moderator checks consensus, and only disagreements trigger a fourth arbitrator.Source: B. Validating Requirements with… · p. 5
  • Seven binary quality criteria gate admission, while six boundedness criteria classify admitted requirements as OPEN or CLOSED, with expected answer sets above 20 always OPEN.Five graded dimensions produce a 1–5 quality score, and requirements scoring ≥3.5 are admitted; specificity rubrics penalize opposite failures for open and closed requirements.Source: B. Validating Requirements with… · p. 5, Table I · p. 6
  • The moderator early-exits without arbitration on 95.3% of closed and 97.5% of open requirements, reserving adjudication for contested cases.The confidence-weighted commit–defer design is cheap when voters agree and invokes the more expensive arbitrator only for ambiguity.Source: B. Validating Requirements with… · p. 5

C. Constructing the Acceptance Oracle (Ground Truth)

  • For each open requirement, three search models build a source-linked candidate pool that a cross-family judge fact-checks before evidence-based synthesis.Each search model can run up to ten rounds of neural search and page fetching; synthesis ranks consensus by cross-model support, evidence quality, and host diversity, and leaves the oracle null when candidates lack agreement or grounding.Source: C. Constructing the Acceptance Oracle… · p. 6
  • The oracle covers 203 requirements with a mean pool of 44.6 people (range 6–67), mean synthesis reliability 0.60, and total construction cost $347.77.All three generator models covered the evaluation set; raw three-way name overlap was only ≈0.02 Jaccard, so consensus depended on corroborated evidence rather than identical wording.Source: C. Constructing the Acceptance Oracle… · p. 6

D. Verifying Satisfaction (CGPS)

CGPS verifies satisfaction with a cost-aware commit–defer process and measures sourcing depth over a method-neutral pool of relevant real people. It separates recall and reachable yield from precision-oriented relevance and evidence-support rates.

D. Verifying Satisfaction (CGPS)

  • CGPS reuses CADA to fix query-level requirements, commits candidate relevance from structured fields, and defers costly evidence fact-checking to a calibration subset.The relevance gate uses name, organization, and title rather than evidence thickness, avoiding a penalty for concise profiles.Source: D. Verifying Satisfaction (CGPS) · p. 6
  • CGPS measures each system’s recall over the union of systems’ relevant real-person returns, using a deterministic, label-only metric rather than a per-candidate composite.It reports 500-resample bootstrap 95% confidence intervals, resampling queries.Source: D. Verifying Satisfaction (CGPS) · p. 6
  • CGPS reports recall and reachable yield for sourcing depth, alongside per-candidate relevance and evidence-support rates for precision, with bootstrap 95% confidence intervals.The structured verdict also assigns a primary issue bucket: OFF-TOPIC, THIN-SOURCES, BROKEN-URL, LIKELY-HALLUCINATION, or NONE.Source: D. Verifying Satisfaction (CGPS) · p. 6

VI. EXPERIMENTAL SETUP … B. RQ2: Robust Across Difficulty, Type, and Language

DINQ TalentScout pairs complete coverage and the highest candidate yield with breadth that holds across difficulty, task type, and language. The evaluation tests breadth and grounded candidate quality separately on open requirements, without empirically testing interactive elicitation.

VI. EXPERIMENTAL SETUP

  • The benchmark evaluates 691 open requirements spanning ten difficulty levels, sixteen sourcing task-types, and seven languages; 316 closed requirements validate the open/closed boundary only.The open requirements come from 1,500 generated requirements, of which 1,007 were admitted as well formed.Source: §VI · pp. 6–7
  • Grounded quality is scored on 203 unique open requirements using evidence-backed oracles with a mean pool of 44.6 people and mean reliability of 0.60.The CGPS judge grades every candidate from all 21 systems against the oracle, with bootstrap 95% confidence intervals.Source: §VI · p. 7
  • The 21 configurations span product pipelines, autonomous-web LLMs, Exa-augmented LLMs, and bare LLMs; a retrieval-backbone source ablation compares internal, web, and mixed modes on 100 requirements.The benchmark reports coverage and yield for breadth, normalized-name overlap for complementarity, and recall, reachable yield, relevance, and evidence-support rates for grounded quality.Source: §VI · p. 7
  • The benchmark gives each requirement directly, testing retrieval, verification, and delivery but not interactive elicitation, for which the paper makes no empirical claim.The authors identify a controlled user study as future work.Source: §VI · p. 7

A. RQ1: Coverage and Yield at Scale

  • 100% coverage and 49.9 candidates/req. make DINQ TalentScout the only system pairing complete coverage with the highest yield across 691 open requirements.It unions a proprietary people index with neural web search; an autonomous GPT-class LLM also reaches 100% coverage but returns 19.8 candidates/req.Source: A. RQ1: Coverage and Yield at Scale · p. 7

B. RQ2: Robust Across Difficulty, Type, and Language

  • 100% coverage and ∼46–57 candidates hold across all ten difficulty levels, sixteen task-types, and seven languages for DINQ TalentScout.Baselines degrade on hard and non-English requirements; for example, the Grok-class model reaches 28% on cross-verify, 14% on temporal, 0% on niche, and 38% on Chinese. The workflow template and full-coverage guard make the agent exhaust requirements rather than stop at easy hits.Source: Figure 3 · p. 7, B. RQ2: Robust Across Difficulty,… · p. 7

A. RQ1: Coverage and Yield at Scale

  • 90.0% (30,963) of DINQ TalentScout’s 34.4k requirement-person mentions appear in none of 20 pooled baselines, whose union is 2.5× larger.Mean Jaccard overlap with each baseline is approximately 0.01.Source: Figure 3 · p. 7

C. RQ3: DINQ TalentScout Surfaces People the Whole Field Misses · D. RQ4: DINQ TalentScout Recalls the Most Relevant Real People

DINQ TalentScout surfaces a largely distinct candidate pool and recalls more relevant real people than the evaluated systems. Professional headhunters also preferred its deeper slates.

C. RQ3: DINQ TalentScout Surfaces People the Whole Field Misses

  • Across over 691 requirements, 90.0% (30,963) of DINQ TalentScout’s returned mentions (approximately 34k total) appeared in none of the 20 baselines combined, whose pooled union contained 85,174 mentions.Source: C. RQ3: DINQ TalentScout Surfaces… · p. 8
  • Mean pairwise Jaccard was 0.010, and a strict name-order- and diacritic-robust re-match changed the unique fraction only from 90.0% to 89.7%.Pooling all 20 baselines, 6.24× the best single system, still missed DINQ TalentScout’s additions; normalized-string overlap measures coverage, not correctness.Source: C. RQ3: DINQ TalentScout Surfaces… · p. 8
  • Mix retrieval beat a web-only Exa backbone in every category by +5.2 to +11.3 unique people per requirement.Web-only baselines relied essentially entirely on LinkedIn evidence, while DINQ TalentScout also grounded candidates in Scholar, GitHub, and Hugging Face profiles.Source: C. RQ3: DINQ TalentScout Surfaces… · p. 8

D. RQ4: DINQ TalentScout Recalls the Most Relevant Real People

  • The CGPS judge graded candidates from all 21 configurations across 691 requirements, counting a candidate relevant when it was not marked off-topic.Judging used name, organization, and title, and recall was measured over a method-neutral union pool with reachable yield and bootstrap confidence intervals.Source: D. RQ4: DINQ TalentScout Recalls the… · p. 8
  • 0.241 recall of relevant real people from the 93,444-person union pool exceeded the next system’s 0.126, with disjoint bootstrap 95% confidence intervals.DINQ TalentScout also surfaced 14,267 reachable relevant candidates and 32.8 relevant people per requirement, compared with 11,795 and 17.1 for the next system.Source: Table II · p. 8, D. RQ4: DINQ TalentScout Recalls the… · p. 8
  • DINQ TalentScout won head-to-head on 68% of requirements versus 14% for the next system, and its per-requirement depth stayed essentially flat across simple and constraint-heavy strata.It ranked first on every sourcing-depth board and on F1, F2, and F3 composite quality scores.Source: D. RQ4: DINQ TalentScout Recalls the… · p. 8, Table II · p. 8
  • DINQ TalentScout provides the widest real, reachable candidate pool, while precision-ranking LLMs return fewer but accurate candidates as complementary verifiers.The reported evidence frames the systems as serving complementary roles in deep sourcing.Source: D. RQ4: DINQ TalentScout Recalls the… · p. 8
  • 25 of 30 professional headhunters ranked DINQ TalentScout first for slate quality, ahead of GPT-5.5 and GLM-5.2.GLM-5.2 ranked third with headhunters despite 0.062–0.073 recall versus DINQ TalentScout’s 0.241, illustrating how a small focused set can read well to raters but score lower on recall.Source: D. RQ4: DINQ TalentScout Recalls the… · p. 8

E. RQ5: Efficiency and Cost

Efficiency comes from spending computation only on hard decisions: parallel, short-circuiting retrieval accelerates grounded results, while the commit–defer cascade avoids most arbitration. Oracle construction is a one-time cost, and source ablations show the value of mixed retrieval.

E. RQ5: Efficiency and Cost

  • 0.92 s to first result makes the hybrid backbone the fastest grounded option, 38% faster than web-only, by parallelizing sources and short-circuiting; the cascade skips arbitration on 95.3–97.5% of decisions.A no-early-exit control gives identical verdicts at ∼20× the cost.Source: E. RQ5: Efficiency and Cost · p. 8
  • $347.77 over 203 requirements ($1.71 each) is the one-time cost of oracle construction.Source: E. RQ5: Efficiency and Cost · p. 8
  • Web-only retrieval loses 7.6 people per requirement and internal-only retrieval drops to 56% coverage in the 100-requirement ablation.The internal index also supplies fact-checkable evidence; isolating the two-stage commit, kickoff recipe, and full-coverage guard is future work.Source: E. RQ5: Efficiency and Cost · p. 8

F. RQ6: Does Clarification Recover Latent Requirements? · VIII. DISCUSSION AND IMPLICATIONS FOR RE

A bounded clarification interview recovers substantially more latent requirements than single-shot reading, while the discussion frames requirements discipline as a way to make agent outputs traceable, bounded, and verifiable. It also casts broad-recall sourcing and precision-based verification as complementary roles.

F. RQ6: Does Clarification Recover Latent Requirements?

  • Recovery improved on every constraint dimension, most on geography (0%→75%), organization type (4%→48%), and recency (9%→65%).The largest gains concern implicit where, what-kind, and when constraints that vague requests often omit, evidence of interview competence [18].Source: F. RQ6: Does Clarification Recover… · p. 9, Figure 5 · p. 9
  • 67.5% of hidden latent constraints were recovered by bounded clarification versus 13.8% by single-shot reading (4.9×; 33/40 requirements improved).In a controlled test on 40 requirements, half of each requirement’s mean 6.2 atomic constraints were hidden; three distinct models handled clarification, oracle responses, and constraint judging. Overall constraint capture rose from 0.29 to 0.41 (+0.12, CI [+0.03, +0.20]).Source: F. RQ6: Does Clarification Recover… · p. 9

VIII. DISCUSSION AND IMPLICATIONS FOR RE

  • Acceptance criteria function as requirements-traceability instruments by distinguishing retrieval failures from candidates surfaced but not justified, so criteria themselves require validation.TalentTrace uses auditable rubrics and deterministic scoring; the discussion argues that LLM-as-judge evaluation should validate the evaluator, not merely apply it.Source: §VIII · pp. 9–10
  • DINQ TalentScout leads recall by 1.9×; it returns the most relevant people on 68% of 691 requirements, versus 14% for the next system.The discussion frames recall as the sourcing obligation and precision-ranking LLMs as complementary verifiers that prune candidates after sourcing.Source: §VIII · p. 10
  • The clarification contract’s 4.9× latent-constraint recovery uses no index, separating that requirements contribution from the system’s sourcing-depth advantage.TalentTrace scores systems under one methodology, and the sourcing-versus-verifier framing is conceptual; the discussion claims an index-independent requirements contribution, not that the index is the contribution.Source: §VIII · p. 10
  • TalentTrace limits judge circularity by using structured-field relevance, a method-neutral union pool, and one rubric across all 21 systems.A 500-resample bootstrap gives DINQ TalentScout an interval disjoint from every baseline; remaining judge noise, especially hallucination calls on concise candidates, affects precision estimates rather than its recall lead.Source: §VIII · p. 10
  • DINQ TalentScout applies four symmetric requirements constraints to agent risks: clarification, workflow templates, two-stage commit, and bidirectional termination guards.The discussion presents this symmetry as a way to make an open-ended agent bounded, verifiable, and reproducible.Source: §VIII · p. 10
  • The four-constraint principle and generate→validate→oracle→verify harness can transfer beyond people-search to literature and dataset discovery, vendor selection, and compliance evidence.Candidate sourcing is described as a demanding case because it involves open-set oracles and adversarial evidence such as profiles, paywalls, and stale pages.Source: §VIII · p. 10

IX. THREATS TO VALIDITY · X. RELATED WORK · XI. CONCLUSION

The paper frames open-ended candidate sourcing as requirements engineering: useful systems must elicit and validate an under-determined request before retrieving and verifying people. DINQ TalentScout and TalentTrace address that lifecycle, while the paper qualifies its evaluation scope and positions its contributions against query-given retrieval and related requirements-engineering work.

IX. THREATS TO VALIDITY

  • Evaluation covers web-accessible people and open requirements, with English- and profile-site-skewed evidence, model-constructed oracles, noisy precision judgments, and no live human-interview UX study.The authors treat the recall lead as robust, precision and evidence results as approximate, and bare no-retrieval coverage values as lower bounds; conclusions may not transfer to closed enterprise corpora or under-documented populations.Source: §IX · p. 10

X. RELATED WORK

  • People-search systems and benchmarks generally treat requests as finished queries, whereas DINQ TalentScout interactively authors and refines a vague people-requirement, then verifies delivered people against it.The related-work discussion contrasts this with expertise retrieval, reviewer matching,,, LLM recruiting tools [3], and fixed-query benchmarks [23], [24].Source: §X · p. 11
  • Prior LLM interviewers for requirements elicit needs but stop at producing a requirement; DINQ TalentScout closes the loop by validating sourcing requirements and verifying people against an evidence oracle.The oracle operationalizes IEEE 830 / ISO·IEC·IEEE 29148 quality attributes, as criteria for retrieval-grounded, set-valued deliverables.Source: §X · p. 11
  • The paper connects the test-oracle problem to people-finding and makes evaluator validation a benchmark obligation, using a derived, partial, probabilistic oracle for open requirements.It applies Boehm’s V&V to the oracle itself via the adequacy obligation,, and treats acceptance criteria as analogous to a user story’s,.Source: §X · p. 11
  • Browsing and deep-research benchmarks assume fully specified queries with one verifiable answer, while research on clarifying under-specified needs is not tied to the requirements lifecycle.The paper adapts heterogeneous multi-agent debate into a deterministic, early-exiting validator to mitigate LLM-judge bias within a guarded reason–act loop,.Source: §X · p. 11

XI. CONCLUSION

  • Across 21 systems and all 691 requirements, the paper argues that open-ended candidate sourcing is fundamentally a requirements-engineering problem, not merely retrieval.DINQ TalentScout converges an LLM’s divergence on four axes, and TalentTrace runs the requirements lifecycle.Source: §XI · p. 11
  • 1.9× the next system, DINQ TalentScout recalls the most relevant real people, making it a deep sourcing engine alongside precision-ranking LLMs as complementary verifiers.The conclusion describes this difference as bootstrap-significant.Source: §XI · p. 11
  • The studied system is proprietary, so its source code and data cannot be publicly released, although the paper specifies algorithms and settings needed for re-implementation.The paper points to §IV–§V and Alg. 1–2 for those details.Source: §XI · p. 11
Loading 2608.23501v1…