Search for a command to run...
Transformation-based problem solving recurs across mathematics, engineering, artificial intelligence, and the sciences whenever the original form of a problem hinders analysis, computation, implementation, or cross-system coordination. In such cases, progress depends on changing the form itself: variables are rewritten, representations are recoded, domains are converted, scales are shifted, procedures are recast, and conceptual frames are reorganized so that a workable route becomes available. These transformations are widely used across fields, but they are rarely treated as a coherent methodological space. They remain scattered across local techniques and field-specific vocabularies, which makes transformation routes difficult to compare, justify, transfer, and accumulate across domains. Transformation Compass addresses this gap by providing a structured language for identifying why transformation is needed, what is being transformed, how the transformation is carried out, and what must still be preserved afterward. As the paradigm-specific zoom-in of the Transformation-Based branch of the Eight Universal Methodology Paradigms (UM8) (DOI: 10.5281/zenodo.18790203), the Transformation Compass develops transformation-based methodology into a structured framework for selecting, comparing, and justifying form-changing routes. It disentangles four commitments that practice often leaves conflated: transformation purpose, transformation object, transformation approach, and preservation commitment. By organizing these commitments into a coherent cross-domain design space, the framework helps researchers and practitioners plan transformation routes deliberately and assess whether a proposed transformation is methodologically appropriate for the task at hand. The value of the framework First, it provides a disciplined basis for transformation design by decoupling commitments that practice often inherits as a single bundled choice. Familiar transformation methods generally carry their purpose, target object, operational approach, and preservation burden together, even though these dimensions vary independently. Transformation Compass separates them into explicit methodological commitments, making it possible to align the intended gain of a transformation with the target object, the mechanism used to change it, and the conditions that must still hold afterwards. This design clarity is especially valuable in multi-step analytical pipelines, where transformations are chained, layered, or embedded within larger systems. Second, it makes transformation trade-offs explicit. Many non-trivial transformations operate under recurring tensions between tractability, feasibility, alignment, and fidelity. A route that improves efficiency may weaken semantic integrity; a simplification that secures operational viability may alter recoverability or constraint validity. Transformation Compass brings these trade-offs into the design space directly. By making preservation commitments explicit, it provides a structured basis for deciding what must remain intact, what may be relaxed, and what degree of approximation is methodologically acceptable for the intended use. Finally, it turns dispersed transformation practice into cumulative cross-domain methodological knowledge. Transformation methods are developed under highly local vocabularies, e.g., variable substitution in mathematics, representation recoding in machine learning, domain conversion in engineering, surrogate reformulation in scientific computing, and conceptual reframing in interdisciplinary inquiry. Transformation Compass provides a shared structural language for relating these routes without erasing their differences. This supports cross-domain transfer, makes methodological accumulation more systematic, and offers a clearer basis for future agent-level planning over transformation routes. Architecture of the framework 1. Transformation Purpose Transformation Purpose identifies the methodological gain sought through changing form. It orients transformation design before any particular transformation is chosen by asking what the current form fails to provide and what kind of gain the transformation must deliver. It establishes why transformation is being introduced in the first place and what kind of improvement it is expected to make possible. Simplicity (Complexity Reduction) Simplicity becomes the primary aim when the current form carries more structural, descriptive, or procedural burden than the task requires. The goal is to strip away formal clutter, reduce redundancy, or untangle overlapping elements while preserving the information needed for later work. It is chosen when a problem is already workable in its current form, yet remains unnecessarily cumbersome to inspect, analyze, or manipulate. Efficiency (Resource Economy) Efficiency becomes the primary driver when a workable route already exists, but carrying it out demands excessive time, memory, energy, data, or implementation effort. The concern here is operational economy rather than structural simplification. This purpose is selected when the central requirement is to reduce the resource burden of execution while keeping the task viable in its intended use. Feasibility (Operational Viability) Feasibility becomes the central concern when the current form blocks or severely limits a workable route. The obstacle may arise from intractability, excessive constraint burden, poor observability, or incompatibility with the available means of analysis, computation, or implementation. This purpose is selected when the primary need is to make the task operationally possible. Alignment (Cross-Form Compatibility) Alignment is the objective when the main challenge lies in relating heterogeneous forms, systems, or representational regimes. The central requirement is compatibility across forms that cannot otherwise be directly compared or coordinated. This purpose is selected when transformation is needed to establish commensurability, interoperability, or a common basis for comparison and use. 2. Transformation Object Transformation Object identifies the primary target of the transformation. This distinction is critical because similar transformation moves can carry very different methodological implications depending on what they act upon. By isolating the target, this dimension clarifies whether a transformation is changing formal structure, task setup, data representation, reference frame, or conceptual interpretation. Formal Structure This target is central when the transformation acts directly on the formal organization of the problem, such as equations, operators, algebraic forms, bases, or parameterizations. The underlying phenomenon remains constant, but its formal expression is reorganized to improve stability, manipulability, or analytical clarity. This object becomes primary when the main difficulty lies in formal complexity itself. Problem / Task Formulation Here the target is the way the task itself is posed. The transformation changes objectives, variables, constraints, role assignments, or the overall structure of the problem statement. This object becomes primary when progress depends on redesigning how the task is formulated. Data / Feature Representation This object becomes primary when the transformation changes how observed or latent content is represented. It includes raw data formats, engineered features, embeddings, and latent states. This object becomes central when downstream performance depends strongly on how relevant structure is exposed in the data or representation. Domain / Reference Frame This target is primary when the transformation changes the domain, scale, coordinate system, or reference frame in which the object is expressed, analyzed, or processed. The object itself is not fundamentally altered, but the descriptive or analytical frame is changed. This object becomes central when another domain or frame makes the object easier to analyze, compare, or process. Conceptual Frame Here the transformation changes the abstraction, analogy, or explanatory frame through which a situation is organized. This goes beyond formal or computational manipulation and acts on the conceptual lens used to approach the problem. By shifting analogies, levels of abstraction, or system boundaries, conceptual transformations can change how a situation is understood and approached. 3. Transformation Approach Transformation Object identifies the primary target of the transformation. This distinction is critical because similar transformation moves can carry very different methodological implications depending on what they act upon. By isolating the target, this dimension clarifies whether a transformation is changing formal structure, task setup, data representation, reference frame, or conceptual interpretation. 3.1 Representation Rewrite — In-Domain Representation Change This family rewrites the same object through different variables, codes, or bases while keeping the underlying domain and reference frame unchanged. It becomes central when the main obstacle lies in the current expression itself. Reparameterization rewrites the same object under a different variable or parameter scheme. It becomes especially effective when the existing parameterization introduces awkward constraints, poor conditioning, or unnecessary coupling, and when a new variable scheme yields a more workable formal geometry. Recoding rewrites the same content in a different code or representational format. Its methodological role is strongest when storage, retrieval, transmission, comparison, or learning depends on the coding structure rather than on any change in the object itself. Canonicalization / Normalization rewrites the object into a standardized form. This route is particularly valuable when superficial variation blocks comparability, invariance, or stable downstream handling, and a common baseline represe