Inspect Result
A successful execution produces more than a domain result.
It produces runtime evidence.
This document explains how to inspect that evidence and understand what it demonstrates.
Unlike API Reference documentation, this guide does not describe response schemas.
Instead, it explains how to interpret the observable execution surfaces produced by Forge.
Verification Objective
After completing this document you should be able to:
- identify the primary execution evidence
- distinguish execution identity from execution output
- inspect runtime metadata
- recognize generated artifacts
- understand replay metadata
- determine what an execution proves
- recognize the limits of observable evidence
Prerequisites
This document assumes that you have completed:
- Verification → First Verified Execution
You should already have access to a completed execution.
Result as Evidence
A Forge result should be viewed as a collection of independent evidence surfaces.
Execution Result
│
├── Execution Identity
├── Execution Context
├── Runtime State
├── Result
├── Artifacts
├── Metrics
└── Replay MetadataEach surface answers a different verification question.
Evidence Surface — Execution Identity
Execution identity uniquely identifies a completed workload.
Typical identifiers include:
- job identifier
- run identifier
- request identifier
- trace identifier
What it proves
Execution identity proves that Forge accepted and tracked a unique execution.
What it does not prove
Execution identity alone does not prove that the computational result is correct.
It proves only that the execution exists.
Evidence Surface — Execution Context
Execution context describes the workload that entered the runtime.
Typical context includes:
- operation
- primitive
- profile
- execution surface
- execution policy
- billing mode
What it proves
Execution context proves which execution contract entered the runtime.
What it does not prove
Execution context does not prove successful execution.
It describes the submitted request rather than the produced result.
Evidence Surface — Runtime State
Runtime state describes the lifecycle of the execution.
Typical observations include:
- queued
- planning
- dispatch
- running
- reducing
- completed
- failed
What it proves
Runtime state demonstrates that the workload progressed through the execution pipeline.
What it does not prove
Runtime state does not explain internal scheduling decisions or execution topology.
Evidence Surface — Result
The result contains the domain-specific computational output.
Its structure depends on the executed capability.
Examples include:
- simulation summaries
- ranked candidates
- graph propagation
- portfolio metrics
- climate projections
- insurance loss distributions
What it proves
The result demonstrates the observable output produced by the execution runtime.
What it does not prove
The result alone does not explain how the runtime produced that output.
Evidence Surface — Runtime Metrics
Runtime metrics describe characteristics of the execution rather than the business result.
Examples may include:
- execution duration
- iteration count
- processed workload size
- execution slices
- reduction statistics
What it proves
Metrics demonstrate observable runtime behavior.
What it does not prove
Metrics should not be interpreted as correctness guarantees.
Evidence Surface — Artifacts
Artifacts preserve additional execution evidence beyond the primary result.
Depending on capability, artifacts may include:
- summaries
- histograms
- timelines
- propagation paths
- candidate rankings
- confidence maps
- disagreement maps
- execution previews
What it proves
Artifacts preserve additional observable evidence generated during execution.
What it does not prove
Artifacts should not be interpreted independently from the execution context.
Evidence Surface — Replay Metadata
Replay metadata identifies information required for later verification.
Typical replay evidence may include:
- replay identifiers
- deterministic seed
- replay token
- result hash
- execution signature
What it proves
Replay metadata enables future comparison between equivalent executions.
What it does not prove
Replay metadata does not itself guarantee deterministic equivalence.
That comparison is covered separately.
Reading Evidence Correctly
Verification should proceed from identity toward interpretation.
Recommended inspection order:
Execution Identity
│
▼
Execution Context
│
▼
Runtime State
│
▼
Result
│
▼
Artifacts
│
▼
Replay MetadataAvoid interpreting replay or artifacts before confirming execution identity and successful completion.
What This Result Proves
A completed Forge result allows an evaluator to independently verify that:
- a workload entered the runtime
- execution completed
- runtime evidence was preserved
- computational output was produced
- execution metadata can be inspected
- future replay remains possible where supported
Common Misinterpretations
Treating execution identity as computational proof
Execution identifiers prove execution occurred.
They do not prove domain correctness.
Ignoring execution context
Results should always be interpreted together with the execution contract that produced them.
Comparing artifacts across unrelated executions
Artifacts should only be compared between equivalent execution contracts.
Confusing replay metadata with replay verification
Replay metadata enables replay.
Replay verification demonstrates replay.
These are separate verification stages.
Next Steps
Now that you understand how to inspect execution evidence, continue with:
- Replay & Determinism
- Artifact Inspection
- Negative Validation
- Capability Verification
These documents build directly upon the evidence surfaces introduced here.
Related Documentation
- Verification → First Verified Execution
- Verification → Replay & Determinism
- Verification → Artifact Inspection
- Verification → Negative Validation
- API → Execution Model
- Trust → Verification
Final Principle
A Forge execution should never be evaluated solely by its computational output.
Execution identity, runtime state, metrics, artifacts, and replay metadata collectively form the observable evidence required for independent verification.