System Architecture

Forge Pool is one distributed execution system composed of multiple cooperating runtime responsibilities.

The system is not defined by individual services.

It is defined by the execution contract those services collectively preserve.

One System, Multiple Responsibilities

Forge should not be understood as a loose collection of infrastructure components.

It should be understood as a coordinated runtime that transforms execution intent into deterministic, replayable, and verifiable execution.

Every subsystem exists to support one or more responsibilities:

text

Receive intent
      ↓
Validate execution contract
      ↓
Coordinate execution
      ↓
Execute computation
      ↓
Verify outputs
      ↓
Aggregate deterministically
      ↓
Preserve execution evidence
      ↓
Deliver result

The components may evolve over time.

The responsibility structure should remain stable.

Core System Principle

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

This principle governs the entire architecture.

Interfaces may shape execution intent.

Adapters may normalize domain inputs.

AI agents may help construct payloads.

Studio may compose workflows.

Enterprise integrations may embed Forge into larger systems.

None of these define execution truth.

Execution truth is defined only by the canonical runtime path, primitive/profile semantics, deterministic execution policy, verification, aggregation, and preserved execution evidence.

Architectural Planes

Forge is organized into six architectural planes.

These planes describe responsibilities, not deployment topology.

Interface Plane

Receives execution intent from external systems.

Examples include:

REST APIs
SDKs
Forge Studio
MCP clients
enterprise integrations
domain adapters

The Interface Plane turns user or system intent into a valid execution request.

It does not define computation semantics.

Control Plane

Coordinates execution.

Responsibilities include:

admission
planning
scheduling
policy enforcement
dispatch
verification routing
aggregation coordination
execution state tracking

The Hub implements the primary Control Plane.

The Control Plane governs execution.

It does not perform workload computation.

Execution Plane

Performs computation.

Agents execute isolated shards under explicit execution contracts.

The Execution Plane is responsible for:

shard execution
local isolation
deterministic kernel behavior
structured partial output
runtime telemetry

Agents compute.

They do not define global execution truth.

Semantic Plane

Defines what computation means.

The Semantic Plane is implemented through primitive families and profiles.

Primitive families define computation classes.

Profiles define workload-specific execution semantics.

This is the canonical computation layer of Forge.

Evidence Plane

Preserves execution truth.

The Evidence Plane includes:

verification outputs
aggregation metadata
replay metadata
execution artifacts
lineage
runtime metrics
result envelopes

The Evidence Plane turns distributed execution into inspectable execution evidence.

Storage Plane

Persists runtime state and execution artifacts.

Storage systems support the runtime by preserving:

lightweight metadata
job state
large binary objects
intermediate artifacts
replay references
output artifacts

Storage supports execution.

It does not define execution semantics.

Component Mapping

The system planes map to concrete runtime components.

Plane	Primary Components	Responsibility
Interface Plane	Web Core, API, Studio, MCP, Adapters, SDKs	Accept and shape execution intent
Control Plane	Hub, Scheduler, policy enforcement, dispatch	Coordinate execution
Execution Plane	Agent Mesh, Agent Kernel	Execute workload shards
Semantic Plane	Primitive families, profiles, kernel handlers	Define computation semantics
Evidence Plane	Verification, aggregation, replay, artifacts, telemetry	Preserve execution truth
Storage Plane	KV, Blob, VMem, metadata stores	Persist state and artifacts

The mapping is intentionally separated from deployment details.

A component may evolve internally as long as it preserves its plane responsibility.

Canonical System Path

Every workload follows the same system path.

text

Application / AI Agent / External System
                │
                ▼
          Interface Plane
                │
                ▼
        Execution Contract
                │
                ▼
           Control Plane
                │
                ▼
          Execution Plane
                │
                ▼
           Semantic Plane
                │
                ▼
           Evidence Plane
                │
                ▼
          Final Result

This path is canonical.

Adapters, Studio flows, MCP clients, and enterprise integrations may change how execution intent enters the system.

They do not replace the system path.

Execution Contract

The execution contract is the object the system preserves.

It defines:

caller context
primitive family
profile identity
canonical arguments
seed behavior
execution policy
verification policy
artifact requirements
billing context
project scope

Every runtime subsystem exists to preserve, execute, verify, or record this contract.

If the execution contract is ambiguous, the runtime cannot produce trustworthy execution evidence.

System Invariants

System invariants are properties that must remain true as Forge evolves.

Invariant 1 — Interfaces do not define computation

Interfaces may receive, validate, and shape execution intent.

They must not redefine workload semantics.

Invariant 2 — Adapters do not own execution truth

Adapters translate external context into canonical execution contracts.

They do not perform hidden compute that changes result meaning.

Invariant 3 — The Hub does not execute workloads

The Hub coordinates execution.

It plans, schedules, dispatches, verifies, and aggregates.

It does not perform primitive workload computation.

Invariant 4 — Agents do not define global truth

Agents execute shard-level work.

They return structured partial outputs.

They do not decide final result meaning.

