Change May-Impact Analysis

• Change May-Impact Analysis is a systematic approach to identify potential impacts across loosely coupled artifacts, configurations, and processes in complex environments.
• It leverages formal dependency graphs, rule-based inference, and semantic fusion to map design-time over-approximations of change effects in integrated systems.
• Recent applications integrate CMIA into workflows like CI/CD and requirements-to-architecture mappings to reduce risk and false positives in dynamic settings.

Change May-Impact Analysis (CMIA) refers to the rigorous, systematic identification of artifacts, instances, or stakeholders potentially affected by a proposed change—typically in a context where direct impacts are not statically apparent due to dependencies, configuration variation, process dataflows, or architectural boundaries. This paradigm generalizes traditional Change Impact Analysis by emphasizing conservative, design-time over-approximation of all entities that a change "may" affect, prior to observing concrete execution, configuration, or instance data. Recent research advances have formalized, implemented, and benchmarked CMIA in software process modeling, data-centric business processes, requirements-to-architecture propagation, containerized cloud application pipelines, and highly-configurable build systems.

1. Formal Foundations of May-Impact Analysis

The formal apparatus of Change May-Impact Analysis is grounded in relating a set of candidate changes to all reachable impacts via static dependency structures, relational schemas, or inter-artifact graphs under precise propagation and cardinality conditions.

In a data-and-process context, Evron et al. (Evron et al., 2024) define a data-aware process model as a tuple $M = (A, G, F, type_G, DI, RC, RF, IAO)$, combining control flow (activities, gateways, edges), data items (DI), routing constraints (RC), and input-activity-output mappings (IAO). Inter-instance impacts are characterized by the potential for a data value $d$ shared through 1–m/m–m relational cardinalities to propagate from an initial activity to downstream activities in coupled process instances. They define the Potential Data Impact set:

