Find, Attempt, and Recommend (FAR)

Updated 20 August 2026

Find, Attempt, and Recommend (FAR) is a workflow framework that discovers candidates, evaluates them through execution or reasoning, and selects outputs for reuse, deployment, or expert review across fields such as mathematics, software, robotics, and automated research.
FAR systems improve resource allocation by combining candidate discovery with feedback-driven attempts and persistent selection, including examples such as 4,717 attempted mathematical problems narrowed to 77 recommended artifacts and repository-generation gains of up to 22.94 percentage points.
FAR requires stage-specific evaluation and safeguards because retrieval gaps, weak feedback, critic errors, selection bias, unverifiable claims, and safety failures can make polished recommendations unreliable without provenance, formal verification, and human oversight.

Find, Attempt, and Recommend (FAR) is a staged framework for allocating computational and human effort across discovery, execution, evaluation, and selection. In its most explicit formulation, FAR is a literature-to-review cascade for mathematical discovery: it finds source-grounded open problems, attempts their resolution with increasingly capable reasoning systems, and recommends a small set of potentially valuable artifacts for expert review (Zheng et al., 17 Aug 2026). The same three-stage structure also describes broader systems for code generation, robotics, software engineering, digital libraries, financial recommendations, and automated research. FAR should therefore be understood as a workflow abstraction rather than a single algorithm. The acronym is additionally used for unrelated methods, including Factored Action space Representations in deep reinforcement learning (Sharma et al., 2017) and Failure-Aware Retry in robotic manipulation (Hao et al., 1 Jul 2026).

1. Conceptual scope and terminology

The FAR decomposition separates three functions that are frequently conflated in automated problem-solving systems.

Find identifies candidate tasks, hypotheses, resources, actions, or artifacts. Depending on the domain, it may involve literature mining, retrieval, clustering, graph search, repository matching, failure attribution, or candidate generation. A key distinction is whether the system searches an externally specified problem space or merely generates alternative responses within a fixed task.

Attempt executes or analyzes a candidate. An attempt may consist of mathematical reasoning, repository generation and testing, robot execution, code analysis, library browsing, or financial-behavior inference. The defining feature is interaction with an evaluation signal: a proof audit, test result, runtime outcome, task-success signal, future transaction, or other evidence.

Recommend selects, ranks, preserves, or forwards outputs for subsequent use. Recommendation may be explicit, as in ranking candidate mathematical artifacts by estimated success and importance, or implicit, as in preserving the historical-best repository or selecting higher-value robot actions. A system that only generates candidates or retries after failure does not necessarily contain a complete Recommend stage.

FAR is not synonymous with iterative generation. A retry loop can lack persistent state, candidate comparison, verification, or selection. Conversely, a recommender can implement Find and Recommend without performing an operational Attempt. FeaRS, for example, mines implementation patterns and recommends complete Android methods but does not compile, execute, or validate the retrieved code (Wen et al., 2021). The multi-attempt reinforcement-learning framework for LLMs trains refinement after incorrect answers, but does not implement an explicit post-hoc selector over candidate answers (Chung et al., 4 Mar 2025).

The acronym has several field-specific meanings. “Factored Action space Representations” decomposes compositional discrete action spaces in deep reinforcement learning (Sharma et al., 2017). “Failure-Aware Retry” denotes a robotic test-time recovery method (Hao et al., 1 Jul 2026). “Fully Automated Research System” refers to an autonomous research-production system (Tang et al., 30 Jun 2026). These usages should not be treated as expansions of Find, Attempt, and Recommend.

2. Find: discovery, retrieval, and candidate formation

The Find stage determines the population on which expensive reasoning, execution, or review will operate. Its design controls recall, computational cost, diversity, and exposure to irrelevant or already-resolved candidates.

Literature and problem discovery

The most developed FAR Find pipeline appears in the mathematical-discovery system. It begins with a human-specified research direction rather than a single conjecture. In a combinatorics pilot, the system processed 51,110 mathematics papers, retained 5,245 papers classified as relevant, extracted 6,453 candidate conjectures or open problems, and retained 4,717 apparently well-posed and still-open statements (Zheng et al., 17 Aug 2026).

The pipeline consists of:

