Counterfactual Evolution of Multimodal Datasets via Visual Programming

[W1 & Q1] Lack of semantic question type analysis: There is no analysis of the distribution of question types such as counting, object attribute identification (e.g., color, texture), spatial relationship reasoning, OCR, or comparative questions. It is therefore unclear if the SCOPE framework has an inherent bias towards generating certain types of questions that are easier to represent programmatically (e.g., simple counting or attribute verification) while neglecting more complex semantic reasoning tasks. A thorough analysis of this semantic distribution is crucial for understanding the true diversity and potential biases of the benchmark. What's the distribution of question types such as counting, object attribute identification (e.g., color, texture), spatial relationship reasoning, OCR, or comparative questions?

[A1] Thank you for raising this important point. We fully agree that analyzing the semantic distribution of question types is crucial for assessing the diversity and potential biases of the benchmark. Our initial analysis focused primarily on structural diversity and reasoning complexity, as these are central to SCOPE’s programmatic evolution paradigm. However, we acknowledge the value of explicitly reporting semantic question-type coverage.

To address this, we performed an additional categorization of SCOPE-Test questions into major semantic types commonly used in multimodal reasoning benchmarks: counting, object attribute identification (color, texture, shape), spatial relationship reasoning, OCR-based reasoning, and comparative reasoning. The distribution is as follows:

This analysis demonstrates that SCOPE-Test is not dominated by trivial tasks such as simple counting or single-attribute queries. On the contrary, nearly half of the questions involve complex reasoning—including comparative, multi-hop, and spatial queries—while OCR-based tasks also constitute a substantial proportion, requiring symbolic reasoning and visual-text integration.

Furthermore, because SCOPE’s evolution strategies operate at the programmatic level, semantic diversity naturally increases across evolution rounds as reasoning paths expand and cross-instance composition introduces multi-faceted logic. Importantly, the framework remains flexible: if future benchmarks require stronger representation of specific semantic categories, targeted function additions or evolution heuristics can easily address this without redesigning the architecture.

Additionally, we also evaluated diversity in the question space by measuring distributional differences using Maximum Mean Discrepancy (MMD). Specifically, we compared the QA distribution under SCOPE with two baselines: VLB and Provision. Our results show that SCOPE achieves a significantly higher MMD value (0.38) compared to VLB (0.15) and Provision (0.18), indicating that SCOPE's QA outputs are farther from the baseline distributions and thus occupy a more uniform and dispersed semantic space across reasoning categories. A larger MMD signifies greater divergence from the baseline distributions, demonstrating that SCOPE generates a structurally and semantically more varied QA set overall.

[W2 & Q2] Constrained by the expressiveness of the API library and the proprietary generator model: The framework's ability to generate diverse reasoning paths is fundamentally limited by the expressiveness of its predefined API library and the proprietary generator model. Complex reasoning that cannot be decomposed into the provided functions (e.g., understanding abstract concepts, social interactions, or complex causality) is implicitly out of scope. While the appendix lists the API, a discussion in the main paper about its limitations, the design principles behind it, and the potential for extension would be beneficial. Does training on SCOPE improve model performance on rich-knowledge benchmarks like MMMU?

[A2] Thank you for this insightful observation.

First, SCOPE’s design builds upon the established visual programming paradigm introduced by frameworks such as ViperGPT, Visual Programming (VISPROG), and De-fine, which have demonstrated that programmatic reasoning with modular APIs can generalize across a wide range of multimodal tasks—well beyond classical VQA. For example, ViperGPT has successfully applied executable programs to visual grounding, image QA, video QA, multi-image comparison, symbolic math, and knowledge-augmented queries without task-specific retraining. Similarly, VISPROG and De-fine show that code-driven pipelines enable compositional reasoning, iterative refinement, and improved robustness across diverse domains. These foundations give SCOPE a strong theoretical basis for generalizability.

Importantly, for all current benchmarks, we do not modify the existing API or introduce new functions—the rich function set inherited from ViperGPT is sufficient to support tasks spanning visual reasoning, mathematical problem-solving (e.g., MathVista), knowledge-intensive QA (e.g., MMMU), and OCR-based document understanding (e.g., DocVQA). Thus, the current implementation already covers a wide range of reasoning capabilities without additional engineering overhead. To further validate both generalization and extensibility, we conducted experiments on these four diverse benchmarks. The results are summarized below:

