First Verified Execution
This document demonstrates how to independently verify a successful Forge execution.
Unlike the Quickstart guide, which introduces the platform and shows how to submit workloads, this document focuses on observable runtime evidence.
The objective is not simply to execute a workload.
The objective is to verify that Forge accepted the request, executed it through the runtime, persisted its execution state, and produced evidence that can be independently inspected.
The execution demonstrated here should always originate from a maintained Canonical Smoke described in the Verification Artifact Registry.
Verification Objective
After completing this document you should be able to independently verify that:
- a canonical execution request was accepted
- the execution contract was successfully validated
- a Forge Job was created
- the workload entered the execution runtime
- execution completed successfully
- runtime evidence was produced
- execution can be inspected using its execution identity
This document establishes the foundation for every subsequent Verification guide.
Prerequisites
This document assumes that you have already completed:
- Guide → Quickstart
- Verification → Canonical Smoke Suite
You should already have:
- a Forge account
- a project
- an API key
- access to at least one execution surface
- a maintained Canonical Smoke
Verification Scope
This document verifies:
- execution submission
- execution acceptance
- execution lifecycle
- execution identity
- runtime evidence
- result retrieval
This document intentionally does not cover:
- deterministic replay
- artifact interpretation
- distributed scheduling
- planner internals
- aggregation internals
- heterogeneous execution
- execution performance analysis
Those topics are covered by subsequent Verification documents.
Canonical Execution Journey
Every Forge execution follows the same logical lifecycle regardless of the execution surface.
Canonical Smoke
│
▼
Canonical Execution Request
│
▼
Canonical Validation
│
▼
Execution Accepted
│
▼
Forge Job Created
│
▼
Hub Dispatch
│
▼
Runtime Execution
│
▼
Execution Completed
│
▼
Runtime EvidenceWhether execution originates from Web Core, Studio, MCP, or future SDKs, the execution lifecycle remains the same.
Execution Surfaces
Forge currently exposes multiple execution surfaces.
| Surface | Primary Purpose |
|---|---|
| Web Core API | Direct application integration |
| Studio | Visual workflow composition and execution |
| MCP | Agent-native execution and orchestration |
Each surface eventually submits the same canonical execution request into the Forge runtime.
Verification therefore focuses on the execution lifecycle rather than on a specific interface.
Execution Stage — Select a Canonical Smoke
Verification always begins with a maintained Canonical Smoke.
The smoke defines:
- execution family
- primitive
- profile
- canonical arguments
- execution policy
- requested artifacts
- expected verification outcome
Smoke payloads are maintained together with the runtime and should be treated as the canonical source of executable examples.
Verification documentation explains those examples rather than redefining them.
Execution Stage — Submit the Canonical Execution
Submit the maintained Canonical Smoke using your preferred execution surface.
During submission Forge performs canonical validation before the workload enters the runtime.
Successful validation indicates that the execution contract is complete and internally consistent.
Execution submission does not immediately execute the workload.
It creates an execution request that enters the Forge execution pipeline.
Execution Stage — Execution Accepted
A successful submission should produce an accepted execution.
Expected observations include:
- accepted HTTP response
- execution status
- job identifier
- request identifier
- trace identifier
At this stage the workload has been accepted for execution.
Completion has not yet occurred.
Execution Stage — Observe the Job Lifecycle
Once accepted, the workload progresses through the execution runtime.
Typical lifecycle:
Queued
│
▼
Planning
│
▼
Dispatch
│
▼
Execution
│
▼
Reduction
│
▼
CompletedThe duration of each stage depends on workload complexity, execution policy, and runtime conditions.
The logical lifecycle remains consistent across execution surfaces.
Execution Stage — Retrieve the Result
After execution completes, retrieve the execution result using the same execution identity.
At minimum, the result should allow you to identify:
- the executed workload
- execution status
- execution metadata
- runtime result
- generated artifacts (when requested)
The result represents the observable output of the execution runtime.
Execution Stage — Inspect Runtime Evidence
Verification begins after execution completes.
Typical runtime evidence includes:
- execution identity
- job identifier
- run identifier
- trace identifier
- request identifier
- execution status
- runtime metrics
- execution slices
- generated artifacts
- replay metadata
- execution summary
Do not attempt to interpret every field during the first execution.
The purpose of this document is to establish that observable evidence exists.
Subsequent Verification documents explain each evidence surface in detail.
Expected Runtime Observations
A successful first execution should demonstrate all of the following:
| Observation | Expected Outcome |
|---|---|
| Canonical validation | Successful |
| Execution accepted | Successful |
| Job creation | Successful |
| Runtime execution | Successful |
| Execution completion | Successful |
| Result retrieval | Successful |
| Runtime evidence | Present |
Any deviation from these observations should be investigated before proceeding to replay or artifact verification.
What This Execution Proves
Completing this verification demonstrates that:
- Forge accepted a canonical execution request.
- The execution contract passed canonical validation.
- A persistent execution identity was created.
- The workload entered the distributed execution runtime.
- Runtime execution completed successfully.
- Execution evidence was preserved.
- Execution results can be independently inspected.
Importantly, this verification does not require knowledge of the internal execution architecture.
The observable runtime behavior is sufficient to establish that the execution pipeline operated successfully.
Common Failure Modes
Unexpected behavior during the first verification typically falls into one of four categories.
Validation Failure
The execution contract does not satisfy canonical validation requirements.
Review the capability contract and the maintained Canonical Smoke.
Authorization Failure
The submitted execution surface does not have permission to execute the requested workload.
Verify project credentials and execution permissions.
Runtime Failure
Execution entered the runtime but did not complete successfully.
Inspect the execution status and runtime metadata before retrying.
Artifact Mismatch
Execution completed successfully but expected artifacts were not produced.
Verify the requested artifact configuration defined by the Canonical Smoke.
Next Steps
Your first successful execution establishes that the runtime is operational.
The following Verification documents explain how to inspect the evidence produced by that execution.
Continue with:
- Inspect Result
- Artifact Inspection
- Replay & Determinism
- Negative Validation
- Capability Verification
Each document expands the evidence established by this first execution without introducing new execution concepts.
Related Documentation
- Guide → Quickstart
- Verification → Canonical Smoke Suite
- Verification → Inspect Result
- Verification → Replay & Determinism
- API → Execution Model
- API → Execute
- API → Replay
- Trust → Verification
Final Principle
The purpose of a first verified execution is not to prove that Forge can execute a workload.
It is to prove that the execution produced observable evidence which can be independently inspected, validated, and used as the foundation for all subsequent verification activities.