Invariant 5 — Primitives and profiles define semantics

The meaning of a workload is defined by its primitive family and profile.

Changing computation meaning requires explicit primitive/profile version discipline.

Invariant 6 — Verification does not redefine computation

Verification strengthens trust in execution.

It detects inconsistency, drift, malformed output, or suspicious behavior.

It does not silently alter workload semantics.

Invariant 7 — Aggregation must be deterministic

Aggregation turns partial outputs into final results.

It must preserve stable semantics independent of arbitrary arrival order.

Invariant 8 — Evidence is part of execution

Replay metadata, artifacts, verification records, and runtime metrics are not afterthoughts.

They are part of the execution result surface.

Where Compute Actually Happens

Compute does not happen in:

clients
dashboards
adapters
Studio
MCP clients
orchestration wrappers
the Hub

Compute happens when Agents execute primitive/profile-defined workload shards assigned by the Hub.

That boundary is central to the system.

Without it, execution truth would drift toward the edge.

Relationship to Adapters

Adapters are edge-facing translation layers.

They may:

accept domain input
validate domain structure
normalize payloads
map context to primitive/profile usage
call the canonical execution runtime
reshape outputs for downstream systems

Adapters make Forge usable across industries.

They do not make Forge correct.

Correctness belongs to the core runtime.

Relationship to Studio

Forge Studio is a visual orchestration surface.

It may:

compose execution graphs
manage flows
invoke adapters
persist run history
display outputs
support reusable workboards

Studio does not execute distributed compute.

Studio submits execution intent into the same runtime path as every other client.

Relationship to MCP and AI Agents

MCP exposes Forge execution capabilities to AI systems.

AI agents may:

discover capabilities
describe contracts
construct payloads
execute workloads
retrieve results
interpret outputs

AI agents do not become execution authorities.

Forge remains the execution authority.

The model may reason.

The runtime executes.

Execution Evidence

Forge produces execution evidence, not only results.

Execution Evidence may include:

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

This evidence allows the execution to be inspected, replayed, challenged, and audited after completion.

Failure Assumptions

Forge assumes failure as normal.

The system is designed with the expectation that:

agents may disappear
agents may be slow
agents may return invalid outputs
network links may degrade
packet loss may occur
hardware may differ
shards may fail
verification may reject work
storage may require retry behavior

System correctness depends on explicit recovery boundaries rather than perfect infrastructure.

System Guarantees

The system architecture is designed to preserve:

canonical execution contract handling
strict responsibility boundaries
deterministic primitive/profile execution semantics
distributed shard execution
controlled verification
deterministic aggregation
replayable execution evidence
operational observability
adapter and interface separation
heterogeneous infrastructure tolerance

These guarantees depend on correct implementation of the subsystem contracts described throughout the architecture documentation.

System Non-Goals

The system intentionally does not:

allow adapters to define computation truth
treat the Hub as a compute engine
depend on identical hardware
hide execution assumptions inside interfaces
treat replay as optional metadata
collapse execution and interpretation into one layer
allow AI agents to become result authorities
optimize speed at the expense of execution integrity

These non-goals are part of the architecture.

They prevent short-term convenience from compromising long-term trust.

How to Verify This Architecture

A technical evaluator can verify the system model by tracing one workload through the runtime.

Follow this path:

Submit a workload through the API, Studio, or MCP.
Inspect the execution contract.
Confirm primitive and profile identity.
Inspect Hub planning and scheduling metadata where available.
Inspect Agent/shard execution metadata.
Confirm verification mode.
Inspect aggregation output.
Confirm replay metadata or artifact references.
Compare the result against the documented execution path.

If the system behaves correctly, the execution should remain explainable from intent to evidence.

Continue in this order:

Final Mental Model

A Forge deployment should be understood as one execution system distributed across many independent runtime components.

Distribution is an implementation detail.

Execution is the architectural constant.

The system exists to preserve execution truth from intent to evidence.

System Architecture ​

One System, Multiple Responsibilities ​

Core System Principle ​

Architectural Planes ​

Interface Plane ​

Control Plane ​

Execution Plane ​

Semantic Plane ​

Evidence Plane ​

Storage Plane ​

Component Mapping ​

Canonical System Path ​

Execution Contract ​

System Invariants ​

Invariant 1 — Interfaces do not define computation ​

Invariant 2 — Adapters do not own execution truth ​

Invariant 3 — The Hub does not execute workloads ​

Invariant 4 — Agents do not define global truth ​

Invariant 5 — Primitives and profiles define semantics ​

Invariant 6 — Verification does not redefine computation ​

Invariant 7 — Aggregation must be deterministic ​

Invariant 8 — Evidence is part of execution ​

Where Compute Actually Happens ​

Relationship to Adapters ​

Relationship to Studio ​

Relationship to MCP and AI Agents ​

Execution Evidence ​

Failure Assumptions ​

System Guarantees ​

System Non-Goals ​

How to Verify This Architecture ​

Related Documentation ​

Final Mental Model ​