Functionality Localization: Multidisciplinary Insights

• Functionality localization is the study of mapping behavior to specific realizers—such as memory accesses, code segments, GUI regions, and atomic neighborhoods—across diverse disciplines.
• In computer architecture and graph theory, researchers show that access order and structural constraints can localize computational functions and influence overall system complexity.
• In software and GUI domains, functionality localization bridges natural-language descriptions to precise code segments or interface elements, improving fault detection and interactive design.

Functionality localization denotes the placement, recovery, or confinement of function within a representation, but the object being localized varies sharply across fields. In computer architecture, the term is tied to the claim that the access order of an invariant bit layout can determine different functionalities (Peng, 2024). In software engineering, it denotes mapping natural-language descriptions of bugs, features, or failing behavior to files, methods, and related artifacts (Wang et al., 1 Oct 2025, Shi et al., 24 Sep 2025, Zhou et al., 2019). In GUI research, it denotes grounding a functional goal to a region or element on the screen and predicting the state transition induced by interaction (Li et al., 27 Apr 2026). In graph-based path counting, localization refers to the concentration of long paths near a special high-functionality vertex (Nechaev et al., 2016), whereas in graph theory “functionality” is itself a hereditary complexity parameter whose boundedness depends on the graph class (Dallard et al., 2023). In metallic systems, functionality localization is formulated as the confinement of energy-dependent properties to small atomic neighborhoods (Rajivmoorthy et al., 2021). These usages are non-equivalent, but they share a common concern: identifying where behavior is realized, encoded, or concentrated.

1. Conceptual range and recurring structures

A first distinction is between localizing realizers and localizing effects. In software and GUI settings, localization means finding the code files, methods, or screen regions that implement or should implement a described behavior. In the architecture paper, by contrast, functionality is localized in access order and layout rather than in a separate ALU or control unit. In the graph-path literature, localization means that asymptotically dominant paths remain near a special vertex instead of spreading to infinity. In metallic systems, the localized object is not code or control but the energetic influence of a neighborhood around a cluster (Peng, 2024, Escudero et al., 23 Oct 2025, Li et al., 27 Apr 2026, Nechaev et al., 2016, Rajivmoorthy et al., 2021).

A second distinction concerns what “functionality” denotes. In repository-level localization and GUI grounding, it means a user-visible behavior or task. In the path-counting graph model, it means the degree or coordination number of a special vertex, denoted $p_0$. In the graph-complexity literature, functionality is a Boolean-definability parameter on vertex neighborhoods. In circuit thermodynamics, functionality is the global permutation $P$ implemented by a reversible circuit (Nechaev et al., 2016, Dallard et al., 2023, Chamon et al., 2023).

A common pattern is that functionality localization is mediated by an intermediate representation. The architecture paper uses access order $\pi$ over a fixed data layout $D$. Repository-memory and fault-localization systems use natural-language summaries or commit messages as queries into code. GUI localization uses hierarchical functional regions with bounding boxes and functionality annotations. The metallic-neighborhood method uses the stabilization function $\Delta \varepsilon_n^x$ to determine when the energetic effect of the environment has effectively saturated (Peng, 2024, Wang et al., 1 Oct 2025, Shi et al., 24 Sep 2025, Li et al., 27 Apr 2026, Rajivmoorthy et al., 2021).

2. Localization in memory-centric computer architecture

The most explicit architectural formulation is Functionality Locality, defined as: “the access order of a single piece of information can determine different functionalities, though the information has no spatial changes” (Peng, 2024). The defining conditions are that there is one single piece of information, its spatial layout does not change, and only the order of access changes. The canonical example is a fixed binary layout that behaves as a computational structure when accessed from top to bottom and as a bitmap for queries when accessed from bottom to top. The paper therefore extends locality beyond spatial and temporal reuse to a functional dimension: the operation performed is determined by access order over invariant data.

The DRAM example in the same work makes the mechanism more explicit. After a three-cell Processing-Using-DRAM sequence over cells $A$, $B$, and $C$, the final state is written as

$$\text{Final state} = AB + BC + AC = C(A + B) + \neg C(AB).$$

