Explorer-Definer Pipeline: Two-Stage Architecture
- Explorer-Definer Pipeline is an architectural split that separates open-ended hypothesis generation (Explorer) from transformation synthesis (Definer) for verifiable outputs.
- It employs a two-stage design where Explorers generate diverse candidate patterns and Definers convert them into executable, validated representations.
- The approach underpins systems in abstract reasoning, scientific literature ingestion, and GUI automation by coupling broad exploration with rigorous verification.
Searching arXiv for the cited papers to ground the article in current literature. I’m retrieving the relevant arXiv entries now. Searching for (Moghe et al., 7 Jul 2026, Black, 11 Jun 2026), and (Chaimalas et al., 12 Apr 2025). Explorer-Definer Pipeline denotes an architectural split in which an exploratory stage generates hypotheses, candidate patterns, or environment structure, and a defining stage converts that exploratory output into an explicit, verifiable, and reusable representation. In "Cost-Effective Agent Harnesses for Abstract Reasoning and Generalization on ARC-AGI-1," the term names a two-stage agent pipeline that separates pattern discovery from executable transformation synthesis (Moghe et al., 7 Jul 2026). In "A General Pipeline for Digesting Scientific Literature into a Shared Scientific Knowledge Base," the same split appears as a broader design pattern: schema design and normalization stabilize what scientific knowledge means, while ingestion, visualization, similarity search, and corpus mining explore a growing literature corpus (Black, 11 Jun 2026). "Explorer: Robust Collection of Interactable GUI Elements" describes a system that is already very close to the Explorer half of such a pipeline, discovering GUI elements, states, and transitions that a downstream Definer could consume (Chaimalas et al., 12 Apr 2025).
1. Core concept and cross-domain formulation
Across the cited works, the Explorer-Definer split is not a single implementation but a recurring architectural principle. The Explorer side is responsible for broad search, hypothesis surfacing, environment discovery, or corpus traversal. The Definer side is responsible for turning those exploratory outputs into a stable representation: executable code, schema-bound records, or task/action definitions. The separation is explicit in the ARC-AGI-1 system, implicit but named in the scientific-literature pipeline, and prospective in the GUI-automation setting.
| Context | Explorer role | Definer role |
|---|---|---|
| ARC-AGI-1 | PatternExplorer agents inspect training pairs and produce pattern documents | TransformationDefiner synthesizes Python transformations |
| Scientific literature | Ingester, Explorer UI, and corpus mining explore papers and records | Schema, normalization, provenance, confidence, and promotion rules define record structure |
| GUI automation | Explorer discovers interactables, states, transitions, and traces | A downstream system could define tasks, accessibility overlays, or agent policies |
This suggests a general criterion for the pattern: the exploratory stage handles open-ended search under uncertainty, while the defining stage imposes operational closure. In the ARC setting, closure is executable transformation code checked against training pairs. In the literature setting, closure is a Portable Unit of Knowledge with provenance, confidence, and schema compliance. In the GUI setting, closure would be a higher-level task or policy expressed over detected interactables and state transitions.
2. Two-stage agent architecture in ARC-AGI-1
In the ARC-AGI-1 formulation, each task provides training input-output grid pairs and a single test input , and the goal is to produce the correct output grid . The Explorer-Definer Pipeline uses DeepSeek V3.2 in non-thinking mode, under a strict cost budget, with no ARC-specific fine-tuning. The paper characterizes this as a third regime, distinct from heavy test-time compute over frontier models and benchmark-specific training (Moghe et al., 7 Jul 2026).
The information flow is explicitly staged. Training grids are first sent to multiple PatternExplorer agents. Each explorer independently inspects the training pairs, reasons in a private scratchpad, logs candidate patterns, and emits a structured markdown summary. Those summaries are then compressed into a combined exploration artifact of about 4k tokens per explorer. The TransformationDefiner receives the raw training pairs, the combined explorer artifact, and its own system prompt, and synthesizes one or more Python functions that map input grids to output grids.
The synthesized programs are executed in a restricted sandbox with a 10s timeout, only numpy plus the standard library, and no network. Each candidate program is run on the training inputs, exact-match training accuracy is computed, and candidates are ranked by training accuracy. The system then deduplicates by test prediction: if multiple programs produce the same test grid on , only the highest-ranked program among them is kept. The top- distinct test predictions are used for pass@ evaluation.
The canonical configuration reported in the paper uses explorer count , explorer temperature , and definer count . On the ARC-AGI-1 public 400-task evaluation set, the canonical pipeline reaches 54.75% pass@1 and 57.50% pass@2 at \$0.25/task. The one-shot baseline is 15.50% pass@1 at \$0.002/task, and the CoT baseline is 30.00% pass@1 at \$0.004/task. These figures anchor the claim that decomposition, tool use, and verification recover substantial performance without benchmark-specific training.
3. Explorer phase: pattern discovery; Definer phase: executable transformation synthesis
The PatternExplorer stage is designed for exhaustive, diverse hypothesis generation. Explorers are instructed to inspect structural aspects such as color mappings, symmetries and reflections, object detection and bounding boxes, shape and size relationships, counting, repetition, periodicity, and local versus global rules (Moghe et al., 7 Jul 2026). Each explorer has two tools: think(thought), a private scratchpad not visible to other agents or the downstream Definer, and note_pattern(pattern), a structured logging tool for pattern observations. Explorers are given large per-agent token budgets of about 100k tokens and are instructed to generate multiple hypotheses, note uncertainties, and avoid premature commitment.
The explorer output is not code. It is a structured markdown summary containing high-level rule descriptions, skeleton procedure steps, evidence from examples, and a self-confidence assessment. The purpose of this stage is to widen the hypothesis set upstream, rather than to solve the task directly.
The TransformationDefiner stage converts this exploratory material into an executable representation. It has three tools: think(thought), define_transformation(transformation_summary, reasoning, code), and submit_refined_transformation(what_changed, code). The initial commit specifies a natural-language transformation summary, reasoning that links explorer evidence to the proposed transformation, and Python code. The code implements a function from a grid, represented as a list of lists of integers, to a new grid of the same type.
Training-pair accuracy is the central supervisory signal at inference time. If a candidate passes at least half of the training pairs but not all, the Definer is invoked again with a structured failure summary showing the input grid, expected output grid, and produced output grid for each failing pair. One refinement pass is allowed per Definer. The threshold of at least 50% training accuracy is described as an empirical heuristic: moderately fitting programs are likely partially correct and refinable.
Ablation results clarify which parts of this split are load-bearing. Removing the Definer think tool reduces pass@2 from 57.50% to 51.75%, a decline of 5.75 percentage points, while lowering cost from \$x_{\text{test}}$00.17/task. Removing train-feedback refinement yields 56.75% pass@2, a decline of 0.75 percentage points with a confidence interval that crosses 0. The paper therefore treats decomposition, program verification, and the think scratchpad as the main sources of gain, while refinement appears to contribute only a small benefit.
4. Reflective Orchestrator, bottleneck diagnosis, and selection behavior
The Reflective Orchestrator extends the Explorer-Definer Pipeline by replacing the one-shot Definer stage with a self-guided loop that can define transformations, observe training feedback, refine programs, and reopen exploration when the current abstraction appears wrong (Moghe et al., 7 Jul 2026). It retains the initial Phase 1 explorer fleet but adds a new tool, explore_new_patterns(guidance), which spawns a new small fleet of PatternExplorers with customized guidance describing known wrong directions, gaps in the current hypothesis, and specific training-pair failures.
The spawned explorers run a shortened exploration and return new pattern documents that are appended to the orchestrator’s context. The guidance is explicitly negative-biased: it emphasizes failed hypotheses and ruled-out rule families, with the intention of steering search toward under-explored conceptual regions. The orchestrator may then define a new transformation or refine an existing one in light of the new exploratory evidence.
The loop terminates when training-set accuracy reaches 100%, when the agent calls done(reason), or when predefined fuses are triggered: MAX_ITERATIONS = 15, MAX_CONSECUTIVE_EXEC_ERRORS = 5, and MAX_SPAWN_CALLS = 3. The per-spawn explorer count is 1, motivated by sweep results showing that the step from 2 to 3 yields the largest incremental gain while additional explorers show diminishing returns.
This extension is tied to a specific diagnostic. The paper argues that the pipeline is generation-bound, not selection-bound. Selection is already strong because ranking by training-pair accuracy and deduplication by test prediction capture about 95% of the candidate ceiling. The bottleneck is therefore whether any correct candidate is generated at all. The orchestrator tests this diagnosis by broadening generation rather than changing ranking, and the reported improvements align closely with that prediction: pipeline unbiased pass@1 is 46.40%, orchestrator unbiased pass@1 is 56.21% for a +9.81 percentage-point lift, while pipeline naive pass@2 is 57.50% and orchestrator naive pass@2 is 67.25% for a +9.75 percentage-point lift. The near equality of these lifts is presented as confirmation that the improvement is generation-side.
5. Explorer-Definer as a scientific-literature knowledge pipeline
The Materials Explorer Pipeline presents a domain-agnostic instance of the same architectural division, applied to scientific literature rather than reasoning benchmarks. Its four top-level components are Schema, Ingester, Corpus/Database, and Explorer + Corpus Mining. The paper states that the schema is the “intellectual heart,” defining what is to be captured; the Ingester analyzes each paper and populates the database; the browser-based Explorer visualizes the corpus; and the corpus mining tool surfaces candidate scientific hypotheses (Black, 11 Jun 2026).
The end-to-end data flow begins with PDFs from arXiv and DOE PAGES. Relevance triage is LLM-based and fast, about 15 seconds per paper, and irrelevant papers are logged and skipped. Structured digestion then parses the full document, including text, tables, figures, and supplementary material present in the PDF, and emits one or more Portable Units of Knowledge per paper. A third pass generates a semantic similarity profile for each sample. PUKs are appended to an append-only JSONL corpus ledger, and a processed ledger and idempotency ledger prevent duplication and re-processing. A derived database adds normalization, indexing, and similarity-search structures. The Explorer provides browser-based visualization, interactive search, similarity search, and catchall browsing, while corpus mining reads catchall correlations, builds co-occurrence tables, reasons over evidence tables, and outputs structured findings for human review.
The core record type is the Portable Unit of Knowledge. Each PUK has six blocks: record metadata, sample description, structured measurements, derived quantities, catchall, and similarity profile. The record is self-contained and portable, carrying the measurements, research details, source citations, provenance, and confidence needed for independent use and citation. Structured measurements are sparse and include only fields explicitly supported by the paper. Each populated Block 3 field carries a value, units, a qualitative confidence label of high, medium, or low, and source references such as section, paragraph, table, or figure caption.
The paper makes the Explorer-Definer split explicit. Definer-side components include schema design, the normalization layer, the provenance model, the confidence and quality framework, and the catchall promotion mechanism. Explorer-side components include Ingester triage and extraction, the Explorer UI, catchall browsing, and corpus mining. Schema evolution is driven by the catchall block: fields appearing in the catchall across more than 5% of corpus samples are presented for review as potential candidates for promotion to named schema columns. Human review is built into every stage where AI makes an inference, including structured records and findings.
The superconducting-qubit-materials case study processed 115 publications, of which 35 passed relevance triage, producing 233 sample records across 10 named superconducting material classes, plus 36 “other/unknown material” samples. Extraction verification used ten sample records from distinct publications and 100 field slots: 41 populated and 59 nulls. Of the populated fields, 40 were supported and 1 was ambiguous; all 59 nulls were confirmed; and 108 of 110 catchall items were confirmed. The paper also identifies limitations: data reported solely in figures may be missed or recorded with lower confidence, because the Ingester is not specialized for figure parsing, and extending the Explorer to non-peer-reviewed or supplementary sources raises issues of inherited credibility.
6. Related Explorer-centric systems, applicability, and recurring constraints
The GUI system called Explorer provides a concrete example of an Explorer stage that discovers and structures an environment before any downstream definition of tasks or policies. Its architecture combines environment exploration and data collection with GUI automation and interaction. The main components are an Interactable Detector based on FCOS, a Screen Similarity model based on a Siamese network over FPN and Centerness features, Action Matching, a Trace framework, and a voice-navigation wrapper (Chaimalas et al., 12 Apr 2025).
At training time, live applications are used to collect screenshots and automatically derived ground-truth bounding boxes for interactables. At inference time, the system receives live GUI screenshots and low-level actions, segments the stream into stable states, detects interactables on each state, matches recorded actions to current interactables, and supports trace replay. This yields precisely the artifacts a downstream Definer could consume: interactable inventories, state graphs, traces, and an API-like perception-and-actuation layer. The paper explicitly states that a downstream “Definer” system could use these outputs to define tasks, accessibility overlays, or agent policies.
The system is personalized per target app. Scratch-trained per-app FCOS models outperform fine-tuned generic models. Reported test mAP@0.5 values are 0.97 on KhanAcademy, 0.94 on Spotify, and 0.97 on Android Phone. Screen Similarity reaches test accuracy 0.99 and F1 0.91 on KhanAcademy, and test accuracy 0.96 and F1 0.78 on Spotify. In voice navigation on KhanAcademy, Explorer’s detector achieves 67% success across 15 screen-action pairs, while EasyOCR reaches 93% in that text-dense environment. The paper also reports poor zero-shot generalization across unrelated apps, a requirement for per-app data collection and training, a lack of iOS support, and a resolution-versus-speed tradeoff.
A plausible implication of the three papers taken together is that Explorer-Definer pipelines are most effective when the Explorer can produce a structured intermediate artifact and the Definer can impose a strong constraint on correctness. In ARC-AGI-1, that constraint is exact-match training feedback over executable programs. In scientific-literature ingestion, it is provenance-rich records, sparse extraction, append-only ledgers, and mandatory human review at points of AI inference. In GUI automation, it would be the grounding of high-level task definitions in state-aware interactable inventories and traceable actions.
A second recurring constraint is that the Explorer side benefits from breadth, but uncontrolled breadth is insufficient. The ARC work shows that broader generation is useful only when tied to executable verification and deduplicated selection. The materials pipeline shows that catchall accumulation is useful only when paired with schema evolution and review. The GUI system shows that broad perceptual coverage is useful only when coupled to state segmentation, action matching, and per-app personalization. The resulting pattern is not a synonym for generic chain-of-thought or unconstrained agentic search; it is a decomposition in which exploratory breadth is deliberately paired with a defining mechanism that stabilizes, verifies, or operationalizes what exploration produces.