> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/codev/concepts/validation.md).
# Validation
Validation answers one question before a change merges: will it deploy and pass its tests? codev validates by **actually deploying the changed packages to a real org** — a review environment — and running the Apex tests there. The review environment is either fetched from a pool or a dedicated environment set aside for review. This differs from check-only deployment: what passed validation has genuinely deployed somewhere once already.
You meet validation in three places: the checks on a pull request, the per-commit **Validate** action in [Source Control](/flxbl/codev/development/development-workflow.md#validate-a-commit), and the results under [Change Validation](/flxbl/codev/inspect/change-validation.md) and [Validation Reports](/flxbl/codev/development/validation-and-pull-requests.md).
## What a validation run does
1. Acquires the review environment — fetched from the configured pool, or the dedicated environment chosen for the run.
2. Identifies the **changed packages** — scoped to the domain's release configuration, so only packages of that domain validate.
3. Deploys the changed packages to the environment, respecting dependencies.
4. Runs the Apex tests and checks each package's coverage (default threshold 75%).
5. Reports the outcome — deployment errors, test failures, coverage warnings — as the check or report you see.
## It validates the merge result
Validation does not test your branch as it stands — it merges the target branch into a temporary copy first and validates the **merge result**, what the code will look like once the pull request merges. A merge conflict between the branches fails validation at this step: the same conflict the merge would hit, surfaced earlier.
## It validates what you will actually ship
By default, validation applies the same [component checksum skip](/flxbl/codev/concepts/package-installation.md#only-changed-components-deploy) a release applies: for a changed package, only the components that differ from the previously installed version are deployed. The validation payload therefore matches the release payload.
Checksum skip during validation is controlled from the validation settings — per project, environment, or target branch.
Validation deploys real source to a real org, so it does not depend on a package type's build-time validation — a source package is validated to the same depth as an unlocked one. The trade-offs between types: [Choosing a package type](https://docs.flxbl.io/flxbl/techniques/development-practices/choosing-a-package-type).
## Modes
| Mode | What it does |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **Thorough** (default) | Deploys the changed packages with their dependencies in full and runs all tests. |
| **Individual** | Identifies the changed packages and validates each individually, ignoring what is already installed in the environment. |
Full detail — pool behaviour and the exact sequence of activities: [Validating a change](https://docs.flxbl.io/flxbl/sfp/validating-a-change/overview) · [Different types of validation](https://docs.flxbl.io/flxbl/sfp/validating-a-change/different-types-of-validation).
---
# 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.flxbl.io/flxbl/codev/concepts/validation.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.