Label: classify papers with respect to the research direction.
Extract: recover explicit conjectures, questions, and open problems.
Check: assess well-posedness, current openness, difficulty, and importance.

The Check stage uses web search and source evidence. Its statuses are open, solved, and invalid. The resulting pool remains uncertain because openness depends on available literature and search coverage. The pipeline incorrectly retained an Erdős–Straus-related result as new even though a recent resolution had been posted elsewhere, demonstrating that source-grounded extraction does not guarantee novelty detection (Zheng et al., 17 Aug 2026).

The same principle appears in FARS, where ideation agents search open-access papers and public code repositories, construct a three-tier knowledge base, identify research gaps, and generate proposals. FARS began from nine broad AI research directions and produced 166 papers across 67 fine-grained topics, including emergent areas outside the initial seeds (Tang et al., 30 Jun 2026). Its Find stage is broader than keyword search but does not provide a formal novelty metric, diversity objective, or topic-coverage score.

Retrieval and clustering

In code generation, FeaRS finds implementation patterns by mining 20,713 open-source Android repositories, 2,721,800 commits, and 2,018,479 added-method nodes. Methods are represented in a similarity graph using a customized ASIA Android clone detector, clustered, and normalized into association rules such as

$\{LHS\}\implies RHS.$

When a developer completes methods matching the antecedent clusters, FeaRS retrieves the centroid of the consequent cluster and returns its complete signature and body (Wen et al., 2021). Its Find stage therefore combines offline repository mining with online nearest-centroid matching.

A hypergraph-based digital-library recommender provides another Find mechanism. It represents resources as vertices and association rules over session-level access patterns as hyperedges. hMETIS partitions the resulting resource hypergraph into 17 clusters, enabling recommendations based on collective browsing behavior rather than title similarity (Roy et al., 2023). The method uses EZproxy logs, successful requests, user identifiers, sessions, resource URLs, titles, and association rules with minimum support of 1% and confidence of 80%.

LiveCoder’s Find stage retrieves task-specific success and failure knowledge from previous repository-generation attempts. Stored entries are embedded, ranked by cosine similarity, and injected into subsequent prompts. The persistent state includes Success Knowledge, Failure Knowledge, and a historical-best repository (Pan et al., 4 Apr 2026).

Candidate actions and alternatives

In robotic Failure-Aware Retry, Find operates locally after a failed execution. The system identifies suspicious action chunks using critic-estimated value changes,

$\Delta V_t=V_\psi(s_{t+H})-V_\psi(s_t),$

and selects low-percentile chunks as likely failure-inducing behavior. It then samples candidate action chunks from the current policy, filters them by moderate $L^2$ distance from the failed chunk, and ranks them with an action-value function (Hao et al., 1 Jul 2026).

This illustrates that Find need not discover complete tasks. It may identify the local cause of failure and plausible alternatives within a constrained action neighborhood.

3. Attempt: execution, reasoning, and feedback

The Attempt stage converts candidates into evidence. Its central methodological requirement is that candidate quality be assessed through a feedback mechanism rather than inferred solely from generation confidence.

Mathematical attempts