These results show that SCOPE consistently improves reasoning accuracy across diverse domains, outperforming VLB by up to +1.9 points. This demonstrates that SCOPE not only adapts to knowledge-intensive benchmarks like MMMU but also scales to tasks requiring OCR, symbolic reasoning, and domain-specific interpretation, confirming both its generalizability and practical effectiveness.

At the same time, SCOPE remains inherently extensible. If future benchmarks require handling concepts beyond the existing API (e.g., domain-specific logic or abstract causal reasoning), new functions can be seamlessly integrated into the library without redesigning templates, prompt structures, or scene graphs, nor retraining the underlying models. This modularity ensures that complexity is localized and controlled, rather than requiring end-to-end system changes.

Finally, to address your question, our answer is: yes, training on SCOPE can improve model performance on rich-knowledge benchmarks such as MMMU. This is because SCOPE leverages external APIs during evolution, effectively distilling tool- and model-specific knowledge into the data, thereby enhancing the model’s reasoning and knowledge capabilities. SCOPE’s program-based paradigm offers interpretability, controllability, and modular extensibility, making it particularly effective for complex, multi-step reasoning tasks.

Dear Reviewer,

I hope this message finds you well. As the discussion period is nearing its end with less than three days remaining, I wanted to ensure we have addressed all your concerns satisfactorily. If there are any additional points or feedback you'd like us to consider, please let us know. Your insights are invaluable to us, and we're eager to address any remaining issues to improve our work.

Thank you for your time and effort in reviewing our paper.

[W1 & Q1] The concerns are about clarity, including the need for a more specific introduction that clearly states the work focuses on VQA tasks, clarifies whether the dataset is for pre-training or post-training, and provides details on real vs. synthetic data and the quantifiable gains achieved.

[A1] We thank the reviewer for the feedback and clarify the main concerns. Our introduction already states the motivation: addressing the growing mismatch between dataset evolution and model advancement—a problem that cannot be solved by simply enlarging pre-training data. We will further improve clarity by summarizing key contributions upfront. Regarding data composition, the Appendix provides full details, and we will add a concise summary in the main text to clarify that only the initial dataset is real, while all evolutionary stages are synthetic, along with quantifiable gains. SCOPE is a general paradigm applicable to both pre-training and post-training, not restricted to either. Finally, SCOPE is not limited to VQA; as a Visual Programming-based approach, it supports a broad range of multimodal tasks (e.g., video QA, image editing, multi-image reasoning).

[W2] The novelty of the paper from the methodology is not much. A similar dataset creation approach (or the use of VLM programs) has already been studied.

[A2] We would like to clarify that our contribution does not lie in proposing Visual Programming itself or minor modifications of it. Instead, we introduce a novel data evolution algorithm that enables counterfactual editing of reasoning steps. To achieve this, we are the first to align reasoning steps with code blocks in Visual Programming, allowing intervention at the structural or variable level to alter reasoning paths—a capability not present in prior work. Furthermore, we note that several cited works, such as VisProg and ViperGPT, are not dataset creation approaches. Our method fundamentally differs by leveraging code-level interventions to generate evolved datasets for enhancing reasoning, which is the core novelty of SCOPE.

[W3 & Q3] The concerns focus on the necessity and scalability of program-based data generation versus simpler approaches, questioning whether the added complexity and counterfactual modifications are justified given strong existing models and large-scale web data alternatives.

[A3] In fact, SCOPE is designed to enable controllable, interpretable evolution of reasoning steps, not merely to enlarge datasets or match saturated benchmarks. This is important because counterfactually editing reasoning paths creates new data distributions and reasoning challenges that web-scale datasets and existing benchmarks do not capture. Visual Programming is the most effective tool for this, as it allows fine-grained structural intervention—beyond what templates or scene graphs can achieve. Regarding scalability, I’m certain this approach is quite scalable for web-scale data by generating initial questions and programs and then applying SCOPE evolution, similar to VLB or Provision. Finally, we compared SCOPE-generated challenging samples with GPT-augmented ones and found that SCOPE yields examples significantly harder even for GPT itself, demonstrating the necessity of structured program-based evolution over simple prompt-based generation.

