> 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.md). # Day Zero: Structural Analysis (no execution history required) ## Day Zero: Structural Analysis ### High-Level Description #### Core Capability Day Zero is the phase that begins the moment a test cycle is created — before any test has run. Using only structural analysis of the SAP system (dependency relationships, object metadata, and production usage patterns), SeaLights produces a complete change impact assessment and an optimized test recommendation in three automated steps. No execution history, no prior baseline, and no manual triage are required to get value. #### Interface Experience and Navigation Day Zero outputs are visible immediately after cycle creation across all three result tabs: **Change Analysis** (what changed and what's at risk), **Tests to Run** (which tests to execute), and **Test Gaps** (what has no test at all). There is no separate Day Zero view — the three tabs are its output. The analysis runs entirely in the background; the team's first interaction is reading the results. *** ### Business Value & Key Use Cases * **Value from cycle one** — Teams that have never used SeaLights before get a prioritized test recommendation on their very first cycle, against their existing test repository, with no setup beyond connecting the landscape and test repository. * **Replacing manual impact assessment** — Change impact analysis that would take a senior SAP architect hours to produce manually — tracing which programs depend on which changed objects — is produced automatically in minutes. * **Objective, auditable risk ranking** — Risk prioritization is based on defined, consistent heuristics rather than individual judgment, making the process repeatable and defensible to auditors and governance boards. #### Impact Metrics Day Zero structural analysis converts a raw transport import into a prioritized test plan — covering change impact, test recommendations, and gap identification — within minutes of cycle creation, across repositories of thousands of tests, with no human triage step. *** ### Detailed Functionality #### The Three Steps Day Zero runs three steps in sequence, each building on the output of the previous: **Step 1 — Build the Dependency Map** SeaLights reads the list of ABAP objects changed by the cycle's transports and maps them to the production-active executables that depend on them. The map is intentionally narrow: only objects that actually changed, only executables that are actively used in production. This focus eliminates noise from unused code and unchanged objects. → [Step 1 in detail: Building the Dependency Map](https://claude.ai/chat/how-02-dependency-map.md) **Step 2 — Rank Most-At-Risk Executables** From the dependency map, SeaLights ranks every impacted executable from most to least at risk using five heuristics applied in priority order — Business Criticality, New or Changed Executable, Dependency Depth, Functional Relevance, and Usage Frequency. The output is the Most-At-Risk set: the executables that must be verified in this cycle. → [Step 2 in detail: Most-At-Risk Ranking](https://claude.ai/chat/how-03-most-at-risk-ranking.md) **Step 3 — Build the Optimal Test Set** SeaLights maps every test in the connected repository to the Most-At-Risk executables. It identifies the covering tests (any test that exercises at least one most-at-risk executable) and calculates the optimal sub-set: the minimum combination of covering tests that guarantees every most-at-risk executable is verified at least once. → [Step 3 in detail: Building the Optimal Test Set](https://claude.ai/chat/how-04-optimal-test-set.md) #### What Day Zero Does Not Do Day Zero makes no claim about what tests actually exercise at runtime. It predicts coverage based on structural relationships — which executables call which objects, which tests are mapped to which executables. Whether a predicted link is real is confirmed (or corrected) by Day One Onward once tests execute. This distinction matters: a green test run on Day Zero recommendations means every most-at-risk executable was targeted by a test. It does not yet mean every most-at-risk executable was actually exercised. That confirmation comes from Day One Onward. *** ### FAQ **Q: How accurate are Day Zero recommendations without any execution history?** A: Structural analysis produces a strong first approximation — it correctly identifies which executables are in the blast radius of a change and which tests are structurally linked to them. The primary limitation is that structural links (executable A calls object B) do not always mean a test exercises that path at runtime. Day One Onward removes false positives over time. In practice, Day Zero recommendations are immediately actionable and meaningfully better than running the full test suite. **Q: Does Day Zero need to be re-run if transports are added?** A: Transport scope is fixed at cycle creation, so Day Zero does not re-run for an existing cycle. To analyze additional transports, create a new cycle using Carry Over. **Q: How long does Day Zero take to complete?** A: \[Configuration detail pending validation — completion time depends on transport volume and object count. In observed usage, results appear within minutes for typical cycle sizes.] *** *Part of the* [*How SeaLights Works*](https://claude.ai/chat/how-00-how-sealights-works.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.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.