Validation Level

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 invests in verifying each milestone — the build-and-run lifecycle, functional testing, 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 — at the cost of more upfront configuration and longer milestone runs.

---

​

The Three Levels at a Glance

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, so deviations from the behavior described in your spec go undetected.
• No 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 — tests are generated and executed against the migrated app to confirm it behaves sensibly.
• Target-only 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 — 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 — 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).

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.

---

​

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.

---

​

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.

​

Upgrading

When you upgrade to a higher level: 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. 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.

​

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