> For the complete documentation index, see [llms.txt](https://docs.sealights.io/knowledgebase/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealights.io/knowledgebase/knowledge-base/sealights-for-abap/how-it-works/day-zero-structural-analysis-no-execution-history-required/most-at-risk-ranking.md). # Most-At-Risk Ranking {% hint style="info" %} Most-At-Risk Ranking is available only through Test Cycles. {% endhint %} #### Core Capability Not all impacted executables carry equal risk. Most-At-Risk Ranking takes the full set of executables surfaced by the dependency map and applies five heuristics — in priority order — to rank them from highest to lowest risk. The output is the Most-At-Risk set: the executables that most urgently need test coverage in this cycle. This ranked list drives both the test recommendations in Step 3 and the coverage reporting throughout the cycle. #### Interface Experience and Navigation The Most-At-Risk Executables count is surfaced in the **Change Analysis** tab as one of the four headline metrics. The ranked list itself drives the **Tests to Run** tab — the tests recommended are those that cover the most-at-risk executables, not the full impacted set. There is no separate ranking view in the UI; the ranking is expressed through the test recommendations and coverage outputs. *** ### Business Value & Key Use Cases * **Testing what matters, not everything** — The impacted executable count in a large release can run into the hundreds. Testing all of them exhaustively is neither feasible nor necessary. The Most-At-Risk set identifies the subset where test coverage is genuinely critical, so effort is concentrated where it matters most. * **Objective prioritization** — Risk ranking is based on defined, consistent heuristics rather than individual judgment or tribal knowledge about which programs are "important." Every team, on every cycle, applies the same logic. * **Business-critical process protection** — The highest-priority heuristic allows teams to permanently flag their most critical executables so they are always prioritized regardless of where the change landed in the dependency chain. #### Impact Metrics In a cycle with hundreds of impacted executables, Most-At-Risk Ranking typically reduces the test-relevant set to a fraction of the full impacted count — without dropping any genuinely high-risk executable from the recommendation. The result is a test list scoped to real risk, not worst-case surface area. *** ### Detailed Functionality #### The Five Heuristics Heuristics are applied in priority order. A higher-priority heuristic always outweighs a lower one — an executable ranked up by heuristic 1 is not demoted by heuristic 5. *** **1. Business Criticality** Executables that have been manually flagged as business-critical are always included in the Most-At-Risk set when they appear in the dependency map — regardless of how they score on any other heuristic. This is the team's override: if a process is mission-critical, it is always prioritized. Business-critical executables are uploaded and managed directly in the product. This list is persistent across cycles — it does not need to be re-entered per cycle. > This is the only heuristic that teams can configure. All others are determined by SeaLights automatically. *** **2. New or Changed Executable** If the executable itself is brand-new or was directly modified by one of the cycle's transports, it is treated as high risk regardless of usage history. New objects have no established behavior baseline and no prior test evidence — they are unknown quantities by definition. *** **3. Dependency Depth** The closer an executable sits to the changed object in the dependency graph, the stronger the risk signal. An executable that directly calls a changed function module is ranked higher than one that reaches the same object through three intermediate layers. Shorter dependency paths mean the change has a more direct and likely impact on that executable's behavior. *** **4. Functional Relevance** Executables that belong to the same SAP functional module as the changed object — or a closely related one — are ranked higher than executables in unrelated modules. A change in a Purchasing object is more likely to affect Purchasing and Materials Management executables than Finance ones. This heuristic reduces false positives from distant cross-module dependencies. *** **5. Usage Frequency** Among executables that score similarly on the first four heuristics, the one used most frequently in production is ranked higher. High-usage executables affect more users and more business processes — a failure there has a broader blast radius than a failure in a rarely-used program. *** #### The Most-At-Risk Set in Practice The five heuristics together produce a ranked list where the top entries are executables that are: flagged as critical, or newly changed, or directly dependent on the changed object, or functionally adjacent to it, or heavily used in production — and typically some combination of all of these. These are the executables that warrant verified test coverage before the release proceeds. The rest of the impacted executables — those ranked lower — are not ignored. They still appear in the Impacted Executables count in the Change Analysis tab. But they are not prioritized in the test recommendations, because the structural and contextual signals suggest their risk in this specific cycle is lower. *** ### FAQ **Q: How do we flag an executable as business-critical?** A: Business-critical executables are uploaded as a list and managed directly in the SeaLights product. The list is persistent and applies to all future cycles on the connected landscape. \[Configuration detail pending validation — specific upload format and management UI steps for the business-critical list, available in Service Pack 2.] **Q: Can we adjust the weight or order of the five heuristics?** A: No. The heuristic priority order is fixed. The only configurable input is the business-critical executable list, which feeds heuristic 1. All other heuristics are applied automatically based on system data. **Q: An executable we consider high-risk isn't appearing in the Most-At-Risk set. Why?** A: The most likely reasons are: (a) the executable is not production-active and was excluded from the dependency map, (b) the executable has no dependency on any of the changed objects in this cycle's transports, or (c) the executable has not been added to the business-critical list. If it should always be prioritized when impacted, adding it to the business-critical list ensures it is never deprioritized. **Q: Does the Most-At-Risk set change during the cycle as tests execute?** A: No. The Most-At-Risk set is determined at cycle creation from the dependency map and heuristics. It is fixed for the lifecycle of the cycle. What changes as tests execute is the coverage status of those executables — which ones have been verified and which remain unverified. *** *Part of the* [*Day Zero: Structural Analysis*](https://claude.ai/chat/how-01-day-zero.md) *section | SeaLights for ABAP* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.sealights.io/knowledgebase/knowledge-base/sealights-for-abap/how-it-works/day-zero-structural-analysis-no-execution-history-required/most-at-risk-ranking.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.