Under this interpretation, $A$ and $P$0 are operand bits and $P$1 is a control bit. When $P$2, the final state is $P$3 (logical OR); when $P$4, it is $P$5 (logical AND). The physical cells do not change identity; the realized logic is attached to the operation sequence, i.e. to access order at circuit level (Peng, 2024).

The same paper introduces Mixture as a unifying abstraction: a bit sequence with arbitrary length whose functionalities include compute, query, and move. Its capabilities depend on length and layout. For length $P$6, a Mixture can compute, query, and move. For length $P$7 with horizontal layout, it can compute and move but not query. For length $P$8 with vertical layout, it can query and move but not compute. The paper states that these definitions “shall cover all existing quantifiers (such as scalar and vector) and bitmaps,” making layout-directed functionality central rather than incidental (Peng, 2024).

From Functionality Locality and Mixture, the work derives the principle Control = Logic = Memory. Control is stored in memory bits; logic is realized by sequences of memory operations; and memory becomes both the place and the mechanism for control and logic. On this basis, the Harvard model is described as “a form of specialization of Von Neumann Model, with different levels of the granularity for the memory,” and memory-centric computing is expanded into Everything is Memory. A plausible implication is that this is a particularly strong form of functionality localization: functionality is localized in memory layout plus access order, not in dedicated compute units (Peng, 2024).

3. Software-engineering localization of functionality in code

In repository-level software engineering, functionality localization is the problem of identifying “the specific files and code segments that need to be modified to resolve the issue at hand” (Wang et al., 1 Oct 2025). One line of work augments graph-guided agents with repository memory built from commit history. The memory is explicitly split into episodic memory—recent commits, diffs, linked issues—and semantic memory—LLM-generated functionality summaries for the most frequently modified files. Retrieval is provided through tools such as SearchCommit, ExamineCommit, ViewSummary, and SearchSummary. Commit retrieval uses BM25 over commit messages with an LLM-based tokenizer, and the semantic store is built from top-$P$9 frequently modified files, with $\pi$0 in the reported pipeline. On SWE-bench-verified, full repository memory raises LocAgent from Acc@5 $\pi$1 to $\pi$2; on SWE-bench-live it raises Acc@5 from $\pi$3 to $\pi$4 (Wang et al., 1 Oct 2025).

At finer granularity, method-level fault localization is treated as behavior-to-code alignment. FaR-Loc consists of LLM Functionality Extraction, Semantic Dense Retrieval, and LLM Re-ranking. A failed test and its stack trace are first converted into a concise natural-language description of the failing functionality. This description is embedded into the same semantic space as covered methods by models such as CodeBERT, CodeT5+, and UniXcoder, and methods are retrieved by cosine similarity via FAISS. Re-ranking is then performed by an LLM over the retrieved methods. On Defects4J v1.2.0, FaR-Loc reports Top-1 $\pi$5, Top-3 $\pi$6, and Top-5 $\pi$7, outperforming SoapFL and AutoFL; replacing the functionality query with raw test code and stack traces reduces Top-5 from $\pi$8 to $\pi$9, and removing LLM re-ranking reduces Top-5 from $D$0 to $D$1 (Shi et al., 24 Sep 2025).

A complementary mobile-app setting localizes change files from user reviews. RISING performs classification, fine-grained segmentation, constrained clustering, and linking. Reviews are filtered to feature request and problem discovery, segmented into atomic sentences using conjunction-aware parsing, and clustered by COP-Kmeans under must-link and cannot-link constraints. Localization then combines review–code similarity with review–commit similarity, using weighted asymmetric Dice scores and a dynamic interpolation

$D$2

where $D$3 is the review length and $D$4 is the number of words shared by the review and the file’s commit tags. On the evaluated Android apps, RISING reports average Top-5 accuracy of $D$5 for feature requests and $D$6 for problem discovery, substantially exceeding the reported ChangeAdvisor baseline (Zhou et al., 2019).

Across these systems, the localized target is not merely “relevant text” but an implementation site: files, methods, diffs, or code regions. The recurrent technical problem is the lexicon gap between user-facing descriptions and implementation vocabulary. Commit history, LLM-generated functionality descriptions, and file-level summaries all serve as bridge representations between behavior and code (Wang et al., 1 Oct 2025, Shi et al., 24 Sep 2025, Zhou et al., 2019).

