DataPraxis: Scaling Analytics Tasks via Verified Workspace Evolution

# Scaling Analytics Tasks via Verified Workspace Evolution
Source: [https://arxiv.org/html/2610.26924](https://arxiv.org/html/2610.26924)
Nan Jia††thanks:Equal contribution:[jianan@hust\.edu\.cn](mailto:[email protected]),[shiwenxuan20@mails\.ucas\.ac\.cn](mailto:[email protected])\.Wenxuan ShiAffiliation:Institute of Computing Technology, Chinese Academy of SciencesJingqing Ruan††thanks:Corresponding authors:[ruanjingqing@meituan\.com](mailto:[email protected]),[zengzhizhao@meituan\.com](mailto:[email protected])\.Affiliation:MeituanZhizhao ZengAffiliation:MeituanTianyi ZhaiAffiliation:MeituanZhongda SuAffiliation:MeituanFeng HongAffiliation:MeituanZhengyu ChenAffiliation:MeituanWenhao YanAffiliation:Tsinghua UniversityHaojin YangAffiliation:Peking UniversitySiqi DaiAffiliation:Institute of Automation, Chinese Academy of SciencesWeipeng ZhangAffiliation:MeituanKe ZengAffiliation:MeituanXunliang CaiAffiliation:Meituan

###### Abstract

General\-purpose agents are increasingly expected to perform professional analytics work, which requires sustained reasoning, iterative investigation, and reliable evidence\. Training these capabilities requires diverse and challenging tasks\. However, generating tasks directly from raw data often overlooks deeper questions that emerge through analysis and provides limited evidence for verification\. To address these limitations, we introduce DataPraxis, an analytics task synthesis framework based on verified workspace evolution\. The framework progressively enriches workspaces with validated findings and artifacts, then inherits and combines these workspaces to uncover deeper questions\. It constructs tasks from accumulated findings and their dependencies, verifying analytical results both during evolution and after task assembly\. Using this framework, we construct DataPraxis\-5K, a dataset of 5,000 verified trajectories spanning diverse domains and output formats, to train DataPraxis\-27B and DataPraxis\-35B\-A3B\. DataPraxis\-27B achieves 55\.11 on DABStep and 51\.9 on JobBench, matching or surpassing frontier models such as GLM\-5\.2\. DataPraxis\-5K is available at[huggingface\.co/datasets/stargazerhust/DataPraxis\-5k](https://huggingface.co/datasets/stargazerhust/DataPraxis-5k)\.

## 1Introduction

As large language models acquire capabilities for code execution, tool use, and multi\-turn interaction, general\-purpose agents are beginning to undertake professional work in real environments\([Yao et al\., 2023](https://arxiv.org/html/2610.26924#bib.bib16);[Wang et al\., 2025](https://arxiv.org/html/2610.26924#bib.bib30)\)\. Analysis is a representative example: users expect models not only to answer questions, but also to understand the materials in a working directory, conduct analyses autonomously, and deliver well\-supported conclusions and files\([Hong and others, 2024](https://arxiv.org/html/2610.26924#bib.bib10);[Zhang and others, 2025](https://arxiv.org/html/2610.26924#bib.bib11)\)\. CLI agents such as Claude Code\([Anthropic,](https://arxiv.org/html/2610.26924#bib.bib17)\), Codex\([OpenAI,](https://arxiv.org/html/2610.26924#bib.bib18)\), and Pi Agent\([Zechner and contributors,](https://arxiv.org/html/2610.26924#bib.bib19)\)provide a general\-purpose execution interface for such work\. However, training models to reliably complete these long\-horizon analytical tasks still requires training tasks that cover complex analytical processes and provide reliable evaluation signals\. Constructing such tasks at scale is a key challenge in improving general\-purpose agents’ professional analysis capabilities\.

Existing agent task synthesis methods broadly fall into two categories\. The first generates and combines tasks based on data descriptions and predefined structures\([Qiao and others, 2026](https://arxiv.org/html/2610.26924#bib.bib1);[Xie and others, 2025](https://arxiv.org/html/2610.26924#bib.bib8);[Shi and others, 2025](https://arxiv.org/html/2610.26924#bib.bib9)\)\. These methods guide task generation and increase complexity, but may struggle to discover tasks that emerge only through actual analysis\. The second constructs tasks from interaction experience and execution evidence obtained through environment exploration\([Mai and others, 2025](https://arxiv.org/html/2610.26924#bib.bib6);[Chen and others, 2026](https://arxiv.org/html/2610.26924#bib.bib7)\)\. These methods ground tasks in interaction evidence, but offer limited support for discovering deeper tasks that require further computation on prior results or integration of findings across analytical branches\. Discovering deeper questions that are not apparent from raw materials through continued analysis therefore remains a key challenge in professional data analysis task synthesis\. Meanwhile, intermediate findings are not inherently reliable, and errors can propagate when these findings are reused\. Even when local findings are confirmed, the complete tasks constructed from them may still lack reliable evaluation criteria\. Ensuring both the trustworthy accumulation of analytical results and reliable evaluation of the resulting tasks is another key challenge\.

![Refer to caption](https://arxiv.org/html/2610.26924v1/figures/discovery_current.png)Figure 1:Up:Tasks are generated from the initial materials without workspace evolution\.Down:DataPraxis inherits and combines verified analytical results through workspace evolution, providing new grounds for discovering deeper questions\.To this end, we propose DataPraxis, a professional analytical task synthesis framework based on verified workspace evolution\. Its central idea is that analytical results are not only answers to current questions, but also a basis for discovering subsequent ones\. DataPraxis retains scripts, intermediate data, and analytical findings produced during execution in executable workspaces, enabling subsequent analysis to inherit prior results, explore new directions, and combine different branches for joint analysis\. Figure[1](https://arxiv.org/html/2610.26924#S1.F1)illustrates the role of workspace evolution in task discovery: without continued workspace evolution, task generation cannot fully exploit progressively accumulated analytical results; by inheriting and combining verified workspaces, DataPraxis enriches the basis for proposing questions, progressively revealing deeper questions that are difficult to discover directly\. The framework then constructs tasks backward from the resulting findings and their dependencies, removing intermediate support from the evolution process so that solvers must independently reconstruct the analysis from raw materials, thereby converting accumulated analytical dependencies into challenging long\-horizon training tasks\. To ensure reliability from analytical discovery to task construction, DataPraxis introduces dual\-evidence verification, combining verified findings from workspace evolution with independent solution trajectories to construct and validate evaluation rubrics\. These rubrics assess final deliverables and filter solution trajectories for training\.

Our main contributions are as follows:

- •We propose DataPraxis, a data analysis task synthesis framework based on workspace evolution\. Verified workspace evolution and dual\-evidence verification enable the scalable construction of challenging, verifiable terminal\-agent tasks\.
- •We construct DataPraxis\-5K, containing 5K long\-horizon professional analytical training examples across 15 domains, including business, finance, sports, and entertainment\. We train DataPraxis\-27B, a 27B dense model, and DataPraxis\-35B\-A3B, a 35B mixture\-of\-experts model with 3B active parameters\.
- •We demonstrate that workspace\-evolution\-based synthesis improves agents’ ability to perform data analysis work\. DataPraxis\-27B achieves leading performance among the evaluated models on data analysis and long\-horizon professional tasks\.

![Refer to caption](https://arxiv.org/html/2610.26924v1/main_pic_v2.png)Figure 2:The DataPraxis framework\. \(a\) The Profiler characterizes the initial data and domain\. \(b\) Verified workspace evolution progressively discovers and validates analytical findings, which are converted into standalone tasks through backward synthesis\. \(c\) Dual\-evidence verification combines evidence from evolution with independent solving trajectories\.
## 2Motivation

LetX0=\(𝒟,ℰ\)X\_\{0\}=\(\\mathcal\{D\},\\mathcal\{E\}\)denote a seed workspace containing data assets𝒟\\mathcal\{D\}and an execution environmentℰ\\mathcal\{E\}\. DataPraxis constructs a task instructionqqand a verifierVVfrom this workspace:

X0⟶\(q,V\)\.X\_\{0\}\\longrightarrow\(q,V\)\.\(1\)The instructionqqspecifies the analytical objective and delivery requirements for an agent operating inX0X\_\{0\}\. The verifierVVevaluates the analytical correctness, supporting evidence, and overall quality of the agent’s final output\. The challenge is to formulate deep analytical questions from the initial workspace, where many patterns and relationships have yet to be uncovered\. Findings uncovered during analysis can motivate questions that are not apparent from the initial workspace alone\.

To examine how analysis informs subsequent questions, an agent investigates three successive questions in each of 50 workspaces, using findings from one analysis to formulate the next question\.

![Refer to caption](https://arxiv.org/html/2610.26924v1/figures/question_perplexity.png)Figure 3:Question perplexity with initial workspace information alone or with accumulated findings\.We use Qwen3\.6\-27B to measure the perplexity of each proposed question given either the initial workspace alone or the initial workspace together with findings from earlier analyses\. Figure[3](https://arxiv.org/html/2610.26924#S2.F3)shows that mean perplexity given only the initial workspace rises from 16\.87 to 31\.07, whereas including prior findings reduces it by 46\.1% and 53\.0% in rounds 2 and 3, respectively\. These observations suggest that continued analysis gives rise to questions that are less apparent from the initial workspace, while accumulated findings provide useful context for formulating them\.

Motivated by this observation, DataPraxis evolves a workspace by updating its state with verified results from each analysis\. A workspace state captures the data, scripts, and analytical results available to an agent within its execution environment at a given stage\. Each update carries forward prior analytical assets and incorporates new findings, providing the basis for subsequent analysis\. For each evolution path, DataPraxis traces the accumulated findings and their dependencies backward to synthesize one task:

X0→EvolveX1→Evolve⋯→EvolveXm→Synthesis\(q,V\),X\_\{0\}\\xrightarrow\{\\text\{Evolve\}\}X\_\{1\}\\xrightarrow\{\\text\{Evolve\}\}\\cdots\\xrightarrow\{\\text\{Evolve\}\}X\_\{m\}\\xrightarrow\{\\text\{Synthesis\}\}\(q,V\),\(2\)wheremmis the number of evolution steps andX1,…,XmX\_\{1\},\\ldots,X\_\{m\}are the successive workspace states\. Theqqrequires a single agent to reconstruct the analysis fromX0X\_\{0\}within one session, without access to scripts, intermediate artifacts, or conclusions produced during evolution\.

## 3Method

### 3\.1Workspace Initialization and Profiling

As shown in Figure[2](https://arxiv.org/html/2610.26924#S1.F2)\(a\), we collect raw datasets containing files in diverse formats from Kaggle, DataWorld, and GitHub repositories to construct initial workspace\. Filtering by relational structure and size yields 500 data collections spanning 15 domains, including business, government, human resources, and others\. Each collection is paired with a shared execution environmentℰ\\mathcal\{E\}, including dependencies such as pandas and NumPy, to form a seed workspaceX0X\_\{0\}\.

A common approach to task synthesis uses predefined task categories as seeds to guide generation\([Qiao and others, 2026](https://arxiv.org/html/2610.26924#bib.bib1);[Zhang and others, 2025](https://arxiv.org/html/2610.26924#bib.bib11)\)\. However, a fixed taxonomy limits the range of questions considered, while model preferences may further concentrate generation on familiar categories\. DataPraxis therefore derives seeds from each workspace’s data and domain properties\. A Profiler Agent analyzes𝒟\\mathcal\{D\}to construct a*Workspace Profile*, capturing relationships among tables, data pitfalls, and field semantics, alongside relevant analytical methods and common domain questions\. This profile connects the available data with domain problems, guiding the generation of diverse analytical objectives suited to each workspace\.

### 3\.2Task Synthesis via Verified Workspace Evolution

Building on the workspace profile, DataPraxis constructs task instructions through progressive workspace evolution followed by backward synthesis\. As shown in Figure[2](https://arxiv.org/html/2610.26924#S1.F2)\(b\), evolution strategy selection determines which states to inherit and how to advance the analysis\. Verified workspace evolution then updates these states through execution and verification, providing a basis for subsequent objectives\. Finally, backward task synthesis converts the accumulated analytical dependencies into task instructions, withholding intermediate support to require independent completion\.

#### 3\.2\.1Evolution Strategy

Starting from a workspace with no predefined task, DataPraxis uses a director agent to decide where analysis should proceed\. The director considers the workspace profile and findings verified during earlier evolution steps to select eligible source workspaces\. It proposes an analytical question grounded in the available data and distinct from earlier analyses\. When extending an existing workspace, the director identifies the specific prior finding on which the new question depends\. It then selects an evolution mode according to how the question draws on the chosen workspaces\. Table[1](https://arxiv.org/html/2610.26924#S3.T1)summarizes the four modes\.

Table 1:Workspace evolution modes\. The mappings→ts\\to tdenotessssource workspaces andttanalytical directions, withk≥2k\\geq 2\.Bothdeepenandsearchstart from a single source workspace\. The former evolves the workspace by investigating existing findings in greater depth, while the latter expands its contents by retrieving and filtering relevant external materials\. The other two modes support workspace branching and merging\. Starting from a single workspace,decomposedivides a compound objective into complementary subtasks, each driving the evolution of an isolated workspace\. Undercompose, complementary verified workspaces are merged after conflicts among their contents have been resolved\. The merged workspace then evolves through an integrated analysis that requires findings from multiple sources\. Together, these modes produce diverse workspace evolution paths, enabling the synthesis of tasks with different analytical dependencies\.

#### 3\.2\.2Verified Workspace Evolution

Each evolution step builds on inherited workspace states through workspace preparation, analytical modification, and verification, coordinated by four agents: director, proposer, executor, and validator\. The director uses the workspace profile and previously verified findings to identify an analytical question that is grounded in the data and distinct from earlier analyses\. It selects the source workspaces and an evolution mode based on what the question requires\. When extending an existing workspace, the director identifies the specific prior finding on which the new analysis depends\. The proposer then prepares the inherited workspace state by organizing its data and analytical assets\. When combining multiple sources, it removes duplicate materials and resolves file conflicts\. The proposer formulates a local analytical objective and explicit output requirements from the prepared state\. The executor updates the workspace to address this objective through reasoning and tool use\. It incorporates relevant materials, creates or revises scripts, and produces artifacts and findings\.

Before this state can support further evolution, the validator reviews the changes in the workspace\. It checks whether data dependencies, metric definitions, and analytical methods are appropriate\. It also assesses whether evidence supports the conclusions and whether scripts reproduce the reported results\. If errors are found, the executor revises the affected workspace contents and submits the changes for another review\. This cycle continues until no errors are identified or the review limit is reached\. Updates that pass verification are retained as new workspace states, while those with unresolved errors are discarded\. The accepted states can then serve as sources for another evolution step, where their findings inform new objectives and their analytical assets support execution\. Repeating this procedure produces multiple evolution paths, preserving verified findings, supporting materials, and their dependencies for backward task synthesis and subsequent collection of evolution evidence\.

#### 3\.2\.3Backward Task Synthesis

Backward synthesis converts verified analyses from workspace evolution into standalone tasks and collects evolution evidence for subsequent dual\-evidence verification\. DataPraxis first selects a target evolved workspace and uses its findings to define the task’s objective\. It traces the evolution path backward to the initial workspaceX0X\_\{0\}, converting dependencies on prior findings into explicit task requirements\. For example,searchnodes yield retrieval instructions, while computations atdeepennodes become prerequisite analysis steps\. The task instructionqqcombines these requirements and specifies a deliverable format suited to the domain, such as JSON, Markdown, or a spreadsheet\. During this backward traversal, DataPraxis collects evolution evidence: the verified findings and supporting materials accumulated along the evolution path\. This evidence is passed to the rubric generator and combined with solution evidence from independent reference trajectories to ground task\-specific evaluation criteria\. GivenqqandX0X\_\{0\}, the solver independently plans the full workflow, reconstructs the supporting evidence, and produces the requested deliverable within one session\. This consolidates analyses previously distributed across multiple agents into one task, placing greater demands on independent planning and sustained reasoning\. Appendix[B\.1](https://arxiv.org/html/2610.26924#A2.SS1)illustrates how workspace evolution and composition lead to a standalone task through a hotel pricing example\.

### 3\.3Dual\-evidence Verification and Rejection Sampling

Backward synthesis turns verified analyses into task instructions, but evidence from workspace evolution alone does not directly establish criteria for evaluating independently produced deliverables: a solver may follow a different analytical path\. DataPraxis therefore uses dual\-evidence verification to construct and validate task\-specific evaluation rubrics from two evidence sources, as shown in Figure[2](https://arxiv.org/html/2610.26924#S1.F2)\(c\)\. Evolution evidence consists of verified findings and supporting materials collected along the workspace evolution path during backward synthesis\. Solution evidence is extracted from reference trajectories produced by two models that independently solve the synthesized task from the initial workspaceX0X\_\{0\}in a sandbox\. The rubric generator combines both sources to define criteria for conclusions, analytical methods, and delivery requirements\. The rubric validator then checks whether each rubric is grounded in the data, assessable from the final deliverable, and explicit about what constitutes a satisfactory result\. Rubrics that fail these checks are revised and revalidated, or removed if they remain invalid\. Appendix[B\.2](https://arxiv.org/html/2610.26924#A2.SS2)presents a case study of rubric synthesis and validation\.

DataPraxis packages the synthesized instruction, initial workspace, execution environment, and validated rubrics into a Harbor task\. We uses the rubrics to select teacher trajectories through rejection sampling\. It assesses the final deliverables of candidate teacher trajectories against the rubrics constructed and validated using evolution evidence and solution evidence, retaining only runs that pass task\-level verification\. The final training dataset contains the accepted trajectories, any continuations after context compaction, and subagent trajectories from those runs\.

## 4Experiments

### 4\.1Experimental Setup

##### Models and harness\.

We evaluate whether DataPraxis improves data analysis agents built on Qwen3\.6\-27B\([Qwen Team, 2026a](https://arxiv.org/html/2610.26924#bib.bib31)\)and Qwen3\.6\-35B\-A3B\([Qwen Team, 2026b](https://arxiv.org/html/2610.26924#bib.bib32)\)\. We use Claude Code\([Anthropic,](https://arxiv.org/html/2610.26924#bib.bib17)\)as the harness for both trajectory collection and evaluation\. The models trained on DataPraxis\-5K are denoted DataPraxis\-27B and DataPraxis\-35B\-A3B, respectively\.

##### Benchmarks\.

We evaluate the effectiveness of DataPraxis training data on three benchmarks: \(1\) DABStep\([Egg and others, 2025](https://arxiv.org/html/2610.26924#bib.bib2)\)measures data analysis reasoning across multiple steps; \(2\) JobBench\([Li and others, 2026a](https://arxiv.org/html/2610.26924#bib.bib3)\)assesses agents’ ability to analyze heterogeneous data and produce professional deliverables across occupations; \(3\) RideBench is a benchmark developed internally by a company for business analysis in ride\-hailing scenarios, with construction details in Appendix[A](https://arxiv.org/html/2610.26924#A1)\. We conduct all benchmark evaluations in Harbor sandboxes and use Gemini\-3\.7\-Flash as the judge model\.

##### Baselines\.

We compare DataPraxis\-27B and DataPraxis\-35B\-A3B against 7 leading frontier models from the Claude\([Anthropic, 2026](https://arxiv.org/html/2610.26924#bib.bib24)\), Kimi\([Moonshot AI, 2026](https://arxiv.org/html/2610.26924#bib.bib25)\), GLM\([Z\.ai, 2026](https://arxiv.org/html/2610.26924#bib.bib26)\), DeepSeek\([DeepSeek, 2026](https://arxiv.org/html/2610.26924#bib.bib27)\), GPT\([OpenAI, 2026](https://arxiv.org/html/2610.26924#bib.bib28)\), and Gemini\([Doshi, 2026a](https://arxiv.org/html/2610.26924#bib.bib29);[Doshi, 2026b](https://arxiv.org/html/2610.26924#bib.bib33)\)families\. For each backbone, we also compare against the original model and a counterpart trained on 5K DataMind examples\([Qiao and others, 2026](https://arxiv.org/html/2610.26924#bib.bib1)\)\. To match our agent framework and training set size, we regenerate the DataMind solution trajectories using GLM\-5\.2 in Claude Code\.

##### Implementation and training\.

We use GLM\-5\.2 as the backbone model\. For dual\-evidence verification, DeepSeek\-V4\-Pro and Kimi\-K3 provide reference trajectories\. We construct a training set of 5K trajectories, including continuations after context compaction and subagent trajectories\. The agent prompts in DataPraxis are provided in Appendix[E](https://arxiv.org/html/2610.26924#A5)\. We use LlamaFactory\([Zheng et al\., 2024](https://arxiv.org/html/2610.26924#bib.bib34)\)for supervised fine\-tuning\. We train the base models for 5 epochs, using a learning rate of1×10−61\\times 10^\{\-6\}, a batch size of 32, and a maximum sequence length of 128K tokens\.

Table 2:Performance on data analysis benchmarks\. Scores marked with†\\daggerare taken from the DABStep leaderboard\.

### 4\.2Main Results

Table[2](https://arxiv.org/html/2610.26924#S4.T2)reports consistent improvements across both backbones and all three benchmarks after training on DataPraxis\. The average benchmark score rises from 48\.36 to 60\.39 for Qwen3\.6\-27B and from 42\.43 to 55\.19 for Qwen3\.6\-35B\-A3B\. DABStep Hard shows particularly large gains in pass rate, at 23\.28 and 19\.31 percentage points, respectively, suggesting improved reasoning across multiple analytical steps\. For the challenging workplace tasks in JobBench, the corresponding score increases are 13\.40 and 9\.70 points\. RideBench scores reach 74\.16 and 71\.91, up by 3\.37 and 12\.36 points, extending the observed benefits to practical business analysis\.

A comparison with DataMind further examines the effectiveness of the synthesis approach at a fixed training set size of 5K examples\. Using DataPraxis yields average benchmark scores higher by 9\.14 points for Qwen3\.6\-27B and 13\.66 points for Qwen3\.6\-35B\-A3B\. These advantages demonstrate the value of workspace evolution for synthesizing training data for complex analytical tasks\.

With just 5K training examples, both DataPraxis models also achieve scores close to or above those of several frontier models\. DataPraxis\-27B is comparable to GLM\-5\.2 in both average benchmark score and JobBench score, while exceeding DeepSeek\-V4\-Pro, GPT\-5\.6\-Terra, and Gemini\-3\.6\-Flash in average score\. For DataPraxis\-35B\-A3B, the DABStep score is close to those of DeepSeek\-V4\-Pro\. Taken together, these comparisons demonstrate the potential of synthesized training data to make smaller models competitive with frontier models on complex analytical tasks\.

### 4\.3Ablation Studies

##### Training data volume\.

Table[4](https://arxiv.org/html/2610.26924#S4.F4)shows that increasing the training set from 2K to 5K examples improves the DABStep score from 48\.89% to 55\.11% and JobBench from 45\.50 to 51\.90\. From 4K to 5K examples, DABStep gains 0\.66 percentage points, while JobBench improves by a further 3\.10 points\. DABStep emphasizes prerequisite computations within complex analyses, whereas JobBench requires agents to complete complex tasks and produce deliverables\. The continued improvement on JobBench suggests that additional training data remain valuable for learning to complete such tasks, even as gains on the computational subtasks become smaller\.

Table 3:Ablation results for Qwen3\.6\-27B\. DataPraxis\-5K uses 5K training examples with verification\. DABStep reports overall scores\.Figure 4:Average pass rate and tool\-call turns across evolution depths\.

##### Evolution depth\.

We define task evolution depth as the number of evolution steps along the longest dependency chain from the initial workspace to the workspace selected for synthesis\. To examine how depth affects task difficulty, we use Qwen3\.6\-35B\-A3B to solve synthesized tasks independently\. Figure[4](https://arxiv.org/html/2610.26924#S4.F4)shows that the task pass rate decreases from 35\.60% at depth 1 to 22\.90% at depth 4, while the mean number of turns involving tool calls increases from 17\.8 to 30\.1\. These trends indicate that deeper tasks require more tool interaction and are harder for the model to solve\. We further examine how tasks synthesized at different evolution depths contribute to model performance\. Table[4](https://arxiv.org/html/2610.26924#S4.F4)compares two Qwen3\.6\-27B models, each trained on 2K tasks\. The shallow setting uses tasks synthesized at workspace evolution depths 1–2, while the deep setting uses tasks from depths 3–5\. Compared with the shallow setting, the deep setting improves the JobBench score by 2\.30 points, suggesting that the greater demands of deeper workspace evolution can benefit learning to complete complex tasks\. The shallow setting, in turn, achieves a DABStep score 1\.78 percentage points higher than the deep setting, indicating the value of earlier evolution stages for learning prerequisite analytical computations\. These complementary benefits motivate selecting tasks from both shorter and longer workspace evolution paths to develop both capabilities\.

Figure 5:Teacher ablation for Qwen3\.6\-27B using 5K training trajectories per teacher\. Benchmark values denote student scores, with the best in bold\.
##### Dual\-evidence verification\.

With the training set size fixed at 5K examples, removing dual\-evidence verification on trajectories reduces DABStep from 55\.11% to 50\.00% and JobBench from 51\.90 to 47\.50\. Sampled trajectories from teacher model may contain undesirable behavioral patterns or analyses that lack sufficient evidential support\. Dual\-evidence verification excludes trajectories whose deliverables fail the rubrics, helping remove unreliable solutions\.

##### Trajectory teacher\.

Figure[5](https://arxiv.org/html/2610.26924#S4.F5)compares student performance and the mean reasoning length of training trajectories from three teachers\. Kimi\-K3 has the highest average teacher score in Table[2](https://arxiv.org/html/2610.26924#S4.T2), yet students trained on GLM\-5\.2 trajectories score 10\.59 percentage points higher on DABStep Hard\. Compared with DeepSeek\-V4\-Pro, GLM\-5\.2 yields student scores 3\.71 percentage points higher on DABStep Hard and 6\.10 points higher on JobBench\. DeepSeek\-V4\-Pro yields the highest student score on DABStep Easy, at 90\.28%\. Teacher performance alone does not predict how much the student benefits from its trajectories\. Kimi\-K3 has the lowest mean reasoning length and may leave intermediate steps implicit despite its stronger reasoning\. DeepSeek\-V4\-Pro averages 45,716 characters, but its longer reasoning does not yield better performance\. GLM\-5\.2 offers a more suitable balance of reasoning quality and explicit intermediate steps for these tasks\.

### 4\.4Diversity of Analytical Behaviors

![Refer to caption](https://arxiv.org/html/2610.26924v1/figures/taxonomy.png)

\(a\)

![Refer to caption](https://arxiv.org/html/2610.26924v1/figures/umap.png)

\(b\)

Figure 6:Analytical diversity\. \(a\) Action shares across the top\-level behavioral clusters derived from DataPraxis\-5k\. \(b\) UMAP projection of action representations from DataPraxis and DataMind\.By varying source workspaces and evolution strategies, DataPraxis constructs tasks with different analytical requirements\. We characterize the behavior diversity in training trajectories using a hierarchical clustering procedure inspired by Clio\([Tamkin and others, 2024](https://arxiv.org/html/2610.26924#bib.bib4)\)\. Each action represents a coherent analytical intent\. We embed individual actions with Qwen3\-4B\-Embedding\([Zhang et al\., 2025](https://arxiv.org/html/2610.26924#bib.bib20)\), cluster their representations, and use GLM\-5\.2 to name the clusters\. In each subsequent round, the names assigned in the preceding round are embedded, clustered, and named in the same manner\. Three rounds of this procedure produce a behavioral hierarchy without predefined categories\.

Figure[6](https://arxiv.org/html/2610.26924#S4.F6)\(a\) shows that DataPraxis trajectories span 17 top\-level behavioral clusters, indicating diversity across forms of analytical work\. Clusters for structure analysis and anomaly repair appear alongside those for grouped comparison and output verification, with further behaviors represented by the remaining clusters\. Figure[6](https://arxiv.org/html/2610.26924#S4.F6)\(b\) projects the action representations used in the initial clustering round into a common UMAP\([McInnes et al\., 2018](https://arxiv.org/html/2610.26924#bib.bib21)\)space\. Its annotations describe the analytical behaviors captured by selected clusters\. Compared with DataMind, DataPraxis actions occupy a broader range of behavioral regions in the projection, providing qualitative evidence that its trajectories encompass more varied analytical work\.

## 5Related Work

##### Task\-Type and Skill Guided Task Synthesis\.

DataMind\([Qiao and others, 2026](https://arxiv.org/html/2610.26924#bib.bib1)\)generates analytical questions from data metadata, fine\-grained task categories, and exemplars, then increases complexity through recursive composition\. DeepAnalyze\([Zhang and others, 2025](https://arxiv.org/html/2610.26924#bib.bib11)\)conditions interaction\-task generation on sampled task types before executing and checking solution trajectories\. AgenticDataBench\([Sun and others, 2026](https://arxiv.org/html/2610.26924#bib.bib5)\), SkillSynth\([Fan and others, 2026](https://arxiv.org/html/2610.26924#bib.bib14)\), and SkillNet\([Liang and others, 2026](https://arxiv.org/html/2610.26924#bib.bib15)\)organize task generation through skill paths or workflows, with SkillNet additionally using exploration reports to construct tasks and evaluation components\. These methods enable targeted coverage of specified tasks or skills\. However, predefined categories and skill structures may constrain question discovery\. Our DataPraxis continually guides task generation with verified analytical findings, uncovering deeper questions beyond these predefined structures\.

##### Exploration\-Based Task Synthesis\.

OS\-Genesis\([Sun and others, 2024](https://arxiv.org/html/2610.26924#bib.bib12)\)and CuES\([Mai and others, 2025](https://arxiv.org/html/2610.26924#bib.bib6)\)construct tasks from state transitions or interaction patterns obtained through environment exploration\. AutoPlay\([Ramrakhya et al\., 2025](https://arxiv.org/html/2610.26924#bib.bib22)\)explores environment states and available functionalities before generating tasks from the resulting trajectories\. WebExplorer\([Liu et al\., 2025](https://arxiv.org/html/2610.26924#bib.bib23)\)discovers interconnected facts through search and browsing before generating and iteratively refining questions\. DIVE\([Chen and others, 2026](https://arxiv.org/html/2610.26924#bib.bib7)\)alternates tool execution, evidence accumulation, and backward question construction\. Yet these methods offer limited support for reusing computations and combining analytical branches\. Our DataPraxis inherits and merges verified workspaces to uncover deeper questions beyond individual branches, while retaining traceable evidence for task evaluation\.

##### Compositional and Evolutionary Task Synthesis\.

AgentSynth\([Xie and others, 2025](https://arxiv.org/html/2610.26924#bib.bib8)\)alternates the generation and execution of state\-dependent subtasks before integrating them into long\-horizon instructions\. TaskCraft\([Shi and others, 2025](https://arxiv.org/html/2610.26924#bib.bib9)\)introduces task dependencies through depth expansion and combines independent subtasks through width expansion\. Recursive Synthesis\([Li and others, 2026b](https://arxiv.org/html/2610.26924#bib.bib13)\)extends reference solutions from verified seed tasks, jointly updates instructions, environments, and verifiers, and revalidates the resulting tasks\. These methods increase task complexity by composing subtasks or extending existing solutions\. While adding steps can increase task complexity, it does not necessarily reveal objectives that emerge through analysis\. Our DataPraxis constructs tasks backward from verified findings and their dependencies, turning these emergent objectives into analytically demanding tasks with grounded evaluation criteria\.

## 6Conclusion

We introduced DataPraxis, a framework that uses verified workspace evolution to synthesize professional analytical tasks\. By accumulating and combining analytical findings, it uncovers deeper questions that are difficult to formulate from raw materials alone\. Verification draws on evolution evidence alongside solution evidence to establish task criteria and filter training trajectories\. Experiments with DataPraxis\-5K demonstrated improved agent performance across two model scales and multiple benchmarks\. These findings support the value of accumulated workspace knowledge as a foundation for synthesizing deeper tasks\. DataPraxis offers a promising approach to scaling task difficulty, opening new possibilities for pushing the boundaries of model capabilities\. We illustrate limitations in Appendix[D](https://arxiv.org/html/2610.26924#A4)\.

### AI use statement

We used generative AI tools to support research ideation and execution, retrieve and discover related literature, translate manuscript content, draft sections of the paper, and polish the manuscript’s wording and presentation\. We also used these tools to generate the synthetic dataset introduced in this work\.

Within DataPraxis, language models profile workspaces, propose and execute analytical tasks, validate workspace changes, assemble task instructions, construct and validate rubrics, and generate training trajectories\. The synthesis and reference models are specified in the experimental setup\. We additionally use a language model to name behavioral clusters in Section[4\.4](https://arxiv.org/html/2610.26924#S4.SS4)\. Generated analyses and trajectories undergo the execution and verification procedures described in Section[3](https://arxiv.org/html/2610.26924#S3), with examples in Appendix[B](https://arxiv.org/html/2610.26924#A2)\. The authors take responsibility for the final text, claims, and research artifacts, including content prepared with AI assistance\.

### Ethics statement

DataPraxis is constructed from publicly available datasets obtained from Kaggle, DataWorld, and GitHub repositories\. We checked the license of each source dataset to ensure that its use in this work is permitted\. The data used in this study do not contain sensitive personal information\. Task instructions, evaluation rubrics, and solution trajectories are generated through the automated synthesis pipeline, without human annotation or participation by human subjects\. RideBench uses simulated order, driver, and passenger records, as described in Appendix[A](https://arxiv.org/html/2610.26924#A1)\. We release DataPraxis\-5K for research on analysis agents\. The release respects the licenses and redistribution conditions of the underlying source datasets\.

### Reproducibility statement

Section[3](https://arxiv.org/html/2610.26924#S3)describes workspace initialization, the evolution modes, backward task synthesis, and verification for trajectory selection\. The experimental setup specifies the synthesis and reference models, execution harness, training hyperparameters, benchmarks, and baseline construction\. Appendix[E](https://arxiv.org/html/2610.26924#A5)provides the agent prompts and structured output formats used for task synthesis and verifier construction\. Appendix[A](https://arxiv.org/html/2610.26924#A1)documents RideBench’s simulation procedure, scenarios, and task distribution\. Appendix[B](https://arxiv.org/html/2610.26924#A2)illustrates workspace evolution and rubric validation, while Appendix[C](https://arxiv.org/html/2610.26924#A3)defines the behavioral measurements and presents comparisons of model behavior before and after training\.

## References

- \[1\]AnthropicClaude Code\.Note:Official software repositoryAccessed September 17, 2026External Links:[Link](https://github.com/anthropics/claude-code)Cited by:[§1](https://arxiv.org/html/2610.26924#S1.p1.1),[§4\.1](https://arxiv.org/html/2610.26924#S4.SS1.SSS0.Px1.p1.1)\.
- Anthropic \(2026\)AnthropicIntroducing Claude Opus 5\.Note:Anthropic BlogExternal Links:[Link](https://www.anthropic.com/news/claude-opus-5)Cited by:[§4\.1](https://arxiv.org/html/2610.26924#S4.SS1.SSS0.Px3.p1.1)\.
- Chenet al\.\(2026\)A\. Chenet al\.DIVE: Scaling Diversity in Agentic Task Synthesis for Generalizable Tool Use\.arXiv preprint arXiv:2603\.11076\.External Links:[Link](https://arxiv.org/abs/2603.11076)Cited by:[§1](https://arxiv.org/html/2610.26924#S1.p2.1),[§5](https://arxiv.org/html/2610.26924#S5.SS0.SSS0.Px2.p1.1)\.
- DeepSeek \(2026\)DeepSeekDeepSeek\-V4 preview: entering the era of affordable million\-token context\.Note:DeepSeek BlogExternal Links:[Link](https://deepseek.com/en/news/v4-preview/)Cited by:[§4\.1](https://arxiv.org/html/2610.26924#S4.SS1.SSS0.Px3.p1.1)\.
- Doshi \(2026a\)T\. DoshiIntroducing Gemini 3\.6 Flash, 3\.5 Flash\-Lite, and 3\.5 Flash Cyber\.Note:Google BlogExternal Links:[Link](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-6-flash-3-5-flash-lite-3-5-flash-cyber/)Cited by:[§4\.1](https://arxiv.org/html/2610.26924#S4.SS1.SSS0.Px3.p1.1)\.
- Doshi \(2026b\)T\. DoshiIntroducing Gemini 3\.7 Flash\.Note:Google BlogExternal Links:[Link](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-3-7-flash/)Cited by:[§4\.1](https://arxiv.org/html/2610.26924#S4.SS1.SSS0.Px3.p1.1)\.
- Egget al\.\(2025\)A\. Egget al\.DABstep: Data Agent Benchmark for Multi\-step Reasoning\.arXiv preprint arXiv:2506\.23719\.External Links:[Link](https://arxiv.org/abs/2506.23719)Cited by:[§4\.1](https://arxiv.org/html/2610.26924#S4.SS1.SSS0.Px2.p1.1)\.
- Fanet al\.\(2026\)Z\. Fanet al\.Toward Scalable Terminal Task Synthesis via Skill Graphs\.arXiv preprint arXiv:2604\.25727\.External Links:[Link](https://arxiv.org/abs/2604.25727)Cited by:[§5](https://arxiv.org/html/2610.26924#S5.SS0.SSS0.Px1.p1.1)\.
- Honget al\.\(2024\)S\. Honget al\.Data Interpreter: An LLM Agent For Data Science\.arXiv preprint arXiv:2402\.18679\.External Links:[Link](https://arxiv.org/abs/2402.18679)Cited by:[§1](https://arxiv.org/html/2610.26924#S1.p1.1)\.
- Liet al\.\(2026a\)Y\. Liet al\.JobBench: Aligning Agent Work With Human Will\.arXiv preprint arXiv:2605\.26329\.External Links:[Link](https://arxiv.org/abs/2605.26329)Cited by:[§4\.1](https://arxiv.org/html/2610.26924#S4.SS1.SSS0.Px2.p1.1)\.
- Liet al\.\(2026b\)Z\. Liet al\.Recursive Synthesis for Long\-Horizon Terminal Tasks\.arXiv preprint arXiv:2608\.05466\.External Links:[Link](https://arxiv.org/abs/2608.05466)Cited by:[§5](https://arxiv.org/html/2610.26924#S5.SS0.SSS0.Px3.p1.1)\.
- Lianget al\.\(2026\)Y\. Lianget al\.SkillNet: Create, Evaluate, and Connect AI Skills\.arXiv preprint arXiv:2603\.04448\.External Links:[Link](https://arxiv.org/abs/2603.04448v3)Cited by:[§5](https://arxiv.org/html/2610.26924#S5.SS0.SSS0.Px1.p1.1)\.
- Liuet al\.\(2025\)J\. Liu, Y\. Li, C\. Zhang, J\. Li, A\. Chen, K\. Ji, W\. Cheng, Z\. Wu, C\. Du, Q\. Xu, J\. Song, Z\. Zhu, W\. Chen, P\. Zhao, and J\. HeWebExplorer: Explore and Evolve for Training Long\-Horizon Web Agents\.arXiv preprint arXiv:2509\.06501\.External Links:[Link](https://arxiv.org/abs/2509.06501)Cited by:[§5](https://arxiv.org/html/2610.26924#S5.SS0.SSS0.Px2.p1.1)\.
- Maiet al\.\(2025\)S\. Maiet al\.CuES: A Curiosity\-driven and Environment\-grounded Synthesis Framework for Agentic RL\.arXiv preprint arXiv:2512\.01311\.External Links:[Link](https://arxiv.org/abs/2512.01311)Cited by:[§1](https://arxiv.org/html/2610.26924#S1.p2.1),[§5](https://arxiv.org/html/2610.26924#S5.SS0.SSS0.Px2.p1.1)\.
- McInneset al\.\(2018\)L\. McInnes, J\. Healy, and J\. MelvilleUMAP: Uniform Manifold Approximation and Projection for Dimension Reduction\.arXiv preprint arXiv:1802\.03426\.External Links:[Link](https://arxiv.org/abs/1802.03426)Cited by:[§4\.4](https://arxiv.org/html/2610.26924#S4.SS4.p2.1)\.
- Moonshot AI \(2026\)Moonshot AIKimi K3: open frontier intelligence\.Note:Kimi BlogExternal Links:[Link](https://www.kimi.com/en/blog/kimi-k3)Cited by:[§4\.1](https://arxiv.org/html/2610.26924#S4.SS1.SSS0.Px3.p1.1)\.
- \[17\]OpenAICodex CLI\.Note:Official software repositoryAccessed September 17, 2026External Links:[Link](https://github.com/openai/codex)Cited by:[§1](https://arxiv.org/html/2610.26924#S1.p1.1)\.
- OpenAI \(2026\)OpenAIGPT\-5\.6: frontier intelligence that scales with your ambition\.Note:OpenAI BlogExternal Links:[Link](https://openai.com/index/gpt-5-6/)Cited by:[§4\.1](https://arxiv.org/html/2610.26924#S4.SS1.SSS0.Px3.p1.1)\.
- Qiaoet al\.\(2026\)S\. Qiaoet al\.Scaling Generalist Data\-Analytic Agents\.InICLR,External Links:[Link](https://arxiv.org/html/2509.25084v3)Cited by:[§1](https://arxiv.org/html/2610.26924#S1.p2.1),[§3\.1](https://arxiv.org/html/2610.26924#S3.SS1.p2.1),[§4\.1](https://arxiv.org/html/2610.26924#S4.SS1.SSS0.Px3.p1.1),[§5](https://arxiv.org/html/2610.26924#S5.SS0.SSS0.Px1.p1.1)\.
- Qwen Team \(2026a\)Qwen TeamQwen3\.6\-27B: flagship\-level coding in a 27B dense model\.External Links:[Link](https://qwen.ai/blog?id=qwen3.6-27b)Cited by:[§4\.1](https://arxiv.org/html/2610.26924#S4.SS1.SSS0.Px1.p1.1)\.
- Qwen Team \(2026b\)Qwen TeamQwen3\.6\-35B\-A3B: agentic coding power, now open to all\.External Links:[Link](https://qwen.ai/blog?id=qwen3.6-35b-a3b)Cited by:[§4\.1](https://arxiv.org/html/2610.26924#S4.SS1.SSS0.Px1.p1.1)\.
- Ramrakhyaet al\.\(2025\)R\. Ramrakhya, A\. Szot, O\. Attia, Y\. Yang, A\. Nguyen, B\. Mazoure, Z\. Gan, H\. Agrawal, and A\. ToshevScaling Synthetic Task Generation for Agents via Exploration\.arXiv preprint arXiv:2509\.25047\.External Links:[Link](https://arxiv.org/abs/2509.25047)Cited by:[§5](https://arxiv.org/html/2610.26924#S5.SS0.SSS0.Px2.p1.1)\.
- Shiet al\.\(2025\)D\. Shiet al\.TaskCraft: Automated Generation of Agentic Tasks\.arXiv preprint arXiv:2506\.10055\.External Links:[Link](https://arxiv.org/abs/2506.10055)Cited by:[§1](https://arxiv.org/html/2610.26924#S1.p2.1),[§5](https://arxiv.org/html/2610.26924#S5.SS0.SSS0.Px3.p1.1)\.
- Sunet al\.\(2024\)Q\. Sunet al\.OS\-Genesis: Automating GUI Agent Trajectory Construction via Reverse Task Synthesis\.arXiv preprint arXiv:2412\.19723\.External Links:[Link](https://arxiv.org/abs/2412.19723)Cited by:[§5](https://arxiv.org/html/2610.26924#S5.SS0.SSS0.Px2.p1.1)\.
- Sunet al\.\(2026\)Z\. Sunet al\.AgenticDataBench: A Comprehensive Benchmark for Data Agents\.arXiv preprint arXiv:2607\.01647\.External Links:[Link](https://arxiv.org/abs/2607.01647)Cited by:[§5](https://arxiv.org/html/2610.26924#S5.SS0.SSS0.Px1.p1.1)\.
- Tamkinet al\.\(2024\)A\. Tamkinet al\.Clio: Privacy\-Preserving Insights into Real\-World AI Use\.arXiv preprint arXiv:2412\.13678\.External Links:[Link](https://arxiv.org/abs/2412.13678)Cited by:[§4\.4](https://arxiv.org/html/2610.26924#S4.SS4.p1.1)\.
- Wanget al\.\(2025\)X\. Wang, B\. Li, Y\. Song, F\. F\. Xu, X\. Tang,et al\.OpenHands: An Open Platform for AI Software Developers as Generalist Agents\.InICLR,External Links:[Link](https://arxiv.org/abs/2407.16741)Cited by:[§1](https://arxiv.org/html/2610.26924#S1.p1.1)\.
- Xieet al\.\(2025\)J\. Xieet al\.AgentSynth: Scalable Task Generation for Generalist Computer\-Use Agents\.arXiv preprint arXiv:2506\.14205\.External Links:[Link](https://arxiv.org/abs/2506.14205)Cited by:[§1](https://arxiv.org/html/2610.26924#S1.p2.1),[§5](https://arxiv.org/html/2610.26924#S5.SS0.SSS0.Px3.p1.1)\.
- Yaoet al\.\(2023\)S\. Yao, J\. Zhao, D\. Yu, N\. Du, I\. Shafran, K\. Narasimhan, and Y\. CaoReAct: Synergizing Reasoning and Acting in Language Models\.InICLR,External Links:[Link](https://arxiv.org/abs/2210.03629)Cited by:[§1](https://arxiv.org/html/2610.26924#S1.p1.1)\.
- Z\.ai \(2026\)Z\.aiGLM\-5\.2\.Note:Z\.ai BlogExternal Links:[Link](https://z.ai/blog/glm-5.2)Cited by:[§4\.1](https://arxiv.org/html/2610.26924#S4.SS1.SSS0.Px3.p1.1)\.
- \[31\]M\. Zechner and contributorsPi Coding Agent\.Note:Official software repositoryAccessed September 17, 2026External Links:[Link](https://github.com/badlogic/pi-mono)Cited by:[§1](https://arxiv.org/html/2610.26924#S1.p1.1)\.
- Zhanget al\.\(2025\)S\. Zhanget al\.DeepAnalyze: Agentic Large Language Models for Autonomous Data Science\.arXiv preprint arXiv:2510\.16872\.External Links:[Link](https://arxiv.org/abs/2510.16872)Cited by:[§1](https://arxiv.org/html/2610.26924#S1.p1.1),[§3\.1](https://arxiv.org/html/2610.26924#S3.SS1.p2.1),[§5](https://arxiv.org/html/2610.26924#S5.SS0.SSS0.Px1.p1.1)\.
- Zhanget al\.\(2025\)Y\. Zhang, M\. Li, D\. Long, X\. Zhang, H\. Lin, B\. Yang, P\. Xie, A\. Yang, D\. Liu, J\. Lin, F\. Huang, and J\. ZhouQwen3 Embedding: Advancing Text Embedding and Reranking Through Foundation Models\.arXiv preprint arXiv:2506\.05176\.External Links:[Link](https://arxiv.org/abs/2506.05176)Cited by:[§4\.4](https://arxiv.org/html/2610.26924#S4.SS4.p1.1)\.
- Zhenget al\.\(2024\)Y\. Zheng, R\. Zhang, J\. Zhang, Y\. Ye, and Z\. LuoLlamaFactory: unified efficient fine\-tuning of 100\+ language models\.InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics \(Volume 3: System Demonstrations\),pp\. 400–410\.External Links:[Document](https://dx.doi.org/10.18653/v1/2024.acl-demos.38),[Link](https://aclanthology.org/2024.acl-demos.38/)Cited by:[§4\.1](https://arxiv.org/html/2610.26924#S4.SS1.SSS0.Px4.p1.1)\.

## Appendix ARideBench Construction

RideBench was developed internally by a company to evaluate business analysis in ride\-hailing operations\. It uses a simulator that models interactions among passenger demand, driver supply, and platform policies\. The simulator first establishes a stable operating state\. Scripted events then alter selected parameters, allowing their effects to propagate through the simulated business\. The resulting data capture changes in operational metrics under known interventions\.

The benchmark covers 11 scenarios involving external events and platform strategies, including competitive pricing, subsidies, driver shortages, and extreme weather\. Some scenarios introduce a single event, while others combine interventions to support more complex attribution and strategy comparisons\. Agents receive order records and daily driver and passenger tables\. Internal simulation variables and event logs are retained separately to support reference analysis and evaluation\.

The 89 tasks are organized into three difficulty levels according to the required analysis and scenario complexity\. The 56 easy tasks focus on metric computation, anomaly detection, and basic attribution\. The 23 medium tasks require more detailed attribution or inference about external events\. The 10 hard tasks emphasize operational strategy comparison and complex attribution\. Together, these tasks assess whether agents can connect observed business changes to their underlying drivers\.

## Appendix BCase Studies

### B\.1Workspace Evolution

Workspace evolution turns intermediate findings into both reusable analytical assets and grounds for subsequent questions\. Figure[7](https://arxiv.org/html/2610.26924#A2.F7)illustrates this process through a hotel pricing example\. Two branches characterize different dimensions of the same booking records\. Their composition then tests whether the relationships found on each dimension persist when the other is taken into account\.

Figure 7:Workspace evolution in hotel pricing analysis\.A–C denote selected evolution nodes\. Arrows show workspace inheritance and subsequent task assembly\. Descriptive filenames are used for readability\.##### Initial workspace\.

The workspace containshotel\_bookings\.csv, with 119,390 booking records for a City Hotel and a Resort Hotel, with arrival dates spanning July 2015 to August 2017\. Available fields include the number of days between booking and arrival, the average daily room rate \(ADR\), hotel identity, and cancellation status\. The initial snapshot also includesdata\_profile\.json\. The execution environment is represented by the task package’sDockerfile\. We follow the two pricing branches and their composition, denoted A, B, and C in the figure\.

##### Node A: discovering the relationship with booking lead time\.

The first branch groups room rates by booking lead time\. Among completed stays with positive room rates and stay lengths, the Resort Hotel exhibits an inverted U: median ADR rises from EUR 61 for bookings made 1–7 days before arrival to EUR 90 for bookings made 121–180 days before arrival, then declines at longer lead times\. The City Hotel appears comparatively flat, with a range of only EUR 8\.1 across lead time bins from 0 to 365 days\. The workspace retainslead\_time\_analysis\.py, an enriched tablecompleted\_stays\.csv, and grouped summaries inlead\_time\_prices\.csv\. It also establishes the cancellation filter and lead time bins used in the subsequent analysis\.

##### Node B: identifying the seasonal context\.

A separate branch constructs arrival dates and examines monthly price patterns\. In the complete calendar year of 2016, median ADR peaks in August for the Resort Hotel and September for the City Hotel\. The same peak months remain when canceled bookings are excluded\. This branch addsseasonal\_analysis\.py, which defines the calendar mapping, together withmonthly\_prices\.csvandprice\_peaks\.json\. Its findings identify specific months in which to revisit Node A’s pooled relationships\.

##### Node C: composing the findings into a new question\.

The composition node inherits both branches’ scripts and result tables\. Its recorded objective explicitly connects their findings: does the Resort Hotel’s lead time premium persist in August, and does the City Hotel’s apparently flat relationship persist in September? The executor reuses Node A’s filtering and lead time bins together with Node B’s calendar definitions to construct a joint grid of lead time and arrival month across all available years\. The resulting analysis changes the interpretation of both pooled patterns\. In August, the Resort Hotel’s median ADR is EUR 199 for the 1–7 day bin but EUR 172 for the 121–180 day bin, reversing the corresponding pooled comparison\. For the City Hotel, the range across the same 0–365 day bins expands from EUR 8\.1 when months are pooled to EUR 42\.2 in September\. The successor workspace addsjoint\_pricing\_analysis\.py, the joint gridlead\_time\_month\_prices\.csv, and tests inprice\_interactions\.csv, making these conditional findings available for further evolution\.

##### From evolved workspace to an independent task\.

The assembled task asks a solver to analyze how booking lead time and arrival season jointly relate to room rates, assess whether their relationships can be treated separately, and compare the two hotels in a Markdown report\. The solver receives the original booking file, while construction scripts, intermediate tables, and discovered conclusions are withheld\. The dependencies established during evolution thus become analytical work that the solver must reconstruct\. This case illustrates how composition goes beyond collecting separate results: a finding from one branch specifies where to interrogate another, producing a question and a conditional explanation that neither branch had established alone\.

### B\.2Rubric Synthesis and Validation

The dual\-evidence verification process turns task requirements and analytical evidence into criteria that can be checked against a deliverable\. A coffee retail task illustrates how validation separates the analytical requirement from a conclusion that depends on a particular choice of analysis population\. The task usesCoffee Shop Sales\.xlsx, containing 149,116 sales rows from three stores, and requests a Markdown report on product co\-occurrence and bundle recommendations\. A shopping basket is defined by transaction date, time, and store\.

##### From evidence to candidate criteria\.

Evolution evidence from the workspace evolution record supplies verified findings about basket composition and product associations\. Solution evidence from two independent reference trajectories is organized into evidence cards linking operations, computed values, and report conclusions\. The rubric generator produces ten candidate criteria covering substantive conclusions, basket construction, association measures, recommendations, and report completeness\. One criterion requires distinguishing frequent co\-occurrence from strong association\. Its initial satisfaction rule also requires the report to conclude that Bakery and Tea have lift greater than one \(Table[4](https://arxiv.org/html/2610.26924#A2.T4)\)\.

Table 4:Rubric refinement for coffee basket analysis\. Criterion text is condensed and translated from the recorded rubric\.
##### Validation establishes the scope of the expected conclusion\.

The rubric validator checks the referenced fields, the criterion’s observability in the reports, and its conclusion against the workbook\. For categoriesAAandBB, lift isnA​B​N/\(nA​nB\)n\_\{AB\}N/\(n\_\{A\}n\_\{B\}\), whereNNis the number of baskets,nAn\_\{A\}andnBn\_\{B\}count baskets containing each category, andnA​Bn\_\{AB\}counts baskets containing both\. All counts refer to the same basket population\. Recomputing this quantity shows why the initial requirement is too specific: Bakery \+ Tea has lift below one over all baskets but above one after restricting to baskets containing multiple categories\. The two reference reports use these different populations\. The validation record therefore revises the criterion to retain the distinction between frequency and association while removing the required direction for this particular pair\. The revised criterion passes the subsequent validation check\.

##### Preserving a substantive scoring requirement\.

The final criterion retains a substantive test: the report must distinguish frequent co\-occurrence from positive association using both frequency and lift\. Listing popular combinations alone is insufficient\.

## Appendix CModel Behavior Before and After Training

We compare Qwen3\.6\-27B and DataPraxis\-27B on the same 65 JobBench tasks across 35 occupations\. We examine two observable behaviors: organizing work into explicit subgoals and checking generated outputs\.

##### More explicit task organization\.

We identify explicit subgoals from successful task creation records for analysis or deliverable construction, excluding final verification goals\. The number of tasks with explicit subgoals increases from 47 to 65 after training \(Figure[8](https://arxiv.org/html/2610.26924#A3.F8)\(a\)\)\. Among the 47 tasks with subgoals for both models, DataPraxis\-27B introduces them after fewer tool calls in 44 tasks, excluding task management calls\. The trained model therefore makes intermediate objectives explicit more consistently, with earlier introduction in most tasks where both models use subgoals\.

##### More frequent self\-verification\.

We examine self\-verification through output inspection: tool calls that reopen or parse generated documents, spreadsheets, or data files to inspect their structure or contents\. Checking only whether a file exists does not count\. We compute inspection attempts per 100 nonmanagement tool calls for each task and average these rates equally across tasks\. The mean increases from 6\.64 to 10\.36 per 100 tool calls, excluding task management calls \(Figure[8](https://arxiv.org/html/2610.26924#A3.F8)\(b\)\)\. This indicates that inspecting generated outputs occupies a larger share of tool use after training\.

Figure 8:Task organization and output inspection on JobBench\.\(a\) Number of tasks with explicit subgoals, expressed as a percentage of all 65 matched tasks\. Final verification goals are excluded\. \(b\) Mean output inspection attempts per 100 nonmanagement tool calls, with 95% bootstrap intervals over tasks\. Output inspection is an observable proxy for self\-verification\. Both panels compare Qwen3\.6\-27B with DataPraxis\-27B on the same task set\.
### C\.1Illustrative Cases of Behavioral Changes

We examine two tasks to illustrate the behaviors measured above\. Each case compares Qwen3\.6\-27B and DataPraxis\-27B on the same task: a VPN incident investigation illustrates explicit task decomposition, and workforce planning illustrates output inspection followed by revision \(Figure[9](https://arxiv.org/html/2610.26924#A3.F9)\)\.

##### Organizing a complex request into explicit subgoals\.

The VPN task requires reconciling gateway logs, incident records, and helpdesk tickets, then producing a report, a CSV containing two change requests, and a dashboard database\. Qwen3\.6\-27B reads the sources and writes a script that generates all three deliverables, without registering explicit subgoals\. After an initial inspection, DataPraxis\-27B records four substantive subgoals: analyze the sources, prepare the reconciliation report, prepare the change requests, and build the dashboard\. These goals retain requirements that matter to each output\. For example, the change request goal specifies session and incident identifiers as evidence and requires the DNS rollback plan to account for tunnel routing discrepancies\. The model then works through source analysis, report construction, change requests, and dashboard construction, updating the corresponding goal statuses as it proceeds\. This makes the task’s requirements explicit at the level of individual work stages, providing a concrete example of the increased subgoal coverage in Figure[8](https://arxiv.org/html/2610.26924#A3.F8)\(a\)\.

Figure 9:Paired cases illustrating the two aggregate behavior patterns\.\(a\) Explicit subgoals organize VPN incident analysis and its deliverables\. \(b\) Inspecting workbook contents reveals an omission and guides its repair\. Text summarizes recorded operations\.
##### Using output contents to guide revision\.

In the workforce planning task, the models analyze employee turnover and screen applicants, producing a report and a workbook with a license follow\-up tracker\. The trajectories show how output inspection informs revision\. Qwen3\.6\-27B inspects document headings, worksheet names, and worksheet dimensions\. DataPraxis\-27B additionally reads worksheet rows and summary values\. Its draft summary lists four applicants requiring license follow\-up, but the tracker contains only one applicant record\. The subsequent edit fixes the row indexing used to populate the tracker, preventing instruction text from overwriting candidate entries\. After regenerating the workbook, the model reads the tracker again and confirms all four applicant IDs\. Both models ultimately deliver trackers containing these four applicants\. The distinctive evidence is the trained model’s observed sequence of content inspection, targeted repair, and confirmation within its own trajectory\. This sequence illustrates how output inspection, the behavior measured in Figure[8](https://arxiv.org/html/2610.26924#A3.F8)\(b\), can lead to a concrete correction before delivery\.

## Appendix DLimitations

DataPraxis relies on seed workspaces with sufficient data complexity and analytical scope to support continued exploration\. Simple files with few variables or limited relationships may offer fewer opportunities to uncover deeper questions through workspace evolution\. In addition, the difficulty of synthesized tasks and the quality of solution trajectories depend on the capabilities of the teacher models\. Their ability to identify meaningful analytical directions and execute the required analyses shapes the resulting training data\.

## Appendix EAgent Prompts

These condensed English templates retain the agents’ core instructions and structured outputs\. Angle brackets denote runtime inputs or values to fill in\. A vertical bar separates allowed values\. Use JSON null rather than a quoted string where specified, and empty lists when no entries apply\. Each agent is shown once, with the Director’s output selected by its operation mode\.

### E\.1Profiler

You are a data profiler\. Inspect the initial data and research the relevant domain to produce a structured profile for subsequent exploration\. No analytical objective has been assigned yet\.

Domain context: <task\_description\>

Documentation: <briefing\_files\>

Search and fetch tools: <search\_tool\>, <fetch\_tool\>

Output path: <output\_path\>

Inspect the current workspace using scripts and suitable readers\. Consult documentation before inferring field meanings\. Identify artifacts, entity keys, explicit and implicit relationships, and the valuable analytical questions these relationships support\. For databases, inspect schemas and basic size information without performing downstream analyses\.

Research professional activities, role descriptions, analytical frameworks, and methods using the supplied search and fetch tools\. Use this research to broaden the domain’s work types and methods\. Skip online research only if the tools are unavailable\. Keep research findings in the domain profile\. Do not import external numerical benchmarks or metric definitions into the workspace profile\.

List atomic professional work types that can be independently performed and checked and remain meaningful for other datasets in the same domain\. Separately list methods with domain concepts and their reasoning mechanisms, not generic descriptive statistics\. Do not prescribe pairings between work types and methods\.

Record locally observed prerequisites as usage and silent analytical pitfalls as hazard\. Do not invent issues\. Use Python to write only data\_profile\.json to <output\_path\>, using the following structure\. The artifact note is optional\.

\{

"workspace\_profile": \{

"overview": "<2\-4 sentences describing the data and scale\>",

"artifacts": \[\{"ref": "<file or table\>", "role": "<contents\>",

"note": "<optional loading or usage note\>"\}\],

"relations": \["<objects, joining keys, and analytical value\>"\],

"observations": \[\{"kind": "usage\|hazard", "note": "<observation\>"\}\]

\},

"domain\_profile": \{

"work\_modes": \[\{"id": "<snake\_case\_id\>", "intent": "<purpose\>"\}\],

"domain\_methods": \[\{"name": "<method\>", "logic": "<reasoning mechanism\>"\}\]

\}

\}

### E\.2Director

You are the exploration director\. Plan valuable new analytical questions from the exploration graph\. Follow the supplied expansion or composition instructions\.

Domain context and profile: <source\_task\_hint\>

Candidate parents: <candidate\_list\>

Exploration graph: <tree\_overview\>

Depth and limits: <depth\_status\>, <max\_depth\>, <per\_call\_cap\>

Operation instructions: <operator\_menu\>, <required\_operator\_note\>

Composition limit: <max\_compositions\>

Output path: <output\_path\>

Read the full graph to avoid repeating existing questions\. Favor substantive questions with practical or research value and support in the available data\. Specify what to investigate and why, without calculation steps, formulas, expected numbers, or instructions for avoiding data pitfalls\.

For expansion, choose one eligible parent and propose up to <per\_call\_cap\> distinct directions\. At the data root, derive initial questions from the profile\. Otherwise identify the specific verified finding each direction depends on\. A merely related topic is insufficient\. Assign an allowed operator and a work\_mode to every direction\. Work types are an open set, not a coverage quota\. If no candidate supports a valuable new direction, set can\_expand to false, parent\_node\_id to null, and branches to an empty list\.

For composition, propose up to <max\_compositions\> natural questions, each requiring at least two verified sources\. Explain their relationship and what new conclusion their combination could support\. Do not merely concatenate independent questions\. Keep the question in objective and the reasoning about source findings in divergence\_rationale\. Return an empty list if no meaningful composition exists\.

Use Python to write only director\_direction\.json to <output\_path\>\. Use the expansion structure below, or the composition structure when composition is requested\.

Expansion:

\{

"can\_expand": true,

"parent\_node\_id": "<eligible node ID, or null when stopping\>",

"branches": \[\{"next\_focus": "<question\>", "operator": "<allowed operator\>",

"depends\_on": "<parent finding, or empty at the data root\>",

"work\_mode": \{"id": "<work type\>", "intent": "<purpose\>"\},

"insight": "<why this direction is valuable\>"\}\]

\}

Composition:

\{

"operator": "composition",

"compositions": \[\{"source\_node\_ids": \["<verified ID\>", "<verified ID\>"\],

"relation": "<relationship\>", "objective": "<single question\>",

"divergence\_rationale": "<why multiple sources are needed\>"\}\],

"reasoning": "<rationale for the number of proposals\>"

\}

### E\.3Proposer

You are a goal proposer\. Translate the Director’s direction into a clear analytical task for the Executor\. Specify what to answer and deliver, not how to calculate it\.

Data profile: <data\_profile\>

Domain context: <source\_task\_hint\>

Verified predecessor findings: <history\_summary\>

Direction: <director\_direction\>

Operation instructions: <operator\_note\>

Output path: <output\_path\>

Understand the core question and write a self\-contained instruction describing the analytical setting, objects, question, and expected output\. Keep it at a moderate scale with typically one to three central conclusions that can be reliably executed and independently checked\. Do not prescribe a calculation recipe or supply the answer\.

Identify the specific predecessor finding on which the new objective depends\. Prepare context\_summary from history\_summary alone\. Include verified findings and their source nodes so that the Executor can reuse them directly\. Numerical facts must come from verified history\. The Director’s proposal is a direction for future work, not evidence of a result\. Do not perform the analysis yourself\.

Use Python to write only goal\_package\.json to <output\_path\>, using exactly this structure\.

\{

"current\_goal": \{

"goal\_text": "<setting, analytical question, and expected output\>",

"depends\_on": "<specific predecessor finding\>"

\},

"context\_summary": "<verified prior conclusions with source nodes\>"

\}

### E\.4Executor

Complete the assigned analysis and leave reusable assets for subsequent nodes\.

Goal: <goal\_text\>

Verified prior findings: <context\_summary\>

Workspace files: <workspace\_files\>

Data pitfalls: <data\_traps\>

Inherited scripts: <inherited\_scripts\>

Inherited artifacts: <inherited\_artifacts\>

Node index and output path: <round\_idx\>, <output\_path\>

Reuse or extend verified scripts and intermediate artifacts under sources/\. Compute from raw data when an inherited result is unavailable\. Write analyze\_node<round\_idx\>\.py as a self\-contained script that reproduces the key numerical evidence from persisted inputs, without manual steps or transient state\. Save new intermediate artifacts under generated/\.

Derive directional and quantitative claims from computed values\. If findings overturn an expectation, correct the script and rerun it\. Do not patch the result JSON while leaving contradictory code\. State conclusion as prose with its supporting numbers inline so subsequent nodes can reuse it directly\.

Write analysis\_log\_node<round\_idx\>\.md documenting the subproblems, assumptions and processing choices, calculation steps and intermediate values, changes prompted by the findings, and the evidence supporting each final claim\. Include both the script and log in generated\_files, together with reusable artifacts\.

Write execution\_result\.json to <output\_path\> with all fields below\. Set execution\_status to success or failed\. Use null for failure\_reason on success\. A successful conclusion must be nonempty prose, not a structured table\.

\{

"execution\_status": "success\|failed",

"observations": \["<finding with supporting values\>"\],

"methodology": "<analytical method and processing choices\>",

"conclusion": "<conclusion with supporting numbers inline\>",

"generated\_files": \["analyze\_node<round\_idx\>\.py",

"analysis\_log\_node<round\_idx\>\.md", "generated/<artifact\>"\],

"failure\_reason": null

\}

### E\.5Validator

You are an analysis validator\. Try to falsify the main conclusion fairly, without inventing objections\. Determine reliability and establish the verified conclusion\.

Goal: <goal\_text\>

Execution result: <execution\_result\_json\>

Workspace files: <workspace\_files\>

Output path: <output\_path\>

Check execution success, listed files, and substantive observations and conclusion\. Failure of any of these checks means unsupported with a null ground\_truth\. Do not rescue a failed execution by independently completing it\. Inspect the required script and analysis log\. Rerun the script to check independent reproducibility, which does not itself establish correctness\.

Identify the strongest plausible objection\. Trace claims to calculations and assumptions, check the appropriateness of methods, and confirm that the analysis answers the assigned question\. Judge the chosen analytical perspective on its own terms\.

Return supported if the main claim withstands scrutiny\. Return revised only after a bounded correction to the existing computation, such as repairing a formula or filter, and rerun the corrected script\. If a reliable correction requires new analysis, return unsupported\. Preserve sources/ and the original execution\_result\.json\.

Write ground\_truth in your own words with verified numbers inline\. Record unresolved concerns in issues, and inherited assumptions or intermediate artifacts in condition\_dependencies\. Use Python to save validation\_result\.json at <output\_path\> with the structure below\. Set ground\_truth to null for unsupported\. Include zero to three issues, using major, moderate, or minor severity\. For revised, revisions must identify script changes and the recomputed values\.

\{

"main\_claim": "supported\|revised\|unsupported",

"ground\_truth": "<verified prose conclusion, or null if unsupported\>",

"revisions": \["<correction and recomputed evidence\>"\],

"issues": \[\{"severity": "major\|moderate\|minor",

"description": "<specific issue\>"\}\],

"condition\_dependencies": \["<inherited assumption or artifact\>"\],

"summary": "<what was checked and whether the conclusion holds\>"

\}

### E\.6Verifier Generation

You are a read\-only rubric generation agent\. Derive criteria from the task, data, solving evidence, and candidate reference conclusions\. Reference candidates may be wrong and must not be treated as guaranteed truth\.

Instruction: <instruction\>

Data files: <data\_file\_paths\>

Evidence cards: <evidence\_cards\>

Reference candidates: <gt\_candidate\_rubrics\>

Use Read, Bash, Grep, and Glob without modifying files\. Read only supplied paths\. Inspect the task, data schema, evidence cards, and reference candidates\. Induce four to seven evaluation dimensions covering main conclusions, analytical methods, and presentation, with greatest importance given to the main conclusions\. Assess presentation from extracted text, not rendered pixels\.

Generate one to three criteria per dimension and at most ten overall\. Each criterion must test one observable concern with a justified expected outcome\. Drop correctness criteria whose expected outcome you cannot establish\. Do not accept opposite answers, mere self\-consistency, or answer presence as correctness\. Allow genuinely open answers justified by the task and data, and completeness checks for explicitly required presentation\.

Use filter for fixed primary conclusions and preference for method or presentation\. Label provenance honestly as gt or generated\. A downstream step caps gt criteria at 40 percent, dropping those with lowest confidence if exceeded\. Deduplicate across all sources and record removals\.

Return exactly one minified JSON object in the final reply, with the following fields\. Do not use Markdown fences or additional prose\. Tool output is not the final reply\. Use null for source\_field when no reference field applies\.

\{

"rubric\_id": "<ID\>", "instruction\_key": "<key\>",

"evaluation\_dimensions": \["<dimension\>"\],

"criteria": \[\{

"criterion\_id": "F01", "type": "filter\|preference",

"dimension": "<one evaluation dimension\>",

"criterion": "<declarative expected outcome\>",

"observable": "<evidence to inspect\>",

"satisfy": "<conditions for satisfying the criterion\>",

"violate": "<conditions for violating the criterion\>",

"confidence": 0\.0, "source": "gt\|generated",

"source\_field": "<ground\_truth field, or null\>",

"source\_note": "<reference conclusion or independently derived angle\>"

\}\],

"rubric\_warnings": \[\], "dedup\_notes": \["<removed duplicate\>"\]

\}

### E\.7Verifier Validation

You are a read\-only rubric validation agent\. Validate one criterion against the task, input data, solving evidence, and delivered output text\.

Criterion and task: <criterion\>, <instruction\>

Data files: <data\_file\_paths\>

Evidence: <evidence\_cards\>, <output\_files\_by\_trajectory\>

Use Read, Bash, Grep, and Glob without modifying files\. Read only supplied paths and never read ground\_truth files\. Recompute from input data to establish correctness, independently of agreement among trajectories\.

Check four angles\. Grounding checks whether referenced fields and concepts exist\. Observability checks whether supplied text and evidence reveal satisfaction or violation, excluding requirements that need rendered pixels\. Formulation checks one clear declarative requirement with meaningful satisfy and violate conditions\. Reject correctness clauses that accept opposite answers, mere self\-consistency, or only answer presence\. Allow justified open questions and explicitly required presentation completeness\. Leave neutral clauses that do not exhibit these defects unchanged\. Conclusion correctness checks whether the expected outcome holds, using as much recomputation as the claim requires\.

Distinguish verified, unverifiable, over\_specified, and refuted outcomes\. Unverifiable means the data cannot settle the claim, not that a feasible check was skipped\. An arbitrary demand for exact values or rankings is over\_specified\. Do not reject a criterion merely because all current trajectories satisfy it\.

Leave scoring\_tip empty unless equally valid methods reach the same primary conclusion and differ only in secondary details\. Pass only if grounding is supported or ambiguous, observable is observable or partially\_observable, well\_formed is well\_formed, and conclusion\_correct is verified or unverifiable\. Return exactly one minified JSON object with the following fields, without Markdown or additional prose\.

\{

"criterion\_id": "<ID\>",

"validation\_angles": \{

"grounding": \{

"assessment": "supported\|unsupported\|ambiguous", "reason": "<evidence\>",

"data\_evidence": \[\{"file": "<path\>", "sheet": "<sheet\>", "fields": \["<field\>"\]\}\]

\},

"observable": \{

"assessment": "observable\|partially\_observable\|unobservable", "reason": "<evidence\>"

\},

"well\_formed": \{

"assessment": "well\_formed\|ill\_formed", "reason": "<evidence\>", "issues": \[\]

\},

"conclusion\_correct": \{

"assessment": "verified\|unverifiable\|over\_specified\|refuted",

"reason": "<evidence\>", "verification": "<check, finding, and criterion claim\>"

\}

\},

"overall\_pass": true, "failed\_angles": \["<failed angle\>"\],

"scoring\_tip": "", "agent\_confidence": 0\.0

\}