Forge Pool

Appearance

Execution Path ​

Every workload executed by Forge follows one canonical execution lifecycle.

Whether the workload is a Monte Carlo simulation, graph propagation, media transformation, ensemble workflow, scientific computation, or a future primitive family, the runtime preserves the same execution path.

Forge does not define different execution models for different workloads.

It defines one execution model capable of supporting many workload semantics.

This document follows the journey of a single execution contract through that runtime.

The Journey of an Execution Contract ​

Execution begins long before computation starts.

A Forge workload is not simply a request.

It is an execution contract.

The runtime exists to preserve that contract from the moment execution intent enters the system until execution evidence is produced.

Every subsystem participates in that responsibility.

text
Execution Intent
        │
        ▼
Execution Contract
        │
        ▼
Planning
        │
        ▼
Scheduling
        │
        ▼
Distributed Execution
        │
        ▼
Verification
        │
        ▼
Deterministic Aggregation
        │
        ▼
Execution Evidence
        │
        ▼
Final Result

The execution path is constant.

Only workload semantics change.

What Remains Constant ​

Regardless of workload type, every execution preserves the same architectural properties.

The runtime always maintains:

  • one canonical execution contract
  • explicit primitive and profile semantics
  • deterministic execution policy
  • controlled orchestration
  • deterministic aggregation
  • preserved execution evidence

Execution should therefore remain understandable independent of the workload itself.

Stage 1 — Execution Intent ​

Execution begins when an external actor expresses computational intent.

The actor may be:

  • an application
  • Forge Studio
  • an SDK
  • an MCP client
  • another service
  • an AI agent
  • an enterprise integration

At this point, the system has not yet accepted execution.

Intent exists outside the runtime.

Purpose ​

Capture computational intent.

Produced ​

A candidate execution request.

Stage 2 — Execution Contract ​

The Web Core validates and transforms execution intent into a canonical execution contract.

The contract defines:

  • project context
  • authentication
  • authorization
  • primitive family
  • profile identity
  • canonical arguments
  • execution policy
  • verification policy
  • deterministic seed behavior
  • artifact requirements
  • billing context

This contract becomes the source of execution truth.

Every subsequent subsystem preserves it.

Purpose ​

Define a deterministic execution contract.

Produced ​

Canonical execution request.

Stage 3 — Planning ​

The Hub accepts the execution contract.

Planning determines how the workload should execute.

Responsibilities include:

  • workload classification
  • shard planning
  • execution graph construction
  • scheduling constraints
  • policy preparation
  • execution identifiers

Planning never performs computation.

Planning determines how computation should occur.

Purpose ​

Transform one execution contract into an executable plan.

Produced ​

Deterministic execution plan.

Stage 4 — Scheduling ​

The Scheduler maps planned work onto available execution resources.

Scheduling considers factors such as:

  • agent capabilities
  • workload compatibility
  • policy constraints
  • reliability history
  • geographic placement
  • throughput
  • fairness
  • execution strategy

Scheduling affects performance.

It must never change computation semantics.

Purpose ​

Assign execution work.

Produced ​

Shard assignments.

Stage 5 — Distributed Execution ​

Agents receive shard assignments from the Hub.

Each Agent executes:

  • one primitive family
  • one profile
  • one deterministic shard

Execution occurs inside isolated runtime boundaries.

Agents perform computation.

They do not coordinate the system.

Purpose ​

Execute workload shards.

Produced ​

Structured shard outputs.

Stage 6 — Verification ​

Verification evaluates execution correctness according to policy.

Policies may include:

  • no verification
  • spot verification
  • redundant execution
  • structural validation
  • statistical consistency
  • integrity validation

Verification increases confidence.

It does not redefine computation semantics.

Purpose ​

Strengthen execution trust.

Produced ​

Verification records.

Stage 7 — Deterministic Aggregation ​

Distributed outputs remain partial until aggregation.

Aggregation combines shard results into one final workload result.

Aggregation must preserve:

  • semantic correctness
  • deterministic reduction
  • workload meaning
  • reproducibility