4. GUI functionality localization

In GUI research, functionality localization is the grounding problem “Given a functional goal described in language, which region/element (where) in the GUI realizes that function?” (Li et al., 27 Apr 2026). AutoGUI-v2 operationalizes this through a hierarchy of functional regions, defined as high-level groupings of UI elements that collectively serve a unified purpose. Each region is annotated with an image crop $D$7, a normalized bounding box $D$8, a taxonomy type, a visual description $D$9, a high-level functionality $\Delta \varepsilon_n^x$0, and a dividable flag controlling recursive decomposition.

The benchmark contains 3,710 hierarchical functional regions and 2,753 evaluation tasks across six operating systems. These tasks are divided into region-level grounding and captioning, and element-level grounding and captioning. Region-level functionality-oriented grounding asks, for example, which region should be clicked to switch workspaces; element-level grounding asks which fine-grained widget should be used to realize a specified function. Performance is measured by Grounding Center Accuracy

$\Delta \varepsilon_n^x$1

and, for box-producing models, by IoU (Li et al., 27 Apr 2026).

AutoGUI-v2 also treats functionality as a single-step state transition. Captioning tasks ask what happens if the highlighted region or element is clicked, hovered, dragged, right-clicked, double-clicked, long-pressed, or typed into. Hard negatives are constructed from visually similar but functionally distinct elements, so success requires functional understanding rather than appearance matching. The benchmark introduces NID (Normalized Interference Density) to stratify samples by surrounding context density, using an analysis region expanded by $\Delta \varepsilon_n^x$2 around the target (Li et al., 27 Apr 2026).

The reported evaluations show a pronounced model dichotomy. For region grounding, Qwen3-VL-32B and GLM-4.5V report functionality grounding accuracies of $\Delta \varepsilon_n^x$3 and $\Delta \varepsilon_n^x$4, respectively, while Gemini-2.5-Pro reports $\Delta \varepsilon_n^x$5. For element grounding, Qwen3-VL-32B reports $\Delta \varepsilon_n^x$6 and Gemini-2.5-Pro $\Delta \varepsilon_n^x$7. For captioning, commercial models dominate: GPT-5 reports $\Delta \varepsilon_n^x$8 on region captioning, and Gemini-2.5-Pro reports $\Delta \varepsilon_n^x$9 on element captioning. The benchmark therefore distinguishes functional grounding from functionality captioning / outcome prediction, and documents that “all models struggle with complex interaction logic of uncommon actions” (Li et al., 27 Apr 2026).

This use of functionality localization is especially close to interactive agents: the localized object is a spatial region whose function is defined by the state transition it induces. It is therefore neither pure object detection nor pure language understanding, but a grounded mapping from functional intent to executable interface location (Li et al., 27 Apr 2026).

5. Graph-theoretic and spectral senses of localization

A different literature studies paths counting on simple graphs and uses “functionality” for the degree of a special vertex. Paths of length $A$0 are counted with weight $A$1, and $A$2 denotes the number of such paths whose endpoint lies at distance $A$3 from the root. The special root has functionality $A$4, ordinary vertices have functionality $A$5, and the root acts as an entropic trap because a larger degree multiplies the number of path continuations. Localization occurs when a root-centered eigenmode with eigenvalue $A$6 overtakes the bulk mode $A$7, so that $A$8 and $A$9 decays exponentially in $B$0 (Nechaev et al., 2016).

The critical functionality depends on topology. For the infinite regular tree with heavy root,

$B$1

For regular hyperbolic graphs with parameter $B$2,

$B$3

For decorated star graphs, obtained by the reduction $B$4,

$B$5

Below the threshold, long paths delocalize and their typical distance grows linearly in $B$6; above the threshold, endpoint distributions decay exponentially with distance from the root (Nechaev et al., 2016).

The same word, however, has a wholly different meaning in graph-complexity theory. There, for a graph $B$7 with adjacency matrix $B$8, a vertex $B$9 is a function of vertices $C$0 if there exists a Boolean function $C$1 such that

