Forge Pool

Appearance

Runtime Concepts ​

Forge is easier to understand if you follow an execution than if you study individual components.

This guide explains the runtime by following the lifecycle of a single workload—from the moment a question is submitted until its execution becomes durable computational evidence.

After reading this guide you will understand:

  • what an execution contract is
  • how jobs become shards
  • how shards become distributed execution
  • how computation becomes execution evidence
  • how replay is preserved
  • how the Forge runtime is organized

The Runtime Mental Model ​

Every execution follows the same conceptual lifecycle.

text
Question
      │
      ▼
Execution Contract
      │
      ▼
Job
      │
      ▼
Shards
      │
      ▼
Distributed Execution
      │
      ▼
Verification
      │
      ▼
Deterministic Reduction
      │
      ▼
Execution Evidence
      │
      ▼
Replay

Understanding this flow is significantly more valuable than memorizing individual runtime components.

Everything Begins with an Execution Contract ​

Every workload submitted to Forge begins as an immutable execution contract.

The execution contract defines:

  • what should execute
  • which primitive family performs execution
  • which profile defines workload semantics
  • execution arguments
  • execution policy
  • seed behavior
  • replay requirements

The execution contract becomes the computational identity of the workload.

Every subsequent runtime decision is evaluated relative to this contract.

From Execution Contract to Job ​

Once accepted by the runtime, the execution contract becomes a Job.

A Job represents one complete distributed execution.

It contains everything required for execution, including:

  • execution identity
  • workload definition
  • execution policy
  • billing context
  • replay metadata
  • execution state

Jobs remain immutable after execution completes.

The Job—not the API request—is the durable execution object.

From Job to Shards ​

Large computational workloads are partitioned into deterministic shards.

For example:

text
1,000,000 iterations

        │

        ▼

10 deterministic shards

        │

        ▼

100,000 iterations per shard

Sharding enables:

  • horizontal scalability
  • workload isolation
  • fault recovery
  • heterogeneous scheduling
  • verification
  • elastic execution

Shard planning is deterministic.

Given the same execution contract, the same shard structure is produced.

From Shards to Distributed Execution ​

After shard planning completes, execution begins.

Multiple execution agents receive independent shard assignments and execute them in parallel.

Each agent is responsible only for its assigned computational work.

Execution agents never determine global computational truth.

They produce partial computational evidence.

The final result is established elsewhere in the runtime.

The Runtime Architecture ​

Although execution appears as a single operation, several runtime components cooperate to preserve deterministic execution.

text
Web Core
      │
governs execution
      │
      ▼
Kernel
defines execution semantics
      │
      ▼
Hub
plans and orchestrates execution
      │
      ▼
Agents
perform distributed computation
      │
      ▼
Reducers
produce computational truth

Each component has a distinct responsibility.

No individual component independently defines execution correctness.

Primitive Families ​

Primitive families define canonical classes of computation.

Examples include:

  • mc@1
  • tensor@1
  • graph@1
  • search@1
  • media@1
  • ensemble@1

Primitive families describe how computation behaves.

They do not describe business domains.

Profiles ​

Profiles specialize primitive families into workload-specific execution semantics.

Examples include:

  • insurance.v1
  • eta.v1
  • matmul.v1
  • transcode.v1

A useful mental model is:

text
Primitive Family

defines computational class

+

Profile

defines workload semantics

Examples:

text
tensor@1
      +
matmul.v1
text
mc@1
      +
insurance.v1
text
media@1
      +
transcode.v1

Together they define the computational identity of the workload.

Adapters ​

Applications rarely communicate directly using primitive families.

Instead, they interact through adapters.

Adapters translate domain-specific requests into canonical execution contracts.

For example:

text
Insurance Risk
        │
        ▼
Adapter
        │
        ▼
mc@1
        │
insurance.v1

Adapters may:

  • validate input
  • transform domain payloads
  • generate execution contracts
  • normalize outputs

Adapters simplify integration.

They do not define execution semantics.

Deterministic Execution ​

Forge preserves computational determinism rather than operational determinism.

Execution semantics remain stable even when infrastructure changes.

Deterministic execution depends upon:

  • immutable execution contracts
  • controlled seed discipline
  • deterministic shard planning
  • deterministic reduction
  • replay preservation

These properties make execution reproducible across heterogeneous infrastructure.

Verification ​

Distributed execution assumes mixed-trust infrastructure.

Verification ensures that execution faithfully followed the documented execution contract.

Depending on execution policy, verification may include:

  • redundant execution
  • shard validation
  • statistical verification
  • deterministic reduction
  • replay inspection

Verification establishes execution integrity.

It does not establish domain correctness.

Execution Evidence ​

Forge preserves considerably more than computational output.

Every execution also produces durable execution evidence.

Execution evidence may include:

  • execution contract
  • replay metadata
  • shard structure
  • execution metrics
  • verification results
  • execution artifacts
  • aggregation metadata

Execution evidence allows workloads to remain inspectable after computation has completed.

Replay ​

Replay preserves computational history.

It does not attempt to reproduce identical infrastructure.

Replay reproduces execution according to the original execution contract and execution doctrine.

Replay therefore depends on preserved execution semantics rather than preserved hardware.

Memory Surfaces ​

Distributed execution frequently spans multiple stages.

Forge exposes persistent execution surfaces including:

  • Blob Storage
  • KV State
  • VMem
  • snapshots
  • replay artifacts
  • execution references

These allow execution systems to maintain state while preserving deterministic execution behavior.

Ledger ​

Execution also produces economic evidence.

Clients consume computational capacity.

Providers contribute verified computation.

Ledger records preserve:

  • execution accounting
  • computational contribution
  • verification outcomes
  • replay references
  • billing events

Economic settlement therefore derives from documented execution rather than declared participation.

Runtime Summary ​

A useful way to understand Forge is:

text
Execution Contract
        │
        ▼
Job
        │
        ▼
Shards
        │
        ▼
Distributed Execution
        │
        ▼
Verification
        │
        ▼
Deterministic Reduction
        │
        ▼
Execution Evidence
        │
        ▼
Replay
        │
        ▼
Computational Trust

Every runtime component contributes to one stage of this lifecycle.

Together they form a deterministic distributed execution system.

Where to Go Next ​

Now that you understand the runtime, continue with:

  1. Trust Layer — learn how Forge establishes computational trust through verification, replay, and execution evidence.

  2. Architecture — understand how the runtime implements deterministic execution across distributed infrastructure.

  3. Clients Guide — integrate applications using execution contracts and production APIs.

  4. Providers Guide — contribute execution capacity to the runtime.

Understanding these documents in sequence mirrors the way the runtime itself is designed.

Final Thought ​

Forge is not organized around servers, APIs, or infrastructure components.

It is organized around execution.

Every component exists for one reason:

To transform an execution contract into reproducible computation, durable execution evidence, and independently verifiable computational truth.

Deterministic execution infrastructure for distributed compute.

Copyright © 2026 Forge Pool