Arrival order must never redefine result truth.

Purpose ​

Restore one canonical result.

Produced ​

Final workload output.

Stage 8 — Execution Evidence ​

Computation alone does not complete execution.

Execution completes only after the runtime preserves execution evidence.

Execution Evidence may include:

  • execution contract
  • primitive identity
  • profile identity
  • canonical arguments
  • deterministic seed behavior
  • shard plan
  • scheduler metadata
  • agent participation
  • verification records
  • aggregation metadata
  • replay metadata
  • execution artifacts
  • runtime metrics

Execution Evidence enables:

  • replay
  • inspection
  • audit
  • governance
  • reproducibility
  • operational debugging

Evidence is part of execution.

It is not an optional attachment.

Purpose ​

Preserve execution truth.

Produced ​

Replayable execution record.

Stage 9 — Result Delivery ​

The runtime returns the completed execution.

The response may include:

  • workload output
  • execution metadata
  • replay references
  • artifact references
  • verification summary
  • runtime metrics
  • billing information

The result represents the public surface of a completed execution.

The execution evidence remains the authoritative record.

Execution State Lifecycle ​

Every execution progresses through observable runtime states.

text
Accepted
      │
      ▼
Planned
      │
      ▼
Scheduled
      │
      ▼
Executing
      │
      ▼
Verifying
      │
      ▼
Aggregating
      │
      ▼
Completed

These states describe execution progress independently of workload semantics.

What May Change ​

The runtime allows operational variation.

The following may change between equivalent executions:

  • participating Agents
  • scheduling decisions
  • geographic placement
  • network path
  • execution timing
  • infrastructure provider
  • transport latency

These differences are operational.

They should not redefine execution truth.

What Must Not Change ​

The following properties define deterministic execution.

They should remain stable under the same execution contract.

  • primitive semantics
  • profile semantics
  • deterministic seed behavior
  • execution policy
  • aggregation semantics
  • execution evidence model

These define the architectural identity of the execution.

Failure Model ​

The runtime assumes failure throughout execution.

Failures may include:

  • unavailable Agents
  • failed shard execution
  • transport interruption
  • network degradation
  • verification rejection
  • scheduler retry
  • storage retry
  • infrastructure heterogeneity

The execution path is designed so that correctness depends on explicit recovery rather than perfect infrastructure.

Architectural Guarantees ​

The execution lifecycle is designed to preserve:

  • one canonical execution contract
  • deterministic workload execution
  • explicit responsibility boundaries
  • replayable execution evidence
  • deterministic aggregation
  • controlled verification
  • observable execution state
  • heterogeneous infrastructure support

These guarantees define the execution model independently of any specific workload.

Architectural Non-Goals ​

The execution lifecycle intentionally does not:

  • allow clients to redefine execution semantics
  • permit adapters to bypass the execution contract
  • treat replay as optional metadata
  • couple scheduling decisions to computation meaning
  • assume homogeneous infrastructure
  • sacrifice execution integrity for throughput

Execution correctness always has priority over operational convenience.

How to Verify the Execution Path ​

The complete execution lifecycle can be inspected directly.

A technical evaluator can:

  1. Execute a workload through the Quickstart.
  2. Inspect the execution contract.
  3. Confirm primitive and profile identity.
  4. Inspect planning metadata.
  5. Inspect shard execution.
  6. Review verification policy.
  7. Inspect aggregation output.
  8. Confirm replay metadata.
  9. Compare execution evidence with the documented lifecycle.

The observed execution should correspond to every stage described in this document.

Related Documentation ​

Continue with:

  1. Hub Architecture
  2. Scheduler Architecture
  3. Agent Kernel Architecture
  4. Aggregation Layer
  5. Transport Architecture
  6. Storage Architecture
  7. Network Architecture

Final Mental Model ​

A Forge execution is complete only when both computation and its execution evidence have been preserved.

Distributed computation produces results.

Forge preserves the truth of how those results came to exist.

Deterministic execution infrastructure for distributed compute.

Copyright © 2026 Forge Pool