$C$2

for every other vertex $C$3. The functionality of $C$4 is the minimum such $C$5, and the functionality of $C$6 is the hereditary max-min over induced subgraphs. In this sense, interval graphs have functionality at most $C$7; box intersection graphs in $C$8 have unbounded functionality; and the status of functionality for box intersection graphs in $C$9, including unit box intersection graphs, remains open. The same paper also shows that symmetric difference is unbounded for interval graphs and for unit box intersection graphs in $$\text{Final state} = AB + BC + AC = C(A + B) + \neg C(AB).$$0 (Dallard et al., 2023).

These two graph literatures therefore illustrate a recurrent source of confusion: functionality may denote either a degree parameter controlling entropic localization or a Boolean neighborhood-compressibility parameter controlling structural complexity. The shared word does not imply a shared formalism (Nechaev et al., 2016, Dallard et al., 2023).

6. Localized functionality in materials, circuits, and requirements models

In metallic systems, functionality localization is explicitly energy-based. The proposed method tracks the Bader energy of a central cluster $$\text{Final state} = AB + BC + AC = C(A + B) + \neg C(AB).$$1 as successive coordination shells are added. For elemental crystals, with isolated-atom energy $$\text{Final state} = AB + BC + AC = C(A + B) + \neg C(AB).$$2, infinite-crystal per-atom energy $$\text{Final state} = AB + BC + AC = C(A + B) + \neg C(AB).$$3, and cluster energy $$\text{Final state} = AB + BC + AC = C(A + B) + \neg C(AB).$$4, the stabilization function is

$$\text{Final state} = AB + BC + AC = C(A + B) + \neg C(AB).$$5

The neighborhood radius $$\text{Final state} = AB + BC + AC = C(A + B) + \neg C(AB).$$6 is identified when the Bader atoms of $$\text{Final state} = AB + BC + AC = C(A + B) + \neg C(AB).$$7 are closed and $$\text{Final state} = AB + BC + AC = C(A + B) + \neg C(AB).$$8 enters an asymptotic regime. Across crystalline materials and defects, the paper reports that neighborhood size “may be universal - around 2-3 atomic diameters,” and uses this to argue that energy-dependent properties can be localized to meaningful chemical neighborhoods in metals (Rajivmoorthy et al., 2021).

In reversible-circuit thermodynamics, functionality is the permutation $$\text{Final state} = AB + BC + AC = C(A + B) + \neg C(AB).$$9 implemented by a circuit. For fixed length $A$0, the multiplicity of circuits with that functionality is

$A$1

and the associated circuit entropy is

$A$2

The paper then describes obfuscation as thermalization through recursive mixing of neighboring circuit sections: local moves preserve the global functionality while scrambling internal structure. At the same time, the authors argue that the circuit space fragments into disconnected ergodic sectors, and that such fragmentation is unavoidable unless NP and coNP coincide. This yields a constrained notion of functionality localization: within a sector, functionality can be delocalized by local mixing; across sectors, same-size circuits with the same functionality may remain unreachable by bounded local moves (Chamon et al., 2023).

Requirements engineering supplies a third, diagrammatic sense. In the Thinging Machine ontology, a thimac is simultaneously a thing and a machine, and a TM machine can perform only five primitive operations: Create, Process, Release, Transfer, and Receive. The paper defines functionality as “a web of interdependent thimacs” and states that “the TM model is the realization (static description) and execution (dynamic description) of the system’s function.” Functionality localization here is the mapping of functions and subfunctions to thimacs, stages, flows, and events. The automobile, coffee mill, pump, producer-consumer buffer, ATM, and order-processing examples all instantiate this idea by locating each subfunction in explicit nodes and flows of the diagram (Al-Fedaghi, 2020).

Taken together, these papers show that functionality localization is not a single discipline-specific primitive but a family of localization problems. Some versions ask where functionality is implemented; others ask where it is concentrated, recoverable, or encoded. The common thread is a shift away from treating function as an abstract label alone and toward treating it as something that can be pinned to concrete realizers: access sequences, memory cells, files, methods, GUI regions, graph vertices, atomic neighborhoods, circuit sectors, or diagrammatic submachines.