$$PDI = \{ (d_i, d_j; d) \mid d_i \Rightarrow d \text{ in some PI},\ d \Rightarrow d_j \text{ in some PI}' \},$$

supporting the computation of MayImpact sets for change reviews and process management.

Requirement-to-architecture propagation leverages logic-based relation semantics and rule guards: given requirements $R$ as first-order formulas $\Pi(r)$ and artifacts $A$, binary relations (e.g., requires, refines, conflicts) and explicit R-to-A traces (satisfies, allocatedTo) are used to encode the reach of propagating changes through requirements and into architecture elements (Goknil et al., 2016). Rule tables define, for each pair $(\delta, \text{relation})$, whether and how propagation occurs, substantially reducing false positives.

In microservice architectures, a global artifact graph IR is maintained with nodes for components, REST endpoints, repositories, and their cross/repo dependencies. Impact propagation traverses the IR’s graph structure, combining direct and transitive dependencies to yield the full impact set (Cerny et al., 20 Jan 2025).

2. Methodological Patterns and Algorithms

CMIA methodologies instantiate a combination of static graph traversal, rule-based inference, and relational analysis:

• Static dependency closure: Traversal of control/data/trace edges, sometimes with type and relation-specific guards, to compute may-impact sets. For example, in business process models, computation of the transitive closure over data item dependencies identifies all intra- and inter-instance impacts (Evron et al., 2024).
• Rule-based pruning: Use of formal rules to determine when propagation should occur, avoiding naive transitive closure. In requirements-to-architecture analysis, rules check propagation guards to prune infeasible or irrelevant chains, reducing candidate sets and analyst burden (Goknil et al., 2016).
• Semantic–structural fusion: Hybrid methods blend semantic similarity scores (from embeddings or IR-based vector spaces) with structural propagation over heterogeneous graphs. Impacts are scored as $I = \lambda p + (1-\lambda) s$, with $p$ the semantic prior and $s$ the multi-hop structural propagation; thresholding $d$0 provides the impact set (Seedat, 17 Jun 2026).
• Configuration and cross-variant analysis: For multi-variant configurable systems, exposure analysis parses build scripts (e.g., CMake) to build a feature-guarded dependency graph. Backward traversal from deliverables under all configuration conditions surfaces the may-impact (exposure) set for any file-level change (Meidani et al., 2021).
• Blast-radius and pipeline mapping: In cloud-native CI/CD, the impact analysis consists of mapping changed tasks to affected pipelines by building and querying a bipartite task-to-pipeline graph, computing direct ("one hop") blast radii, and summarizing these impacts for release stakeholders (Bhati, 15 Mar 2026).
• Requirements impact prediction using LLMs: Prompt-engineered LLMs label potentially impacted requirements for a natural-language change rationale. This is combined with iterative refinement and NLI filtering for cost-effective may-impact sets (Etezadi et al., 31 Oct 2025).

3. Metrics, Evaluation, and Case Studies

Formal evaluation of CMIA focuses on recall (coverage of true impacts), reduction of false positives, computational complexity, and integration feasibility.

• Recall and precision tradeoffs: In requirements-level LLM analysis, recall exceeds 93%, with precision-based filtering lowering engineer review cost to as little as 2.1–8.6% of all requirements (Etezadi et al., 31 Oct 2025). In graph-propagation hybrid systems, precision/recall curves are parametrically controlled (via λ, τ) and can be explicitly tuned (Seedat, 17 Jun 2026).
• Reduction of false positives: Rule-based semantic propagation yields a 50–60% reduction in suspect architectural elements compared to unfiltered graph closure in industrial AADL/requirements scenarios (Goknil et al., 2016).
• Effort and performance: In safety-critical settings, empirical effort for change-impact activities is estimated at 50–100 hours per engineer per year, with per-change cost scaling sublinearly with improved tool support (Borg et al., 2016).
• Case studies: Application on enterprise business processes (Production, Order-to-Cash, Course-Management) demonstrate tight correspondence between model-based may-impact sets and expert-elicited effects in 4/5 actual scenarios (Evron et al., 2024). Microservice benchmarks show recall=1 for "breaking change" detection rules, with a majority of flagged changes considered actionable upon manual inspection (Cerny et al., 20 Jan 2025). Model differencing for UML-driven systems yields automated checklists and reduced oversight in schema and data-evolution tasks (Müller et al., 2014).

4. Limitations and Open Challenges

Critical limitations and open challenges in current CMIA methodologies include:

• Scalability: Full transitive analysis remains $d$1 or worse; pragmatic implementations employ pruning, incremental updates, or domain-specific constraints to maintain tractability (Evron et al., 2024).
• Coarseness of granularity: File-level or artifact-level impact may overapproximate actual dynamic impact, especially in configurable or data-intensive systems (Meidani et al., 2021).
• Semantic gap: Purely structural approaches miss semantically-related but unlinked artifacts, while purely semantic (embedding-based) approaches lack precision. Fused methods begin to close both gaps but remain contingent on high-quality extraction and parameter tuning (Seedat, 17 Jun 2026).
• Configuration and data challenges: Scenarios with complex build-time configuration or cross-instance data dependencies require comprehensive static models to avoid missing exposed or coupled impacts (Meidani et al., 2021, Evron et al., 2024).
• Empirical incompleteness: Some domains (safety cases, configuration exposure) lack large-scale, published empirical validation, and rely on analytical complexity bounds or small-scale expert review (Jaradat et al., 2014, Meidani et al., 2021).

5. Tool Architectures and Integration Workflows

CMIA tooling is increasingly embedded into pre-commit, CI/CD, and review workflows:

• Incremental intermediate representations (IR): Systems maintain up-to-date artifact graphs and process only deltas per commit, integrating impact reports directly with code review pipelines (Cerny et al., 20 Jan 2025).
• Checklist generation: Domain-specific impact rules, applied on model differences, yield explicit developer checklists for dependent data evolution, migration coding, and configuration adjustment (Müller et al., 2014).
• Web-based impact resolution: Authoring systems (e.g., sTeX/OMDoc DMS) integrate change-impact propagation with user-in-the-loop resolution, highlighting and annotating potentially impacted document fragments (Autexier et al., 2011).
• Live exposure feedback: Static build-graph analysis can annotate code patches with variant exposure at code review, guiding targeted testing (Meidani et al., 2021).
• Blast-radius matrix in promotion pipelines: CI/CD workflows collect task-to-pipeline adjacency matrices and compute blast radius per change for structured stakeholder communication (Bhati, 15 Mar 2026).
• Requirements/CIA assistant LLMs: Prompt-parametrized, cache-augmented LLMs provide prioritized, focus-minimizing requirement impact sets, filtered for confidence using entailment classifiers (Etezadi et al., 31 Oct 2025).

6. Practitioner Guidelines and Impact Management Strategies

Best practices emerging from CMIA research include:

1. Model explicit data, artifact, and control-flow dependencies at design-time, aligning relational schemas, process models, and traceability models to allow comprehensive over-approximation of may-impact sets (Evron et al., 2024).
2. Augment model-based propagation with domain-specific rule guards to constrain false-positive rates and focus analysis, particularly in requirements/architecture settings (Goknil et al., 2016).
3. Continuously update and visualize dependency graphs—in microservice infrastructure or build environments—to detect coupling "hotspots" and architectural erosion early (Cerny et al., 20 Jan 2025).
4. Automate impact reporting to integrate into developer, safety, and operational workflows, providing readiness checklists, impact badges, or distribution lists per change (Müller et al., 2014, Autexier et al., 2011).
5. Tune semantic/structural fusion parameters and thresholds explicitly to match organizational tolerance for recall versus precision, enabling traceable trade-offs (Seedat, 17 Jun 2026, Etezadi et al., 31 Oct 2025).
6. Incorporate impact analysis in the rationale and review process for every substantive change, leveraging documented may-impact reporting to inform resource allocation, regression testing, and risk communication (Borg et al., 2016, Evron et al., 2024).
7. Review and evolve may-impact models as business rules, data schemas, or operational pipelines change, recognizing that value derives from aligning the analytic model with the system's true coupling structure over time (Müller et al., 2014, Cerny et al., 20 Jan 2025).

7. Future Directions

Continued research and industrialization of CMIA will likely involve:

• Richer semantic extraction from non-code artifacts (metrics, dashboards, infra specs) and cross-stack integration in impact graphs (Seedat, 17 Jun 2026).
• Generalization to runtime and transitive dynamic effects, including pipeline trace analysis and data-flow through operational telemetry (Bhati, 15 Mar 2026).
• Scalable, explainable, LLM-driven impact analysis, with prompt design and hybrid symbolic–neural pipelines enabling practical deployments at scale (Etezadi et al., 31 Oct 2025).
• Benchmarking and evaluation across domains with gold-standard datasets, enabling quantitative assessment of tradeoffs in recall, precision, and engineer effort (Cerny et al., 20 Jan 2025, Stengg et al., 22 Dec 2025).
• Feedback-driven refinement—continuous learning from impact realization and developer interaction to adjust model parameters, rules, or propagation logic.

Change May-Impact Analysis thus provides a formal, evidence-based, and operationally grounded toolkit for anticipating, reporting, and managing the multidimensional surface of change in complex software, data, and process environments.