As for the question 3, current MLLM training pipelines are typically multi-stage, combining large-scale pre-training on web data with subsequent fine-tuning on higher-quality, task-specific datasets. For instance, Qwen2.5-VL describes a three-stage process (Sec. 2.2.2), and InternVL2.5 reports two stages (Table 3). Our method, SCOPE, is primarily designed for the fine-tuning stage, where curated data are already of higher quality than raw web-scale data. SCOPE aims to further enhance this data through counterfactual reasoning-step evolution, improving controllability and diversity beyond what web-scale pre-training can offer.

Contrary to the concern, SCOPE is not inherently incompatible with web-scale data. Many pre-training tasks—such as image captioning or OCR—have already been shown to be representable in programmatic form (e.g., ViperGPT and Visual Programming works). Therefore, applying SCOPE to evolve web-scale datasets is technically feasible. Finally, we stress that scaling up data size and improving data quality are orthogonal dimensions; SCOPE targets the latter, which remains critical even when training extremely large models.

[W4 & Q4] The related work section needs to be revised.

[A4] We will consider revising the Related Work section and adding some relevant citations as suggested. However, we note that image-modification is not the core aspect of our approach; in SCOPE it is used only as one of several tools, so our discussion focuses instead on Visual Programming and counterfactual reasoning, which are more central to our contribution. Additionally, our work is built on ViperGPT, we are confident that our discussion of ViperGPT is sufficiently detailed.

[W5] The concerns are about adding concrete details in the dataset and methodology section.

[A5] We would like to clarify that the requested information is already provided in the submission, although primarily organized in the Appendix for readability and space considerations. Specifically, the raw VL dataset statistics and baseline sample details are presented in Appendix Sec. 7.1, while the full data format specification is in Sec. 7.3. Each data instance in SCOPE contains one original example and three counterfactually evolved examples, all following a unified format with VQA annotations and corresponding programs. The resulting datasets include 31,233 training examples and 13,389 test examples, each paired with executable code. During program generation, we enforce execution correctness by iterative verification, ensuring a 100% success rate. Furthermore, to assess the quality of evolved data, we performed random human evaluations across three evolution iterations, achieving acceptability rates of 96%, 92%, and 91%, respectively. Regarding the methodology, in addition to GPT-4o, we used kvedit for image-editing subroutines. For better interpretability, we have already included a qualitative example in Figure 5, illustrating differences between raw and evolved samples. We will bring key statistics into the Benchmark section and cross-reference relevant figures for completeness.

[W6] The concern is about clarifying which model sizes benefit from SCOPE, requesting results for large open-source models to determine whether SCOPE’s utility extends beyond small-scale models and to better contextualize its contribution.

[A6] We appreciate the reviewer’s suggestion. Our choice of 2B and 7B models was intentional: these scales represent the most widely used and practical sizes for deployment due to their balance between performance, inference speed, and resource requirements. Most recent studies also report results primarily in this range. The key objective of SCOPE is to demonstrate that our data evolution method can bring consistent and significant improvements even at these common scales without requiring additional model capacity—an important factor for real-world applications where retraining extremely large models is infeasible.

Regarding 70B-scale models such as Qwen2.5-VL-72B or InternVL2.5-78B, our current hardware resources do not allow us to retrain or fine-tune models at that scale. However, we will include the official results of these models (without fine-tuning) in Tables 2 and 3 for comparison. This will make clear that while absolute performance from very large models is higher, SCOPE provides a scalable and cost-efficient strategy to improve reasoning ability for widely used mid-sized models.

[W7 & Q5] The concern is about clarifying how much baseline data is used for fine-tuning, whether performance gains come from your method or increased data size, and explicitly showing results with vs. without MAP to isolate the dataset’s impact, ideally supported by a statistics table.

[A7] The performance improvements with SCOPE come from two factors: higher-quality data and the MAP training strategy. To ensure fairness in comparisons, we applied the same MAP approach to all baselines, including Provision and VLB. Specifically, we computed curriculum difficulty scores for their samples, adopted balanced gating, and assigned fixed difficulty-aware loss according to their data distribution. This controls for differences in training method, meaning that the performance gaps shown in Tables 1–3 primarily reflect data quality rather than training strategy. From Table 2, readers can already directly compare the gains attributable to the dataset itself under the same MAP setting.

In response to the reviewer’s suggestion, we will extend Table 4 by adding a w/o MAP setting for direct fine-tuning. This will provide a clearer view of the independent contribution of MAP versus data quality.

