The same operation, in any vocabulary
Most of the work — from clinical decision support to formal protocols for hierarchical action, from rebuilding published SOTA to deep readings of emerging neural architectures — turns on the same operation: see the invariant first; treat any one domain's vocabulary as a projection of the invariant, not its definition.
A problem usually arrives wearing one domain's language. The first move is to refuse to stay in that language exclusively. The same task, restated in a second and a third vocabulary, exposes which parts are local to a phrasing and which parts survive translation. What survives is the object to work with. The rest is decoration that any one domain happens to add.
Operational form — three moves
-
Define the object by its external arrows. Inputs, constraints, dependencies, sources of authority — including the top-level ones a commercial system always has and analyses usually omit.
-
Find the decomposition where each arrow lands cleanly in one component. Test: if a component is modified, which external arrows change? Crisp answer — clean boundary. Diffuse answer — decompose again.
-
Let the internal structure fall out. With interfaces fixed and orthogonal, implementation is constrained optimisation, not a design choice.
Each significant decision traces back to axioms or constraints. Alternatives are taken to the level of a usable artifact, then compared. Open questions are marked as external-dependent, not masked. The same procedure applies recursively to the code itself: module boundaries forced by the same external arrows, not by stylistic convention.