Negative Validation
A reliable execution platform is defined not only by the workloads it accepts, but also by the workloads it refuses to execute.
Forge performs canonical validation before an execution request enters the distributed runtime.
This document explains how invalid execution contracts are rejected, what a validation failure demonstrates, and why negative validation is a fundamental part of the Forge verification model.
Unlike execution failures, validation failures occur before execution begins.
No workload is planned, dispatched, or executed until the execution contract satisfies canonical validation.
Verification Objective
After completing this document you should understand:
- why canonical validation exists
- what constitutes an invalid execution contract
- how validation differs from runtime execution
- what successful negative validation proves
- how validation protects the execution runtime
Prerequisites
Before continuing, complete:
You should already understand the normal execution lifecycle before examining validation failures.
Validation Boundary
Canonical validation is the boundary between an execution request and the execution runtime.
Canonical Execution Request
│
▼
Canonical Validation
┌─────┴─────┐
│ │
▼ ▼
Accepted Rejected
│
▼
Execution RuntimeOnly validated execution contracts are allowed to enter the runtime.
Why Validation Exists
Canonical validation exists to ensure that every execution entering the runtime is structurally complete, internally consistent, and compatible with the selected capability.
Validation protects:
- execution planning
- distributed scheduling
- primitive execution
- artifact generation
- replay
- result reduction
Rejecting an invalid execution contract is considered a successful verification outcome.
Validation vs Execution
Validation and execution are independent stages.
| Validation | Execution |
|---|---|
| Verifies the execution contract | Performs computation |
| Executes before runtime | Executes inside runtime |
| Rejects invalid requests | Produces computational results |
| Returns validation diagnostics | Returns execution evidence |
Validation failure should never be interpreted as runtime failure.
Common Validation Categories
The Canonical Execution Validator evaluates multiple aspects of an execution request before runtime admission.
Representative validation categories include:
Required Fields
Required execution fields must be present.
Examples include:
- operation identity
- profile
- required arguments
- execution policy
Profile Compatibility
Arguments must satisfy the selected execution profile.
Validation ensures that profile-specific contracts remain internally consistent.
Enumeration Validation
Fields constrained by canonical enumerations must contain supported values.
Unknown or unsupported values are rejected before execution.
Type Validation
Execution arguments must satisfy their canonical data types.
Examples include:
- numeric values
- boolean values
- structured objects
- collections
Constraint Validation
Canonical constraints are evaluated before runtime.
Representative constraints include:
- valid probability ranges
- supported iteration limits
- permitted optimization objectives
- supported artifact configuration
- compatible execution modes
Capability Validation
Validation confirms that the requested capability exists and supports the submitted execution contract.
Capabilities are validated before planning begins.
Expected Validation Outcome
A successful negative validation demonstrates that:
- the request was inspected
- canonical validation was executed
- invalid execution was rejected
- runtime execution never began
Observable characteristics include:
- validation response
- validation diagnostics
- rejected execution contract
There should be:
- no distributed planning
- no workload dispatch
- no primitive execution
- no runtime artifacts
What Negative Validation Proves
A successful validation failure demonstrates that:
- execution boundaries are enforced
- invalid contracts cannot enter the runtime
- capability contracts are actively protected
- canonical validation operates independently of execution
This is a critical property of a production execution platform.
What Negative Validation Does Not Prove
Validation should not be interpreted as evidence that:
- the workload would have executed successfully
- computational correctness has been verified
- replay compatibility has been established
- artifact generation would have succeeded
Validation only evaluates the execution contract.
Common Validation Misinterpretations
"The Runtime Failed"
A validation failure is not a runtime failure.
The workload never entered the runtime.
"The Primitive Failed"
Validation occurs before primitive selection and execution.
No primitive has executed.
"Validation Is Optional"
Canonical validation is part of the execution contract.
Every execution surface ultimately depends on the same validation boundary.
"Different Surfaces Validate Differently"
Execution surfaces may differ in user experience.
They should not differ in canonical validation behavior.
Equivalent execution contracts should receive equivalent validation outcomes.
Validation Across Execution Surfaces
Canonical validation is independent of the execution surface.
Equivalent requests submitted through:
- Web Core API
- Studio
- MCP
should produce equivalent validation outcomes.
Validation belongs to the execution contract rather than the interface used to submit it.
Verification Outcome
Negative validation demonstrates that Forge protects the execution runtime by refusing invalid computational contracts before they consume execution resources.
Successful validation rejection is therefore considered a successful verification result.
A platform that only demonstrates successful execution remains partially verified.
A platform that demonstrates both successful execution and correct rejection of invalid execution contracts provides a substantially stronger verification model.
Next Steps
Continue with:
Related Documentation
- Verification Overview
- Canonical Smoke Suite
- First Verified Execution
- Inspect Result
- Replay & Determinism
- Execution Model
- Execution API
- Trust Overview
Final Principle
A production execution platform is verified not only by the computations it performs, but also by the execution contracts it refuses to execute.
Canonical validation establishes the trust boundary between user intent and distributed computation.
Every accepted execution crosses that boundary.
Every rejected execution demonstrates that the boundary exists.