[Q2] References need to be revised.

[A8] We acknowledge this point and will carefully review all references throughout the paper to ensure they accurately support the claims made.

Dear Reviewer,

I hope this message finds you well. As the discussion period is nearing its end with less than three days remaining, I wanted to ensure we have addressed all your concerns satisfactorily. If there are any additional points or feedback you'd like us to consider, please let us know. Your insights are invaluable to us, and we're eager to address any remaining issues to improve our work.

Thank you for your time and effort in reviewing our paper.

[W1 & Q1] The main bottleneck here is that this approach will only work with instances that can be described in code. This means the approach is not generalizable. & How would you generalize your approach to cover instances where generating a program is not possible?

[A1] We appreciate the reviewer’s concern regarding the perceived limitation that our approach only works with code-expressible instances. However, this concern is mitigated by substantial prior work—such as ViperGPT, Visual Programming (VISPROG), and De-fine—showing that code-driven paradigms adapt to a broad range of multimodal tasks beyond classical VQA.

ViperGPT composes Python programs from modular functions via LLM-generated code to perform visual grounding, image QA, video QA, multi-image comparison, symbolic math, and knowledge-aware queries. This framework requires no task-specific fine-tuning and achieves state-of-the-art zero-shot results across diverse benchmarks, evidencing that programmatic reasoning is not restricted to narrow domains.

VISPROG further demonstrates how modular, Python-like programs generalize across compositional visual reasoning, image editing, and zero-shot knowledge tagging—without training data—highlighting the flexibility of code-mediated reasoning.

De-fine refines visual programs through auto-feedback loops based on static and dynamic signals, improving robustness and logical consistency in multi-step reasoning without retraining, again confirming adaptability across domains.

These foundations give SCOPE a strong basis for generalizability. Notably, we do not alter the existing API or introduce new functions—the functions inherited from ViperGPT already support visual, math, OCR, and knowledge-augmented QA tasks, as discussed in our Reviewer #qgzN response A3's evaluations on MathVista, MMMU, and science/OCR benchmarks.

If a new domain emerges beyond existing coverage, SCOPE remains extensible: new domain-specific functions can be added to the library without redesigning templates, retraining models, or changing core architecture.

In summary, by leveraging VISPROG and ViperGPT’s modular, executable program paradigm and enabling addition of domain-specific functions when needed, SCOPE achieves broad generalizability and flexible extensibility across multimodal tasks.

[W2] The authors criticize prior work that relies heavily on model generation, yet SCOPE relies on GPT-4o for program generation. Also what if the generated code has flaws but still runs?

[A2] We appreciate the reviewer’s concern. In fact, our critique targets pipelines relying entirely on model-generated data for generation, verification, and feedback—leading to opaque reasoning and bias—SCOPE, though using GPT‑4o for program generation, adopts a fundamentally different, interpretable paradigm.

SCOPE employs executable code as an intermediate reasoning layer aligned with Chain-of-Thought. This code-mediated mechanism enhances interpretability and allows explicit control of reasoning steps, including editing or counterfactual manipulation—capabilities absent in end-to-end pipelines.

Moreover, SCOPE is model-agnostic. GPT‑4o can be replaced with other pretrained code models such as CodeLlama. We also present below the results of a InternVL‑2.5‑2B trained using code generated by CodeLlama. The future work will also integrate multiple code-pretrain models to reduce backbone dependence and model-specific bias.

Finally, human evaluation confirms the evolved code is readable, coherent, and aligned with intended reasoning, with acceptance rates of 96 %, 92 %, and 91 %, indicating that minor noise in code generation is negligible relative to the substantial gains in data quality and reasoning diversity.

[W3] SCOPE-test is not a challenging benchmark by any means; GPT-4o already achieves 88% accuracy.

[A3] Thank you for this insightful observation. In fact, SCOPE-Test was intentionally designed as a diagnostic benchmark, rather than a large-scale competitive suite, with the primary goal of exposing the limitations of current dataset evolution strategies. It demonstrates that models pretrained on existing datasets often fail on specific reasoning dimensions (e.g., those targeted by SCOPE-Test’s three axes), not because the models lack capacity, but because the distribution of existing data remains narrow and fails to cover critical domains. This highlights the necessity of structured data evolution rather than indiscriminately scaling pretraining corpora. Accordingly, SCOPE-Test is not meant to replace comprehensive benchmarks such as MMBench or MMMU; rather, its role is to isolate and stress-test reasoning abilities that conventional benchmarks often overlook.

