Architecture Overview
Forge Pool is a planetary execution infrastructure built around one central idea:
Distributed computation should produce not only results, but execution that can be understood, reproduced, inspected, and trusted.
The architecture is therefore designed around execution rather than infrastructure.
Infrastructure provides compute.
Execution provides correctness.
The Forge runtime exists to preserve that distinction.
The Architectural Problem
Most distributed systems optimize for throughput, elasticity, or resource utilization.
Forge solves a different problem.
How can computation remain deterministic, replayable, and verifiable after it has been distributed across heterogeneous infrastructure?
Answering that question requires more than scheduling work across machines.
It requires an execution model where every subsystem contributes to preserving execution correctness rather than simply completing computation.
That execution model defines the architecture of Forge.
Runtime Philosophy
Forge should not be understood as a collection of services.
It should be understood as a coordinated execution runtime.
Every subsystem exists for one reason:
To preserve a single execution contract from submission through final result.
Whether computation is performed on one machine or thousands, the architectural objective remains identical:
- preserve execution intent
- coordinate deterministic execution
- produce inspectable execution evidence
- deliver trustworthy results
Execution is the product.
Infrastructure is the mechanism.
The Canonical Runtime Model
Every workload follows the same conceptual lifecycle.
Execution Intent
│
▼
Execution Contract
│
▼
Planning
│
▼
Distributed Execution
│
▼
Verification
│
▼
Deterministic Aggregation
│
▼
Execution Evidence
│
▼
Final ResultIndividual workloads differ.
The runtime model does not.
Whether executing Monte Carlo simulation, graph propagation, media processing, search, ensemble execution, or future primitive families, every workload traverses the same architectural backbone.
Architectural Layers
The Forge runtime is organized into cooperating architectural planes.
Viewing the runtime through these planes is more useful than viewing it as a collection of services.
Interface Plane
Receives execution intent from users, systems, SDKs, Studio, MCP clients, and enterprise integrations.
This layer accepts execution requests but never defines execution correctness.
Control Plane
Coordinates execution.
Responsibilities include:
- admission
- planning
- scheduling
- policy enforcement
- verification routing
- aggregation coordination
The Hub is the primary implementation of the Control Plane.
Execution Plane
Performs computation.
Agents execute isolated workload shards under deterministic execution contracts.
No orchestration logic resides here.
Only computation.
Semantic Plane
Defines computational meaning.
Primitive families define classes of computation.
Profiles define workload-specific execution semantics.
This layer determines what a workload means.
Evidence Plane
Preserves execution truth.
Replay metadata, verification outputs, lineage, aggregation metadata, execution artifacts, and runtime metrics collectively form the execution evidence of a workload.
Evidence is treated as part of execution rather than post-processing.
Storage Plane
Persists execution state.
Different storage systems support different classes of runtime information while remaining independent from execution semantics.
Storage supports execution.
It does not define execution.
Core Runtime Components
The runtime is implemented through several cooperating components.
Web Core
The public execution boundary.
Responsible for:
- authentication
- authorization
- request validation
- project isolation
- billing context
- lifecycle initiation
The Web Core admits execution.
It never performs computation.
Hub
The orchestration core.
Responsible for:
- planning
- scheduling
- dispatch
- verification policy
- aggregation coordination
- replay metadata orchestration
The Hub coordinates execution.
It never computes workloads.
Agent Mesh
Distributed execution infrastructure.
Agents perform isolated shard execution under explicit execution contracts.
Agents own computation.
They never define global execution truth.
Primitive Runtime
Defines workload behavior.
Primitive families describe computation classes.
Profiles specialize those families into concrete execution semantics.
This layer defines what computation actually means.
Aggregation
Transforms distributed partial outputs into one deterministic result.
Aggregation preserves semantic correctness independent of execution order.
Execution Evidence
Forge produces more than computation.
Every completed workload generates Execution Evidence.
Execution Evidence may include:
- execution contract
- primitive identity
- profile identity
- canonical arguments
- deterministic seed behavior
- shard metadata
- agent participation
- verification records
- aggregation metadata
- runtime metrics
- execution artifacts
- replay metadata
Execution Evidence allows an execution to be inspected, replayed, verified, challenged, and understood long after computation has completed.
This concept connects Replay, Verification, Audit, Memory Fabric, and Observability into one architectural model.
Determinism
Forge treats determinism as an architectural property rather than a hardware property.
Equivalent execution contracts should produce equivalent execution truth.
Determinism therefore depends on:
- canonical execution contracts
- versioned primitive semantics
- deterministic seed discipline
- stable shard planning
- deterministic aggregation
- explicit verification policies
It does not depend on identical infrastructure.
For a detailed discussion, see the Determinism and Heterogeneous Execution documentation.
Heterogeneous Infrastructure
Forge assumes infrastructure diversity.
Agents may differ in:
- hardware
- operating systems
- geographic regions
- cloud providers
- network conditions
- execution capacity
The architecture therefore separates execution correctness from infrastructure identity.
Deterministic execution is achieved through execution discipline rather than infrastructure uniformity.
Failure Model
The runtime is designed under the assumption that distributed systems fail continuously.
Failures include:
- unavailable agents
- slow agents
- network interruption
- shard failure
- transport instability
- infrastructure heterogeneity
The architecture therefore emphasizes:
- explicit planning
- isolated execution
- verification
- deterministic aggregation
- observable recovery
Correctness should survive operational instability.
Architectural Guarantees
The runtime is designed to preserve:
- deterministic execution semantics
- explicit architectural boundaries
- replayable execution
- inspectable execution evidence
- heterogeneous infrastructure support
- controlled distributed coordination
- reproducible reduction
- operational observability
These guarantees define the architecture independently of any specific workload.
Architectural Non-Goals
The runtime intentionally does not:
- embed workload semantics inside orchestration
- allow interfaces to redefine computation
- couple scheduling with execution correctness
- depend on homogeneous infrastructure
- hide execution assumptions
- treat replay as an optional debugging feature
These constraints preserve long-term architectural integrity.
Reading Path
If this is your first time studying the runtime architecture, continue in the following order:
- System Architecture
- Execution Path
- Hub Architecture
- Scheduler Architecture
- Agent Kernel Architecture
- Aggregation Layer
- Transport Architecture
- Network Architecture
- Storage Architecture
- Scaling Architecture
Each document progressively refines the runtime model introduced here.
Final Mental Model
Forge is not built around services.
It is built around one execution contract.
Every subsystem exists to preserve that contract while transforming distributed computation into deterministic, replayable, and verifiable execution.
Components may evolve.
Infrastructure may evolve.
Primitive families may evolve.
Execution contracts remain.
That continuity is what defines the Forge runtime.