In the combinatorics pilot, each of 4,717 apparently open problems received one attempt from a reasoning model. The system supplied the source paper, extracted statement, and local context, and instructed the model to reconstruct the formal problem, test edge cases, search for counterexamples, and provide a rigorous argument. Attempts were labeled [KNOWN](https://www.emergentmind.com/topics/knowledge-overflowed-weights-nowcaster-known), NEW, FIX, or NONE; 1,050 were claimed as new resolutions, 598 passed three independent automated judges, and 77 were graded as potentially publishable (Zheng et al., 17 Aug 2026).

These labels are not proof certificates. The system used natural-language reasoning, literature searches, and independent model judges rather than Lean, Coq, Isabelle, or another proof assistant. Human review of 15 of the 77 recommendations found all 15 mathematically correct, but the sample was selected by author interest and is not an unbiased estimate of the full recommendation set.

Repository generation and validation

LiveCoder defines an attempt as a complete end-to-end repository solution. An attempt may include internal cycles of generation, execution, inspection of tests or runtime errors, repair, and re-evaluation. A functional score determines whether the candidate becomes the historical best and whether its success or failure is converted into persistent knowledge (Pan et al., 4 Apr 2026).

FARS uses a more structured Attempt stage. Its Planning Agent converts accepted proposals into machine-readable experiment contracts containing ordered experiment items and executable steps. The Experiment Agent produces execution plans, submits them to an independent Review Agent, runs approved code, performs semantic and deterministic verification, and records outputs in a shared workspace. An effectiveness gate determines whether the system proceeds from main experiments to analysis experiments (Tang et al., 30 Jun 2026).

The distinction between execution and documentation is important. FARS preserves code, logs, raw outputs, plotting scripts, evidence plans, and manuscripts, allowing claims to be inspected against artifacts. Nevertheless, its deployment produced recurring narrow-scope, methodological, and integrity failures. Experimental weaknesses appeared in 92.9% of structured reviews, and formal integrity violations affected 39 of 140 reviewed papers (Tang et al., 30 Jun 2026).

Multi-attempt language-model reasoning

The multi-attempt reinforcement-learning framework trains a LLM to answer questions over several attempts. After an incorrect response, the environment provides binary correctness feedback and the number of remaining attempts. The model conditions later responses on the full dialogue history. With a maximum of five attempts during training, multi-attempt training improved evaluation performance from 45.6% with one attempt to 52.5% with two attempts, whereas a single-turn-trained baseline improved only from 42.3% to 43.2% (Chung et al., 4 Mar 2025).

This result distinguishes learned retry behavior from simply allowing repeated sampling at test time. The model is trained to use failed attempts as context and to modify subsequent responses. However, the feedback is not diagnostic: it indicates that the answer is wrong but does not provide a critique, explanation, or correction.

Robotic execution and recovery

Failure-Aware Retry performs physical or simulated attempts with a diffusion policy that predicts action chunks. After failure, the robot arm returns to a predefined start configuration while the object and scene are preserved. Failure-Contrastive Preference Adaptation constructs preference pairs between failed action chunks and critic-ranked alternatives, updates the policy for a small number of gradient steps, and retries with lightweight action perturbations (Hao et al., 1 Jul 2026).

The system can additionally store successful recovery trajectories and use them for continual policy improvement. Failures train the critic and inform adaptation, while successful expert and recovery trajectories receive advantage-weighted actor updates. The method assumes that the failure is recoverable, the scene remains manipulable, and the critic can provide useful value estimates.

Recommendation determines which candidate or trajectory should be reused, forwarded, preserved, or subjected to expert attention. It may operate through explicit scores, thresholds, preference learning, or best-so-far preservation.

Mathematical triage

The mathematical FAR pipeline uses judging and grading as a cascade. Three independent judges evaluate each NEW claim. Only claims passed by every judge proceed to grading. The grader then distinguishes known results, minor new results, standard-journal artifacts, and stronger results. Of 1,050 claimed resolutions, 598 passed judging, 75 were graded known, 446 were too minor, and 77 were retained as publishable artifacts (Zheng et al., 17 Aug 2026).

The paper also formulates candidate allocation under a budget $B$ . If $p(c)$ is the probability that conjecture $c$ produces an accepted artifact and $i(c)$ is its estimated importance, ranking by $p(c)$ targets the number of artifacts, while ranking by $i(c)p(c)$ targets total importance. For the maximum-importance objective, the expected objective is monotone submodular, motivating greedy selection.

Empirically, difficulty predicted the absence of an accepted resolution with ROC AUC 0.69, while importance predicted publishability among accepted resolutions with ROC AUC 0.60. Difficulty and importance were strongly correlated, with Spearman correlation 0.83. These results support calibrated triage but also show that difficulty and importance cannot be treated as independent ranking dimensions.

Best-so-far preservation

LiveCoder implements Recommendation through a strict historical-best rule. If $R_t$ has functional score $\Delta V_t=V_\psi(s_{t+H})-V_\psi(s_t),$ 0 and the current best has score $\Delta V_t=V_\psi(s_{t+H})-V_\psi(s_t),$ 1, replacement occurs only when

$\Delta V_t=V_\psi(s_{t+H})-V_\psi(s_t),$ 2

Consequently,

$\Delta V_t=V_\psi(s_{t+H})-V_\psi(s_t),$ 3

The historical best prevents regression, while Success Knowledge and Failure Knowledge guide future attempts. On RAL-Bench, the framework improved functional scores across four attempts by as much as 22.94 percentage points, increased repository reuse to 81.58%, and reduced cost by as much as 53.63% (Pan et al., 4 Apr 2026).

This is a recommendation mechanism even though it does not produce a conventional ranked list. It recommends the best complete repository found so far and guides future generation toward previously successful or away from previously failed structures.

Preference-based recommendation

In robotic recovery, the critic ranks candidate actions and constructs preferences

$\Delta V_t=V_\psi(s_{t+H})-V_\psi(s_t),$ 4

where $\Delta V_t=V_\psi(s_{t+H})-V_\psi(s_t),$ 5 is a failure-inducing chunk and $\Delta V_t=V_\psi(s_{t+H})-V_\psi(s_t),$ 6 is a higher-value alternative. The policy is updated with a pairwise preference objective based on diffusion denoising loss. Recommendation therefore operates at two timescales: immediate action selection during retry and policy-level adaptation for future attempts (Hao et al., 1 Jul 2026).

Human-oriented recommendation

FARS recommends indirectly by accepting, revising, or rejecting proposals; gating whether analysis continues; and selecting the best available draft after repeated failures. It does not formally rank projects by expected scientific value, feasibility-adjusted novelty, information gain, cost-effectiveness, or downstream impact (Tang et al., 30 Jun 2026).

The mathematical FAR system is more explicit in targeting human review. It reduces 4,717 attempted problems to 77 recommended artifacts and then to 15 manually reviewed items. However, the final human sample is interest-selected, so the pipeline demonstrates capability and workload reduction rather than unbiased recommendation precision (Zheng et al., 17 Aug 2026).

5. Applications across research and engineering

FAR-like workflows have been instantiated across domains with substantially different candidate spaces and feedback signals.

Domain	Find	Attempt	Recommend
Mathematical discovery	Literature, conjecture extraction, openness checks	Proofs, counterexamples, status searches	Judge, novelty grade, expert-review selection
Repository code generation	Prior repositories, success/failure memories	Generate, execute, repair repositories	Historical-best preservation and prompt guidance
Robotics	Failure-inducing action chunks and alternatives	Non-reset retries with perturbations	Critic-ranked preferences and policy updates
Software logging	Existing log locations and program-graph context	Mask log call and infer contextual severity	Six-level recommendation
Android development	Co-implemented method clusters	Retrospective next-method simulation	Complete method retrieval
Digital libraries	Title clusters and session hypergraphs	Browsing and successful resource access	Cluster-based resource recommendation
Financial assets	Transaction and market knowledge graphs	Infer future purchase and return behavior	Three-asset recommendation
Automated research	Topics, literature gaps, proposals	Planned experiments and manuscript production	Proposal gating and review triage

In software logging, a GGNN predicts one of trace, debug, info, warn, error, and fatal from a program-graph neighborhood centered on a masked log statement. On seen projects it achieved AUC 0.880 and accuracy 0.657; on unseen projects, AUC fell to 0.760 and accuracy to 0.435 (Li et al., 2019). The system recommends the level of an existing or candidate log location, not whether a log should exist or where it should be placed.

In financial recommendation, FLARKO combines a Personal Knowledge Graph of transactions with a Market Knowledge Graph of asset metadata and ten-week price summaries. KTO fine-tuning uses binary desirability labels based on whether an asset was purchased and profitable within the following 180 days. The system generates three ISINs and evaluates Pref@3, Prof@3, and Comb@3 (Spadea et al., 14 Oct 2025). Its FAR interpretation is domain-specific: Find identifies candidate assets, Attempt models behavioral and market evidence, and Recommend returns a short list. The paper does not formally define the Find–Attempt–Recommend expansion.

In Android method recommendation, FeaRS achieves high sensitivity precision 0.50, medium sensitivity precision 0.62, and low sensitivity precision 0.72, while recall ranges from 0.04 to 0.07 (Wen et al., 2021). These results show the familiar FAR trade-off between broad candidate coverage and recommendation precision. FeaRS lacks a true Attempt phase because recommendations are not compiled, tested, or adapted.

In digital libraries, the hypergraph method achieves precision 0.75, recall 0.60, and F1-score 0.67, exceeding the listed content-based clustering methods (Roy et al., 2023). Its Attempt stage is only an interpretation: successful resource accesses and browsing sessions are treated as information-seeking behavior, not as explicit task execution with verified outcomes.

6. Evaluation, limitations, and future directions

Evaluation principles

FAR systems require metrics for each stage rather than a single end-to-end score. Find should be evaluated with recall, candidate validity, novelty coverage, diversity, and status accuracy. Attempt should measure execution success, correctness, recovery rate, cost, latency, and robustness. Recommend should measure precision, calibration, downstream utility, human-review efficiency, and false-positive rates.

Existing studies reveal the importance of separating these quantities. In mathematical discovery, 1,050 claimed resolutions are not equivalent to 598 judged passes or 77 recommended artifacts (Zheng et al., 17 Aug 2026). In automated research, 166 generated papers are not equivalent to scientifically reliable discoveries: only 17.7% of reviews reached an overall rating of at least 6, and formal integrity violations affected 27.9% of reviewed papers (Tang et al., 30 Jun 2026). In code completion, a cluster-based “correct” recommendation does not establish compilation, semantic equivalence, or developer usefulness (Wen et al., 2021).

Failure modes

Common failure modes recur across domains:

Incomplete Find coverage: relevant problems, papers, repositories, or assets are missed.
Status and novelty errors: a result appears open or novel because retrieval failed to find prior work.
Candidate-generation bias: extracted problems or generated repositories reflect the source distribution and system priors.
Evaluation mismatch: retrospective cluster agreement, one-window profitability, or automated answer matching may not represent practical utility.
Weak feedback: binary failure signals may encourage resampling without targeted correction.
Critic error: value models, judges, or graders can misattribute failures or rank unsafe alternatives.
Regression: later attempts may discard partially successful artifacts unless best-so-far preservation is used.
Selection bias: manually reviewed or reported outputs are often selected by researcher interest.
Resource concentration: expensive reasoning and human review may be allocated to candidates with poorly calibrated scores.
Integrity and safety failures: polished outputs can contain unsupported claims, fabricated results, insecure code, or unsuitable recommendations.

The studies also expose domain-specific limitations. Robotic Failure-Aware Retry depends on recoverable scenes and indirect failure attribution (Hao et al., 1 Jul 2026). Mathematical FAR lacks formal proof certification and exhaustive novelty checking (Zheng et al., 17 Aug 2026). FARS lacks a validated project-ranking objective and independent replication of its outputs (Tang et al., 30 Jun 2026). Financial recommendation systems face temporal leakage, suitability, privacy, fairness, and transaction-cost concerns (Spadea et al., 14 Oct 2025). GGNN log-level prediction generalizes imperfectly to unseen projects (Li et al., 2019).

Toward complete FAR systems

A more complete FAR architecture would maintain persistent state across attempts and explicitly represent:

candidate provenance;
positive and negative evidence;
evaluator uncertainty;
execution cost;
user or institutional constraints;
historical best artifacts;
verification status;
review history;
safety and integrity flags.

The recommendation objective should be multi-objective rather than based only on a single functional score. Functional correctness, scientific value, maintainability, safety, cost, uncertainty, novelty, and reproducibility may conflict. Recommendation should therefore expose trade-offs and preserve provenance rather than silently collapse them into an opaque scalar.

Future systems should also incorporate adaptive allocation. Early attempts can estimate candidate difficulty and probability of success; later resources can be directed toward candidates with high expected value, high information gain, or high uncertainty. The mathematical FAR formulation provides a basis for this approach through budgeted selection and submodular maximum-importance objectives (Zheng et al., 17 Aug 2026).

Formal and external verification are particularly important. Mathematical systems may require proof assistants; code systems require compilation, tests, static analysis, and security checks; robots require reliable task-progress and failure detectors; financial systems require risk-adjusted and portfolio-level evaluation; automated research systems require independent replication and artifact-grounded integrity audits.

FAR is thus best characterized as a family of resource-allocation and feedback architectures organized around three separable questions: what should be considered, what happens when it is tried, and what should be retained or forwarded afterward. Its strongest implementations combine high-recall discovery, explicit evaluation, persistent failure and success information, and conservative selection. Its principal unresolved problem is recommendation validity: finding and attempting many candidates is not sufficient unless the system can reliably determine which outcomes are correct, novel, useful, safe, and worthy of further human or machine investment.