Verification
Distributed execution is valuable only while independent parties can later determine whether the recorded execution faithfully represents the computation that was requested.
Forge therefore treats verification as part of execution itself rather than as a post-processing integrity check.
Verification exists to establish computational confidence without requiring trust in any individual execution node.
Why Verification Exists
Distributed systems operate across infrastructure that is heterogeneous, geographically distributed, and only partially trusted.
Individual execution agents may differ in hardware, software, reliability, availability, or operational behavior.
Rather than assuming perfect infrastructure, Forge assumes mixed-trust participation and preserves sufficient execution evidence to evaluate computational integrity independently of any single participant.
Verification exists to ensure that execution remains explainable, reproducible, and defensible long after computation has completed.
Core Principle
Agents execute work.
They do not define computational truth.
The Hub remains responsible for:
- execution planning
- shard construction
- verification policy
- deterministic reduction
- replay metadata
- final result materialization
This separation is fundamental to the execution model.
A compromised, faulty, unstable, or malicious agent may influence an individual shard attempt.
It must not be able to silently determine the final computational result.
Verification as Execution Semantics
Verification is not an optional integrity feature layered on top of execution.
Verification defines how execution becomes trustworthy.
Every verification policy implicitly determines:
- what evidence must be preserved
- what redundancy is required
- what validation must occur
- what replay information survives execution
- what level of computational confidence may be established
Changing verification policy therefore changes execution semantics—not merely execution cost.
Threat Model
Forge verification addresses practical execution failures including:
- fabricated shard outputs
- unstable hardware behavior
- nondeterministic execution drift
- interrupted or manipulated execution
- incorrect execution accounting
- partial execution presented as completed work
- implementation defects inside workload handlers
The objective is not to eliminate every possible failure.
The objective is to make incorrect execution increasingly difficult to hide and increasingly straightforward to investigate.
Verification in the Execution Path
Verification is integrated into the canonical Kernel execution flow.
Execution Contract
↓
Deterministic Shard Planning
↓
Distributed Execution
↓
Verification
↓
Deterministic Reduction
↓
Replay & Artifact PreservationVerification occurs before final result materialization.
Invalid or suspicious shard outputs may be rejected, retried, compared, down-scored, or escalated according to the selected execution policy.
Verification Begins with the Execution Contract
Verification starts before the first shard is executed.
It begins when the execution contract becomes immutable.
Every subsequent execution decision is evaluated relative to that contract.
The execution contract establishes the computational identity against which replay, verification, benchmarking, billing, and audit are later performed.
See:
Verification Policies
Forge supports policy-driven verification.
Execution requests define verification behavior through the execution policy.
{
"policy": {
"verify": "none | spotcheck | full"
}
}none
No redundant verification is requested.
Suitable for:
- development
- trusted environments
- exploratory workloads
- low-consequence execution
Execution remains fully traceable through replay metadata and execution evidence.
spotcheck
A controlled subset of shard executions is independently validated.
Suitable for:
- mixed-trust infrastructure
- production workloads
- probabilistic simulations
- cost-sensitive execution
Spotcheck verification balances computational assurance against execution cost.
full
All shards, or a configured high-confidence equivalent, participate in redundant verification.
Suitable for:
- regulated environments
- financial workloads
- insurance workloads
- scientific reproducibility
- enterprise audit scenarios
Full verification increases execution cost and latency while providing stronger computational assurance.
Signed Shard Contracts
Every shard is derived from the immutable execution contract.
A shard contract may include:
- execution identity
- shard identity
- primitive identity
- primitive version
- profile identity
- canonical argument hash
- shard seed
- verification requirements
- execution boundaries
- artifact requirements
Returned work must satisfy the assigned shard contract.
An execution agent cannot legitimately return results for different inputs, different seeds, different profiles, or different execution boundaries while claiming participation in the original workload.
Result Identity
Shard outputs may include deterministic result hashes.
Hashes establish execution identity.
They do not establish computational correctness.
Result identity allows Forge to compare:
- redundant shard execution
- replay execution
- aggregation inputs
- artifact integrity
- repeated execution attempts
Result identity becomes one component of broader execution evidence.
Redundant Execution
Redundant execution assigns equivalent computational work to multiple execution agents.
Its purpose is to detect:
- fabricated computation
- unstable execution
- faulty infrastructure
- nondeterministic behavior
- malicious deviation
For deterministic workloads, equivalent executions should converge to equivalent computational results.
For probabilistic workloads, equivalent executions are interpreted according to the workload's statistical semantics.
Statistical Validation
Certain workload classes require validation beyond byte-for-byte comparison.
Forge may evaluate statistical properties including:
- mean stability
- variance stability
- distribution consistency
- tail behavior
- entropy bounds
- convergence characteristics
- expected value ranges
Statistical validation complements deterministic execution.
It does not replace it.
Different workload classes may therefore employ different validation semantics while remaining compatible with the same execution model.
Deterministic Reduction
Execution agents produce partial computational evidence.
The Hub constructs final computational truth.
Reduction must therefore remain deterministic.
This requires:
- stable reduction semantics
- deterministic shard ordering
- versioned reducers
- controlled floating-point behavior
- exclusion of invalid shard outputs
Reduction is part of verification.
Not merely aggregation.
Agent Reliability
Execution agents accumulate operational history over time.
Reliability evaluation may consider:
- successful execution rate
- verification outcomes
- statistical conformity
- timeout frequency
- latency stability
- execution mismatch history
- protocol compliance
- long-term availability
Reliability is continuously earned.
It is never permanently granted.
The Scheduler may use reliability information to:
- prioritize execution
- reduce shard size
- increase verification requirements
- quarantine unreliable participants
- remove persistent offenders
Quarantine
When execution evidence becomes suspicious, Forge may:
- reject shard results
- retry execution elsewhere
- reduce scheduling priority
- require stronger verification
- quarantine execution agents
- remove agents from future scheduling
A single invalid shard should never silently determine the final computational result.
Repeated execution failures should influence future participation.
Replay-Based Investigation
Verification continues after execution completes.
Replay metadata preserves sufficient information to reconstruct:
- the execution contract
- participating agents
- shard allocation
- seed assignment
- returned results
- verification outcomes
- reduction behavior
- execution artifacts
Replay transforms execution history into durable computational evidence.
Billing and Provider Integrity
Verification also protects the economic layer.
Economic settlement derives from verified computational contribution rather than declared participation.
Execution accounting may incorporate:
- verified shard completion
- verification outcomes
- execution timing
- work contribution
- replay references
- artifact integrity
Economic trust therefore derives from execution evidence.
Verification Boundaries
Verification establishes execution integrity.
It does not establish mathematical correctness.
Those are different problems.
Verification does not guarantee:
- that every workload is mathematically correct
- that every model assumption is valid
- that every dataset is accurate
- that every execution agent remains trustworthy indefinitely
- that every verification policy provides identical assurance
- that low-assurance execution behaves like high-assurance execution
Verification demonstrates that execution faithfully followed the selected execution contract and verification policy.
It does not replace scientific validation, domain expertise, or model governance.
Practical Mental Model
A useful way to understand Forge verification is:
Execution Contract
↓
Distributed Execution
↓
Verification
↓
Deterministic Reduction
↓
Replay Evidence
↓
Computational ConfidenceNo individual execution agent represents the source of truth.
The execution contract defines truth.
Verification preserves it.