Verification

Forge documentation is not complete when the architecture is explained.

It is complete when an evaluator can run a workload, inspect the evidence, repeat the execution, and confirm that the runtime behaves as claimed.

The Verification section exists for that purpose.

It turns Forge documentation from explanation into independent evaluation.

Verification objective

After completing this section, an evaluator should be able to:

execute a maintained Forge smoke workload
inspect execution identity and runtime metadata
confirm that valid payloads execute successfully
confirm that invalid payloads fail before execution
inspect generated artifacts
compare deterministic executions
preserve replay and trace metadata for later investigation

Verification is not a replacement for Architecture, Guide, Trust, or Reference documentation.

It is the layer where claims become observable.

Core principle

Forge Verification is based on maintained execution examples.

A Verification example is canonical only when it originates from a smoke test, integration test, or maintained runtime example.

txt

Documentation example
        │
        ▼
Maintained smoke payload
        │
        ▼
Runtime execution
        │
        ▼
Observable result
        │
        ▼
Replay / inspection metadata

This prevents documentation drift.

If the runtime contract changes, the smoke test changes.

If the smoke test changes, the Verification documentation changes with it.

What Verification proves

Verification documentation helps establish that Forge can:

accept a canonical execution payload
validate the payload before execution
route the workload through the runtime
return execution metadata
produce result summaries
produce artifacts when requested
reject invalid payloads
reproduce deterministic workloads where supported

It does not ask the evaluator to trust the system narrative.

It exposes the execution surface directly.

Evidence chain

Every verified execution follows an evidence chain.

txt

Computational Intent
        │
        ▼
Execution Contract
        │
        ▼
Canonical Payload
        │
        ▼
Validation
        │
        ▼
Execution
        │
        ▼
Observation
        │
        ▼
Verification
        │
        ▼
Replay
        │
        ▼
Independent Confirmation

Not every document covers the full chain.

Each Verification document should clearly state which part of the chain it covers.

Verification categories

Forge uses several verification categories.

Canonical execution

Canonical execution confirms that a primitive runs successfully with a representative payload.

A canonical smoke should demonstrate:

valid operation identity
valid profile
valid arguments
explicit seed when relevant
test billing mode
successful execution
observable result
runtime metadata

Typical examples include Monte Carlo, Graph, Search, Ensemble, Insurance, Climate, Finance, Energy, and Reinsurance workloads.

Artifact verification

Artifact verification confirms that a workload produces the expected evidence surface.

Common artifact classes include:

summary
histogram
samples.preview
ranked_candidates
best_candidate
worst_case
mutation_trace
score_distribution
timeline
cascade_paths
critical_nodes
confidence
disagreement_map

Artifacts are not decorative outputs.

They are part of the runtime evidence surface.

Deterministic replay

Deterministic replay verifies that equivalent payloads produce stable result surfaces when the primitive supports deterministic execution.

The standard pattern is:

txt

same operation
same profile
same arguments
same seed
different job_id
        │
        ▼
compare stable result fields

Depending on primitive type, comparison may include:

summary.mean
summary.p95
summary.p99
histogram shape
best candidate identity
worst case identity
ranked count
candidate count
result hash
replay token
replay identity class

Replay verification should never imply stronger guarantees than the primitive formally supports.

Negative validation

Negative validation verifies that invalid payloads fail before execution.

This is as important as successful execution.

A runtime boundary is only meaningful if invalid contracts are rejected.

Negative smoke tests commonly check:

missing required fields
invalid enum values
invalid probability ranges
invalid graph edges
invalid ranking objectives
invalid horizon definitions
invalid attachment / limit / share values
invalid output modes

A successful negative test produces a controlled validation failure, not an execution result.

Capability verification

Capability verification confirms that a specific profile behaves according to its execution contract.

This usually combines:

txt

Capability Describe
        │
        ▼
Canonical Payload
        │
        ▼
Execution
        │
        ▼
Artifact Inspection
        │
        ▼
Replay / Validation

Capability verification is the preferred pattern for domain-specific examples.

Runtime evidence verification

Runtime evidence verification focuses on execution metadata rather than domain output.

Important fields include:

job_id
run_id
trace_id
request_id
surface_key
op_key
pricing_key
billing_mode
status
iterations
executions
metrics
result_hash
replay_token
artifacts

These fields connect a request to a tracked execution.

Verification surfaces

Forge exposes verification through multiple surfaces.

API

The API surface is useful for direct reproducibility.

It is the preferred surface for smoke suites and curl-based verification.

MCP

The MCP surface is useful for autonomous agent evaluation.

The expected flow is:

txt

discover
        │
        ▼
describe
        │
        ▼
execute
        │
        ▼
status
        │
        ▼
result

Agents should not invent payloads.

Agents should discover and describe capabilities before execution.

Studio

The Studio surface is useful for visual workflow verification.

Studio examples should focus on composition, execution, inspection, and artifacts.

Canonical smoke suite

The smoke suite is the canonical source for executable Verification examples.

A smoke entry should include:

profile name
operation name
version
payload
seed
policy
requested artifacts
expected success or failure
fields to inspect

Example smoke classes:

Class	Purpose
Canonical smoke	Confirms valid execution
Artifact-heavy smoke	Confirms artifact generation
Determinism smoke	Confirms stable replay surface
Negative validator smoke	Confirms invalid payload rejection
Alias smoke	Confirms compatibility aliases
Minimal smoke	Confirms primitive health with small payload

Documentation rule

Verification documents should not invent executable JSON.

Use one of these sources:

maintained smoke test
integration test
production-safe runtime example
capability contract returned by the system

If none exists, create the smoke test first.

Then document it.

Recommended verification path

First-time evaluators should follow this path:

txt

Verification Overview
        │
        ▼
Smoke Suite
        │
        ▼
First Verified Execution
        │
        ▼
Inspect Result
        │
        ▼
Artifact Inspection
        │
        ▼
Replay and Determinism
        │
        ▼
Negative Validation

This path moves from observation to confidence without requiring internal knowledge of the runtime.

What this section does not cover

This section does not explain:

full runtime architecture
pricing internals
provider economics
scheduling internals
full API reference
Studio workflow authoring
enterprise deployment
primitive implementation details

Those topics belong elsewhere.

Verification focuses on independently observable execution.

Final mental model

Architecture explains Forge.

Trust justifies Forge.

Guide enables Forge.

API specifies Forge.

Verification proves Forge.

If an evaluator cannot run it, inspect it, compare it, or replay it, it does not belong in Verification.

Verification ​

Verification objective ​

Core principle ​

What Verification proves ​

Evidence chain ​

Verification categories ​

Canonical execution ​

Artifact verification ​

Deterministic replay ​

Negative validation ​

Capability verification ​

Runtime evidence verification ​

Verification surfaces ​

API ​

MCP ​

Studio ​

Canonical smoke suite ​

Documentation rule ​

Recommended verification path ​

What this section does not cover ​

Related documentation ​

Final mental model ​