> 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-executables.md).

# Most at Risk Executables

**SeaLights** identifies the smallest set of application entry points that must be tested to guarantee coverage of every meaningful change in a release, eliminating both over-testing and under-testing.

***

### What Is Most-at-Risk?

When a release changes SAP objects (programs, functions, tables) SeaLights traces those changes through the full dependency graph and identifies which **used executables** (transactions, APIs, Fiori apps) are genuinely exposed. This list is then optimized to the minimal set of impacted executables known as the **Most-at-Risk list**.

It satisfies two hard constraints simultaneously:

* **Completeness**: every impactful changed object is reachable through at least one most-at-risk executable.
* **Minimality**: the number of most-at-risk executables is as small as possible.

The result: an average **84% reduction in test scope** with **100% coverage** of impactful changes.

***

### How It Works

Analysis runs in three sequential stages.

#### Stage 1 - Collect the Facts

SeaLights establishes two data sets:

* **Used Executables**: entry points (T-Codes, programs, APIs, Fiori apps) that real users have executed in the production system, sourced from the last 3 months of performance history. Executables never run in production do not qualify.
* **Changed Objects**: everything modified by the change: a transport, support pack, or custom development, read directly from the SAP change inventory.

{% hint style="warning" %}
**Brand-new executable have no usage history.** \
A new executable that has never run in production won't appear in the Used Executables set and would be invisible to this stage. The *New/Changed Executable* heuristic (see below) handles this case.
{% endhint %}

#### Stage 2 - Dependency Analysis

SeaLights navigates the full SAP object dependency graph, using table data and ABAP code scans, up to **10 dependency levels deep**, finding every path between a changed object and a used executable.

Output:

* **Impactful Changed Objects**: changed objects with at least one path to a used executable. Objects with no such path carry no user-facing risk and are dropped.
* **Impacted Executables**: used executables with at least one path to an impactful changed object.

{% hint style="info" %}
**Why not just test all impacted executables?** \
A single widely-used configuration table can have first-level dependencies on over 1,000 executables. Reporting all of them provides no prioritization — it's no better than "test everything." Stage 3 solves this.
{% endhint %}

#### Stage 3 - Most-at-Risk Optimization

SeaLights applies five heuristics in priority order to select the minimal set of impacted executables that satisfies both constraints. The first heuristic satisfied marks an executable as most-at-risk. If none apply, it is marked most-at-risk by default. Completeness is never sacrificed.

***

### The Five Heuristics

<table><thead><tr><th width="97.234375">Priority</th><th width="160.69921875">Heuristic</th><th>Logic</th></tr></thead><tbody><tr><td>1</td><td><strong>Business Critical</strong></td><td>Always marked most-at-risk when used, impacted, and registered in the Business Critical list — regardless of any other heuristic.</td></tr><tr><td>2</td><td><strong>New / Changed Executable</strong></td><td>Marks a brand-new changed object as most-at-risk even with zero production usage history, preventing new code from being silently skipped.</td></tr><tr><td>3</td><td><strong>Depth</strong></td><td>Prefers the impacted executable with the shortest dependency chain to the changed object. Closer = more directly exposed.</td></tr><tr><td>4</td><td><strong>Functional Cost</strong></td><td>Prefers executables whose SAP component hierarchy is closest to the changed object's component. A sales transaction is more meaningfully at risk from a sales-component change than a procurement transaction sharing only a distant technical dependency.</td></tr><tr><td>5</td><td><strong>Usage</strong></td><td>When depth and functional cost are equal, prefers the executable with the highest production usage count. Higher traffic means a larger blast radius from any defect.</td></tr></tbody></table>

***

### Test Coverage - Hits, Gaps & Optimal Tests

SeaLights cross-references the Most-at-Risk list against every connected test repository and assigns each object a coverage status.

<table><thead><tr><th width="93.921875">Status</th><th width="308.39453125">Meaning</th><th>Action</th></tr></thead><tbody><tr><td><strong>Hit</strong></td><td>A test covers this most-at-risk object.</td><td>Include it in the run.</td></tr><tr><td><strong>Gap</strong></td><td>No test exists.</td><td>Create one before the release is approved.</td></tr></tbody></table>

SeaLights also produces three test set views:

* **All**: every test that references any used exectuable.
* **Covering**: tests that cover at least one most-at-risk executable.
* **Optimal**: the smallest set that together covers every most-at-risk object, weighted by usage frequency. Typically **80–95% fewer tests** than *All*.

***

### Configuration

<table><thead><tr><th width="165.921875">Parameter</th><th>Purpose</th></tr></thead><tbody><tr><td><strong>Business Critical Executables</strong></td><td>CSV upload (TYPE, NAME columns). Executables listed here are always included in Most-at-Risk when used and impacted.</td></tr></tbody></table>

***

### FAQ

<details>

<summary><strong>What is the difference between "Impacted" and "Most-at-Risk"?</strong> </summary>

Impacted means a used executable has a dependency on at least one changed object. Most-at-Risk means SeaLights selected it as part of the minimal coverage set. Not all impacted executables become most-at-risk; if another executable covers the same changed object with a shorter dependency chain, the first is redundant and excluded.

</details>

<details>

<summary><strong>Why would a heavily-used T-Code not appear in the Most-at-Risk list?</strong> </summary>

High usage alone is not enough. An executable only becomes most-at-risk if there is a dependency path to at least one impactful changed object. If the current release doesn't touch that T-Code's dependency chain, it won't appear.

</details>

<details>

<summary><strong>What if one most-at-risk executable is reached by multiple changed objects?</strong> </summary>

SeaLights tracks all impactful changed objects per executable. A single test covering that executable exercises all of those changes simultaneously - a key driver of the overall test reduction ratio.

</details>


---

# 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-executables.md?ask=<question>&goal=<endgoal>
```

`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.