System Architecture

Forge Pool is a layered distributed execution system.

Its architecture is built around one central principle:

execution truth lives in the core runtime, not at the edge.

This means the system must be understood as a set of coordinated layers with strict boundaries between them.

---

System Layers

Forge can be understood through five layers:

1. Interface Layer

The human-facing and system-facing entry surface.

This includes:

• API requests
• client integrations
• external systems submitting workloads

Its purpose is to turn incoming intent into valid execution requests.

---

2. Control Layer

The Hub and its orchestration subsystems.

This layer is responsible for:

• planning
• scheduling
• dispatch
• verification routing
• aggregation coordination
• state and accounting

It governs execution, but does not perform compute.

---

3. Compute Layer

The Agent fleet.

This is where distributed shard execution occurs.

Agents execute workloads under isolation, return structured results, and expose metrics back to the Hub.

---

4. Execution Semantics Layer

The primitive + profile model.

This is the canonical definition of what computation is being performed.

Primitives define computation families. Profiles define workload-specific execution semantics.

This layer is the source of computational truth.

---

5. Reduction and Delivery Layer

Verification, aggregation, and final response shaping.

This layer turns distributed partial work into deterministic final outputs.

---

Canonical System Path

The system operates through the following path:

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

This is the core architectural path of Forge Pool.

---

Where Compute Actually Happens

Compute does not happen:

• in clients
• in adapters
• in orchestration wrappers
• in the Hub

Compute happens only when Agents execute primitive/profile-defined workloads assigned by the Hub.

That distinction must remain explicit across the entire documentation surface.

---

Relationship to Adapters

Adapters are not part of the execution core.

They are edge-facing layers that may:

• accept user or domain input
• normalize requests
• map intent to primitive/profile usage
• trigger execution through the core
• reshape outputs for downstream systems

They make Forge usable.

They do not define Forge correctness.

---

Separation of Responsibilities

Layer	Responsibility
Interface / Adapter layer	Input shaping, intent mapping, output shaping
Web / API	Request intake, auth, validation
Hub	Planning, scheduling, dispatch, verification coordination
Agents	Isolated shard execution
Primitive + Profile layer	Computation semantics
Aggregation	Deterministic reduction and final result construction

This separation is what allows the system to scale without losing trust.

---

Why This Layering Exists

Without strict layering:

• execution semantics drift
• traceability breaks
• replayability becomes unreliable
• operational boundaries collapse

With strict layering:

• the system remains understandable
• the execution path remains auditable
• components can evolve without compromising correctness

---

System Guarantees

The architecture is designed to preserve:

• deterministic execution behavior
• distributed scalability
• explicit control-plane boundaries
• reproducible results
• fault tolerance under Agent churn
• observability across the full runtime path

---

Mental Model

Think of Forge as a core execution engine with controlled layers around it.

• the edge accepts intent
• the Hub coordinates work
• Agents execute shards
• primitives and profiles define meaning
• aggregation restores a final result

That is the system.

---

Final Note

Forge is not a loose federation of services.

It is a controlled execution architecture.

Understanding that distinction is the key to understanding the entire platform.