> ## Documentation Index
> Fetch the complete documentation index at: https://docs.modelcode.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Validation Level
> Choose how thoroughly Morph validates each milestone — trading speed against stronger guarantees that the modernized app behaves like intended
export const ProductName = "The Morph Platform";
export const productName = "the Morph Platform";
Every migration faces the same tradeoff: move fast, or prove correctness. The **validation level** is a single project-wide setting that lets you decide where you sit on that spectrum. It controls how much work {productName} invests in verifying each milestone — the build-and-run lifecycle, [functional testing](/migration/functional-testing), [acceptance criteria](/setup/build-environment/acceptance-criteria), and source environment setup.
A lower level moves faster and requires less setup. A higher level gives you stronger, evidence-backed guarantees that the modernized app behaves as described in your [project spec](/setup/reviewing-project-spec) — at the cost of more upfront configuration and longer milestone runs.
Validation level applies to the **whole project** and affects **every milestone**. You set it once during onboarding and can change it later from the project overview.
***
## The Three Levels at a Glance
| Dimension | Low — Fast | Medium — Balanced | High — Thorough |
| ----------------------------------------------------------------------- | ------------- | --------------------------- | ------------------------------------- |
| **Target build + unit tests** | ✅ Best-effort | ✅ | ✅ |
| **Full target lifecycle** (run, health checks) | ❌ | ✅ | ✅ |
| **[Functional testing](/migration/functional-testing)** | ❌ Off | ⚠️ Target-only | ✅ Full (baseline captured + verified) |
| **[Acceptance criteria](/setup/build-environment/acceptance-criteria)** | ❌ None | ⚠️ Target-only (you author) | ✅ Full (baseline captured + verified) |
| **Source environment setup** | ❌ | ❌ | ✅ Upfront |
| **Speed** | 🚀 Fastest | ⚖️ Balanced | 🐢 Slowest |
| **Confidence** | Low | Medium | High |
Each level is a strict superset of the one below it — Medium does everything Low does and more, and High does everything Medium does and more.
***
## Low — Fast
The fastest path. Morph builds the target and runs unit tests each milestone on a best-effort basis, then moves on.
**What you gain**
* The shortest milestone runtimes and the quickest route to a complete roadmap.
* No environment setup required before you start.
**What you give up**
* No app-run or health-check lifecycle — the migrated app is never actually started and exercised.
* No [functional testing](/migration/functional-testing), so deviations from the behavior described in your spec go undetected.
* No [acceptance criteria](/setup/build-environment/acceptance-criteria) — there is no formal definition of "done" beyond compilation and unit tests.
**Best for** prototypes, throwaway experiments, internal tooling, or migrations where you intend to validate behavior yourself downstream.
***
## Medium — Balanced
A middle ground that proves the target actually runs, without requiring Morph to stand up your source application's environment.
**What you gain**
* Everything in Low, plus the **full target lifecycle**: Morph builds, runs, and health-checks the migrated app each milestone.
* **Target-only [functional testing](/migration/functional-testing)** — tests are generated and executed against the migrated app to confirm it behaves sensibly.
* **Target-only [acceptance criteria](/setup/build-environment/acceptance-criteria)** — you author absolute-threshold quality gates (for example, "line coverage ≥ 80%") that Morph enforces on the target.
**What you give up**
* No **captured baseline**. Tests and acceptance criteria confirm the modernized app works and meets the thresholds you author, but Morph never observes the source app's real behavior — so you define what "correct" means up front, rather than having it captured for you.
* No source environment setup.
**Best for** greenfield-style rewrites, projects where the source app can't be run, or cases where confirming the app runs and meets your authored thresholds is enough.
***
## High — Thorough
The strongest guarantee. Morph sets up your **source** application upfront, captures its real behavior as a baseline, and verifies the modernized app behaves as the spec describes.
**What you gain**
* Everything in Medium, plus **upfront source environment setup** so the source app can be run and observed.
* **Full [functional testing](/migration/functional-testing)** — Morph captures a behavioral baseline from your source app, runs the modernized app, and verifies it behaves as the spec describes, surfacing any regression side by side.
* **Full [acceptance criteria](/setup/build-environment/acceptance-criteria)** — Morph discovers metrics on the source app, captures their baseline values, and translates them into target-side gates, on top of any criteria you author.
**What you give up**
* The most setup effort and the longest milestone runtimes.
* You must provide enough detail for Morph to stand up the source environment (dependencies, run commands, credentials, and so on).
High validation is the recommended default for production migrations where behaving exactly as the spec describes is a hard requirement.
**Best for** production migrations, regulated or business-critical systems, and any project where "the modernized system must behave exactly as specified" is non-negotiable.
***
## Choosing the Right Level
Ask yourself two questions:
1. **Does the modernized app need to behave *exactly* as described in the spec?** If yes, choose **High** — it's the only level that captures a behavioral baseline from your source app and verifies against it.
2. **Can your source application be run in an environment Morph can access?** If no, **High** isn't viable; choose **Medium** to still validate that the target runs and meets your authored thresholds.
If neither equivalence nor runtime validation matters — you only need code that compiles and passes unit tests — choose **Low** for the fastest path.
| Your priority | Recommended level |
| ------------------------------------------------------------- | ----------------- |
| Behaving exactly as described in the spec | **High** |
| Confidence the target runs correctly, no source app available | **Medium** |
| Maximum speed, minimal setup | **Low** |
***
## Setting the Validation Level
You configure the validation level from the **Validation Level** panel in the project overview. During onboarding it appears as a guided next step.
From the project overview, open the **Validation Level** configuration panel.
Select **Low**, **Medium**, or **High**. The panel summarizes what each option includes so you can compare the tradeoffs in context.
Saving applies the level to the entire project and every milestone in it.
If you choose **High**, Morph opens a short setup chat to capture your source environment details and acceptance criteria. This is what lets Morph baseline the source app and verify the modernized app against the spec.
If you don't pick a level, projects default to **High** — the safest choice when behavioral equivalence matters. Your organization may configure a different default.
***
## Per-Milestone Validation Indicator
Each milestone card on the Roadmap shows a small **validation level indicator** below its title — a bar-chart icon with a label (Low, Mid, or High). This indicates the **effective validation level** that is currently applied and with which the milestone will run.
The effective level is determined by:
* The milestone's own recorded validation level (stamped at execution time), **or**
* The project-level validation level (if the milestone hasn't run yet).
This lets you see at a glance which milestones were validated at which depth — especially useful after changing the level mid-project.
***
## Changing the Level Between Milestones
You can upgrade or downgrade the validation level between milestones. Open the Validation Level panel, select a new level, and click **Save**. A confirmation dialog explains what will happen before any change is applied.
The validation level cannot be changed while a milestone is currently in progress. Wait for the running milestone to complete before adjusting.
### Upgrading
When you upgrade to a higher level:
| Scenario | What happens |
| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **No milestones merged yet** | The new level applies to the next milestone. No extra action needed. |
| **Milestones already merged (upgrade to Medium)** | {ProductName} automatically launches an **ad-hoc validation run** on the last merged milestone to cover the functional tests and acceptance criteria that the lower level skipped. |
| **Upgrade to High** | A short setup chat opens first to capture origin environment details and acceptance criteria. After setup completes, an ad-hoc validation run is launched on the last merged milestone. |
The ad-hoc validation run appears on the Roadmap as a numbered validation milestone (e.g., "Validation 1.1") and must complete before the next standard milestone can start.
### Downgrading
Lowering the validation level reduces checks for **future** milestones only. Completed milestones are not affected — their validation results stay as-is.
***
## On-Demand Validation Rerun
After a milestone is merged, you may see a **Rerun Validation Suite** button appear between milestones on the Roadmap. This lets you retroactively validate a merged milestone at the project's current validation level.
### When It Appears
The rerun trigger is shown when **all** of these conditions are true:
* The previous milestone is merged.
* The project's current validation level is higher than the level recorded on that milestone.
* No ad-hoc validation is already running or pending for that milestone.
* The next standard milestone hasn't started yet.
### How It Works
1. Click **Rerun Validation Suite** on the divider between milestones.
2. {ProductName} creates an ad-hoc validation milestone (e.g., "Validation 2.1") that reruns the full validation suite at the project's current level.
3. The ad-hoc milestone appears in the Roadmap and shows progress like any milestone — with review tasks, test results, and status badges.
4. The next standard milestone is blocked until the ad-hoc validation completes.
The rerun button requires the `executions:create` permission. If you don't see it, check with your workspace admin.
### If a Validation Run Fails
If the ad-hoc validation encounters an error, the milestone card shows a failure alert with a **Retry** button. Click it to re-run the validation suite without creating a new milestone.
***
## Related Docs
How Morph generates, runs, and compares functional tests
Quantitative quality gates enforced on every milestone
Configure how your project builds and runs
The three-step process that validation level shapes