Importantly, SCOPE-Test retains substantial room for difficulty escalation through multi-round evolution. To illustrate, we conducted a small-scale analysis. Specifically, we selected 100 samples that underwent 10 consecutive evolution iterations and evaluated them using GPT‑4o. The results are summarized as follows:

As shown, additional iterations systematically increase reasoning complexity (Halstead effort ↑ by 4.2×) while reducing GPT‑4o accuracy by 39%, confirming that the benchmark’s difficulty is tunable.

Beyond difficulty, SCOPE-Test reveals two critical weaknesses in current models: (1) Width limitations: difficulty in handling tasks that involve multiple interdependent variables or extended context windows; (2) Multi-image reasoning gaps: inability to integrate and reason over multiple visual inputs effectively. Both deficiencies can be directly mitigated through SCOPE’s controlled evolution strategies, which is the fundamental purpose and contribution of SCOPE-Test.

[W4] The approach is somehow complex and relies on many components, e.g., code generation and segmentation models.

[A4] We acknowledge that SCOPE, like prior frameworks such as ViperGPT and Visual Programming, incorporates components such as code generation and perception modules; however, these are standard elements of visual-programmatic paradigms rather than additional complexity introduced by our approach. SCOPE’s core contribution lies in aligning executable programs with chain-of-thought reasoning and introducing three orthogonal evolution strategies for controllable, systematic data diversification. Implementation remains as modular and lightweight as ViperGPT, while offering greater interpretability and verifiability through structured evolution rather than opaque model-driven augmentation. Given its strong performance and novel perspective, this program-based pipeline is a reasonable and acceptable design choice.

[Q1] How computationally expensive is your approach compared to the baselines?

[A5] We thank the reviewer for raising the concern regarding the computational cost of a single SCOPE iteration. Our method consists of two main components:

• Code Evolution: This phase generates new QA samples through programmatic function- and code-driven expansion, without relying on multimodal pipelines or iterative LLM validation loops.

• Classification: This phase assigns reasoning categories to generated QAs using static code analysis (e.g., AST parsing, Halstead metrics), avoiding LLM-based filtering.

Compared to prior work, MAmmoTH-VL relies heavily on multimodal LLMs in both the evolution and classification phases, introducing substantial inference overhead and high model cost. ProVision, while emphasizing that its pipeline does not depend on LLMs, explicitly states in its paper that it requires defining 24 single-image instruction data generator programs and 14 multi-image generator programs, each utilizing hundreds of pre-defined templates—resulting in significant manual engineering cost. In contrast, VLB employs iterative image manipulation and repeated LLM-based semantic verification, both contributing to considerable computational and inference overhead.

In summary, a single SCOPE iteration remains computationally lightweight and scalable—avoiding costly scene-graph generation and LLM inference—yet achieves richer structured outputs and diversity at a cost similar to prompt-based synthesis, and significantly lower than ProVision or VLB. We report the computational cost for a single evolution iteration across different baselines for comparison. The detailed results are summarized in Table below.

I'd like to thank the authors for the detailed response, and I hope they would factor in the extra clarifications in future revisions of the paper. I will maintain my fairly positive assessment of the paper.

[W1] The framework aims to improve the model through data, but its starting point depends on a very powerful model (GPT-4o). The quality and diversity of the generated program are limited by this external model, and its own biases or limitations may be passed on or even amplified in the evolution.

[A1] Thank you for your concern regarding the potential reliance of SCOPE on a strong backbone model (e.g., GPT-4o), which could constrain the quality and diversity of generated programs and potentially propagate its inherent biases. To address this, we provide the following explanation from four complementary perspectives:

(1) Theoretical Design: SCOPE introduces three orthogonal evolution strategies—reasoning path expansion, visual context editing, and cross-instance composition—which enable controllable, multi-dimensional diversification beyond superficial modifications, reducing dependency on any single model’s outputs.

