Capability Verification
Every Forge capability represents a formally defined computational contract.
Verification is therefore performed at the capability level rather than at the API level.
This document explains how to evaluate an individual capability using the same verification methodology introduced throughout this section.
Capability verification combines execution, validation, replay, runtime evidence, and artifacts into a single verification workflow.
Verification Objective
After completing this document you should be able to:
- identify the execution contract of a capability
- execute its maintained Canonical Smoke
- inspect the resulting runtime evidence
- verify capability-specific artifacts
- determine whether the capability behaves according to its documented contract
Prerequisites
Before continuing, complete:
- Verification Overview
- Canonical Smoke Suite
- First Verified Execution
- Inspect Result
- Replay & Determinism
- Negative Validation
- Artifact Inspection
You should already understand the general Forge verification methodology.
Verification Scope
Capability Verification answers a single question:
Does this capability satisfy its documented execution contract?
It does not attempt to compare different capabilities or evaluate domain correctness beyond the defined contract.
Capability Verification Lifecycle
Every capability should be evaluated using the same logical sequence.
Capability Contract
│
▼
Canonical Smoke
│
▼
Canonical Validation
│
▼
Execution
│
▼
Inspect Result
│
▼
Inspect Artifacts
│
▼
Replay
│
▼
Verification OutcomeThis lifecycle is independent of execution surface.
Step 1 — Understand the Capability Contract
Begin by reviewing the documented capability.
The capability contract defines:
- operation identity
- profile
- accepted arguments
- expected outputs
- supported artifacts
- execution constraints
- replay characteristics
Verification should always begin with the contract rather than the implementation.
Step 2 — Execute the Canonical Smoke
Every verifiable capability should expose at least one maintained Canonical Smoke.
The smoke represents the reference execution for that capability.
Verification documentation references this smoke instead of redefining execution payloads.
Step 3 — Verify Execution Acceptance
Confirm that:
- canonical validation succeeded
- execution was accepted
- a persistent execution identity was created
At this stage the capability has entered the execution runtime.
Step 4 — Inspect Runtime Evidence
Inspect:
- execution identity
- execution context
- runtime state
- result
- metrics
- replay metadata
- artifacts
The exact evidence depends on the capability being executed.
Step 5 — Verify Capability Artifacts
Capability-specific artifacts should match the documented execution contract.
Examples include:
- simulation summaries
- graph structures
- propagation paths
- confidence maps
- statistical distributions
Artifacts should be interpreted according to the capability documentation.
Step 6 — Verify Replay
Where replay is supported, execute the maintained replay verification workflow.
Replay should confirm:
- equivalent execution contract
- compatible replay metadata
- stable result surface
Replay extends confidence in the capability by demonstrating reproducibility.
Capability Verification Patterns
Different execution families emphasize different verification patterns.
| Execution Family | Primary Verification Focus |
|---|---|
| Monte Carlo | Statistical stability and replay |
| Search | Ranking consistency and evidence generation |
| Graph | Structural propagation and topology |
| Optimization | Candidate ordering and trade-offs |
| Insurance | Distribution and aggregate metrics |
| Climate | Simulation summaries and projections |
| Finance | Portfolio metrics and scenario analysis |
| Energy | Infrastructure behaviour and system metrics |
Although the domain differs, the verification methodology remains the same.
Verification Outcome
A capability is considered successfully verified when:
- its execution contract is satisfied
- canonical validation succeeds
- execution completes successfully
- runtime evidence is available
- expected artifacts are produced
- replay behaves according to the documented guarantees
Capability verification establishes confidence in the observable behaviour of a single computational contract.
Common Misinterpretations
"The API succeeded, therefore the capability is verified."
API success only confirms transport.
Capability verification evaluates the computational contract.
"Artifacts alone verify the capability."
Artifacts provide supporting evidence.
They do not replace execution verification.
"Replay is required for every capability."
Replay requirements depend on the documented capability contract.
Capabilities should only be evaluated against guarantees they explicitly provide.
"Different capabilities should produce identical evidence."
Each capability exposes its own evidence surface.
Verification compares a capability against its own documented contract rather than against unrelated execution families.
Capability Verification Checklist
Before considering a capability verified, confirm the following:
- Canonical Smoke executed successfully.
- Canonical validation accepted the request.
- Execution completed successfully.
- Runtime evidence was produced.
- Expected artifacts are available.
- Replay expectations were satisfied (where supported).
- Observed behaviour matches the documented capability contract.
Next Steps
The Verification methodology is now complete.
Continue with capability-specific examples:
Each example applies the same methodology to a concrete execution family.
Related Documentation
- Verification Overview
- Canonical Smoke Suite
- First Verified Execution
- Inspect Result
- Replay & Determinism
- Negative Validation
- Artifact Inspection
- Execution Model
Final Principle
Forge capabilities are verified through observable execution rather than implementation details.
A capability is considered trustworthy when its documented execution contract, runtime evidence, replay behaviour, and verification artifacts remain consistent under independent evaluation.