Architecture

This section documents the runtime architecture of Forge Pool.

Forge Pool is built as a deterministic distributed execution system for probabilistic and large-scale analytical workloads. Its architecture separates:

• interface and request surfaces
• orchestration and control
• distributed execution
• reduction and delivery

The result is a system that can execute complex workloads across heterogeneous global compute while preserving reproducibility, auditability, and operational control.

---

Core Principle

Forge is strict at the core and flexible at the edge.

The core system defines execution truth.

That core consists of:

• the Web/API surface
• the Hub
• the Agent fleet
• the primitive + profile execution model
• deterministic aggregation and verification

Everything else exists to make that core usable, extensible, and operable.

---

What This Section Covers

Architecture documentation is organized around four layers:

1. System View

How the full runtime fits together.

• Architecture Overview
• System Architecture
• Execution Path

2. Core Runtime Components

The services that make distributed execution possible.

• Hub Architecture
• Agent Kernel Architecture
• Scheduler Architecture
• Aggregation Layer

3. Network and Transport

How work and results move through the system.

• QUIC Transport
• Network Requirements

4. Storage and Scaling

How the system stores state and grows across fleets.

• Blob Storage Architecture
• Scaling Architecture

---

Canonical Runtime Path

At a high level, Forge executes through the following path:

Client / System
    ↓
Web / API surface
    ↓
Hub
    ↓
Agents
    ↓
Primitives + Profiles
    ↓
Verification + Aggregation
    ↓
Final Result

This is the canonical execution path of the system.

Adapters and domain-facing layers may shape requests and outputs, but they do not replace this path.

---

Architectural Boundaries

Forge maintains strict boundaries between concerns:

Layer	Responsibility
Interface Layer	Request intake, API, domain-facing integration
Hub	Control plane, planning, scheduling, verification, aggregation coordination
Agents	Sandboxed shard execution
Primitives + Profiles	Canonical computation semantics
Aggregation	Deterministic reduction into final outputs
Storage Layers	Large-object, medium-state, and metadata support

This separation is fundamental to correctness.

---

Who This Section Is For

These documents are intended for:

• engineers integrating with Forge
• operators running Hubs and Agent fleets
• enterprise architects and security teams
• technical partners evaluating system behavior

---

Reading Order

For first-time readers, the recommended order is:

1. Architecture Overview
2. System Architecture
3. Execution Path
4. Hub Architecture
5. Agent Kernel Architecture

After that, transport, storage, scheduler, and scaling docs can be read as needed.

---

Final Note

Forge is not a collection of disconnected services.

It is a coordinated execution system.

This section explains how that system is structured and how its guarantees are maintained.