(2) Code-Level Verification: Code-Level Verification: To empirically demonstrate that SCOPE progressively increases code diversity across iterations, we performed two complementary analyses. First, complexity growth: Measured by Halstead Effort, the average effort score shows a clear upward trend from approximately 3281 in the original version to 4369 after the first evolution, 5217 after the second, and 5973 after the third, indicating that the evolved code becomes increasingly complex and information-rich. Second, structural dissimilarity: We computed Abstract Syntax Tree (AST) similarity between each evolved version and the original code, observing a steady decline from 0.72 (first evolution) to 0.51 (second) and 0.34 (third), confirming that each evolutionary step introduces substantial structural variation. Together, these results provide strong evidence that SCOPE effectively enriches both the complexity and structural diversity of generated code through iterative evolution.

(3) QA Distribution Analysis: We evaluated diversity in the question space by measuring distributional differences using Maximum Mean Discrepancy (MMD). Specifically, we compared the QA distribution under SCOPE with two baselines: VLB and Provision. Our results show that SCOPE achieves a significantly higher MMD value (0.38) compared to VLB (0.15) and Provision (0.18), indicating that SCOPE's QA outputs are farther from the baseline distributions and thus occupy a more uniform and dispersed semantic space across reasoning categories. A larger MMD signifies greater divergence from the baseline distributions, demonstrating that SCOPE generates a structurally and semantically more varied QA set overall.

(4) Backbone Variation Experiment: To reduce reliance on a single backbone, we conducted experiments using code generated by CodeLlama, evaluating InternVL‑2.5‑2B on three benchmarks: RealWorldQA, MMBench, and ContextVD. The results show that switching to a different code pre‑training model has little impact on performance—InternVL‑2.5‑2B maintains competitive accuracy across all datasets. This experiment inspired us to plan the integration of multiple code‑generation models combined with diversity‑aware reward filtering, aiming to ensure continued structural and semantic variety while mitigating model‑specific bias.

[W2] The specific computational cost required for a single iteration of evolution has not been provided. Will this limit its practical application?

[A2] We thank the reviewer for raising the concern regarding the computational cost of a single SCOPE iteration. Our method consists of two main components:

• Code Evolution: This phase generates new QA samples through programmatic function- and code-driven expansion, without relying on multimodal pipelines or iterative LLM validation loops.

• Classification: This phase assigns reasoning categories to generated QAs using static code analysis (e.g., AST parsing, Halstead metrics), avoiding LLM-based filtering.

Compared to prior work, MAmmoTH-VL relies heavily on multimodal LLMs in both the evolution and classification phases, introducing substantial inference overhead and high model cost. ProVision, while emphasizing that its pipeline does not depend on LLMs, explicitly states in its paper that it requires defining 24 single-image instruction data generator programs and 14 multi-image generator programs, each utilizing hundreds of pre-defined templates—resulting in significant manual engineering cost. In contrast, VLB employs iterative image manipulation and repeated LLM-based semantic verification, both contributing to considerable computational and inference overhead.

In summary, a single SCOPE iteration remains computationally lightweight and scalable—avoiding costly scene-graph generation and LLM inference—yet achieves richer structured outputs and diversity at a cost similar to prompt-based synthesis, and significantly lower than ProVision or VLB. We report the computational cost for a single evolution iteration across different baselines for comparison. The detailed results are summarized in Table below.

[W3] As mentioned in the limitations of the article, the effectiveness of the method has not been validated in a wider range of domains.

[A3] Thank you for this valuable observation. To further demonstrate SCOPE's robustness and domain generality, we have planned evaluations on four additional benchmarks, which span different reasoning types:

• MathVista: visual-numerical reasoning and multi-step symbolic derivation
• MMMU: multi-disciplinary question answering (STEM, humanities, law, etc.)
• AI2D: diagram interpretation and science-specific reasoning
• DocVQA: OCR-based text-visual integration in real-world documents

In summary, these additional benchmarks will validate that SCOPE enhances reasoning consistency and multi-step control—even in domains demanding symbolic math, domain‑specific knowledge integration, or OCR-based reasoning. Importantly, we do not modify the existing API or introduce new functions for our current tasks. However, SCOPE’s design allows flexible extension into specialized domains: by defining new domain-specific functions and embedding task-relevant logic, we can seamlessly expand the function library without redesigning templates, prompt structures, or scene graphs. The three orthogonal evolution strategies—reasoning path expansion, visual context editing, and cross-instance composition—remain fully applicable across these domains, preserving lightweight implementation while supporting systematic and controlled domain adaptation.