Hub Architecture
The Forge Hub is the Control Plane of the Forge runtime.
Its responsibility is not to perform computation.
Its responsibility is to preserve coordinated execution.
Every workload entering Forge eventually passes through the Hub.
Every execution contract is planned, scheduled, coordinated, verified, and tracked through the Hub before computation begins.
The Hub owns execution coordination.
It never owns computation.
The Coordination Problem
Distributed computation introduces a coordination problem.
Before any workload executes, the runtime must answer several questions:
- What exactly should execute?
- How should the workload be partitioned?
- Which Agents should perform each shard?
- How should execution be verified?
- How should partial outputs become one deterministic result?
- How should execution remain replayable after completion?
These questions define the Control Plane.
The Hub exists to answer them consistently for every execution.
Hub Philosophy
The Hub coordinates execution.
It never performs computation.
Primitive semantics belong to the Semantic Plane.
Computation belongs to the Execution Plane.
Verification belongs to verification policies.
Aggregation belongs to deterministic reduction.
The Hub preserves coordination across all of them.
This separation is fundamental to the Forge architecture.
Primary Responsibilities
The Hub owns global execution coordination.
Its responsibilities include:
Execution Admission
Accept valid execution contracts from the Interface Plane.
Validate project context, authentication, authorization, and execution policy.
Planning
Transform one execution contract into a deterministic execution plan.
Planning determines:
- execution graph
- shard boundaries
- deterministic partitioning
- execution identifiers
- scheduling requirements
- replay alignment
Planning never performs computation.
Scheduling Coordination
Coordinate shard placement across available Agents.
Scheduling considers:
- capabilities
- policy constraints
- reliability
- geographic placement
- capacity
- fairness
- historical behavior
Scheduling affects execution efficiency.
It must never modify execution semantics.
Dispatch Coordination
Coordinate secure delivery of execution contracts to participating Agents.
The Hub tracks execution.
Agents perform execution.
Verification Coordination
Determine which verification strategy applies.
Coordinate verification workflows.
Collect verification outcomes.
The Hub coordinates verification.
It does not redefine computation semantics.
Aggregation Coordination
Coordinate deterministic reduction of distributed shard outputs.
Aggregation restores one workload result.
The Hub ensures the reduction process follows the execution contract.
Execution Evidence Coordination
Coordinate preservation of execution evidence.
Examples include:
- execution identifiers
- planning metadata
- scheduling metadata
- verification records
- aggregation metadata
- replay references
- runtime lineage
The Hub contributes to execution evidence.
It does not own every evidence artifact.
Runtime Accounting
Coordinate execution accounting.
Examples include:
- project quotas
- billing context
- provider credits
- execution cost
- resource attribution
Accounting never changes execution correctness.
What the Hub Never Does
Architectural boundaries are explicit.
The Hub never:
- executes primitive workloads
- changes primitive semantics
- performs hidden computation
- defines workload meaning
- bypasses verification policy
- becomes a storage engine
- owns application logic
- interprets business results
These constraints preserve separation between orchestration and execution.
Internal Runtime Flow
The Hub coordinates execution through a sequence of internal responsibilities.
Execution Contract
│
▼
Admission
│
▼
Planning
│
▼
Scheduling
│
▼
Dispatch
│
▼
Verification Coordination
│
▼
Aggregation Coordination
│
▼
Execution Evidence CoordinationThis flow describes coordination.
Actual computation occurs only after Agents receive shard assignments.
Relationship to the Architectural Planes
The Hub primarily implements the Control Plane.
It interacts with every other architectural plane while preserving clear responsibility boundaries.
| Plane | Relationship |
|---|---|
| Interface Plane | Receives validated execution contracts |
| Semantic Plane | Uses primitive and profile definitions without modifying them |
| Execution Plane | Coordinates Agent execution without performing computation |
| Evidence Plane | Coordinates preservation of execution evidence |
| Storage Plane | Persists runtime state and metadata |
The Hub connects the planes.
It does not replace them.
Relationship to Runtime Components
The Hub coordinates several runtime components.
| Component | Relationship |
|---|---|
| Scheduler | Determines execution placement |
| Agent Kernel | Executes assigned shards |
| Aggregation Layer | Performs deterministic reduction |
| Verification | Evaluates execution correctness |
| Blob Storage | Stores execution artifacts |
| KV / Metadata | Stores runtime coordination state |
| Studio | Submits execution intent |
| MCP | Exposes execution capabilities to AI systems |
Each component owns one responsibility.
The Hub coordinates them into one execution lifecycle.
Hub Invariants
The following architectural properties must remain true.
The Hub never performs computation.
Execution belongs exclusively to Agents.
The Hub never defines workload semantics.
Primitive families and profiles define computation meaning.
The Hub always owns planning.
Planning cannot migrate to Agents.
The Hub preserves execution identity.
Execution identifiers remain stable throughout the lifecycle.
Scheduling never changes execution truth.
Operational optimization must not redefine computation semantics.
Verification policy remains explicit.
Verification may increase confidence.
It never changes workload meaning.
Execution Evidence remains coordinated.
Every completed workload should preserve the information necessary for replay, inspection, and audit.
Failure Model
The Hub assumes distributed infrastructure is imperfect.
Expected failures include:
- unavailable Agents
- delayed execution
- scheduler retries
- transport interruption
- verification rejection
- storage retries
- partial completion
- heterogeneous hardware
- fluctuating network quality
The Hub is designed to preserve execution correctness despite these failures.
Operational instability should not compromise execution integrity.
Observability
The Hub continuously produces operational signals.
Examples include:
- planning decisions
- scheduler events
- dispatch events
- verification outcomes
- aggregation progress
- Agent participation
- runtime latency
- execution timing
- billing metrics
- health information
These signals make execution coordination inspectable.
Contribution to Execution Evidence
The Hub contributes coordination metadata to the overall Execution Evidence.
Examples include:
- execution identifiers
- planning metadata
- scheduling metadata
- dispatch metadata
- verification coordination
- aggregation coordination
- runtime lineage
- execution timestamps
- policy references
Execution Evidence is preserved across multiple runtime components.
The Hub provides the coordination perspective.
Architectural Guarantees
The Hub is designed to preserve:
- deterministic planning
- explicit execution coordination
- stable responsibility boundaries
- replayable coordination metadata
- controlled verification
- deterministic reduction orchestration
- execution traceability
- operational observability
These guarantees define the Control Plane independently of workload semantics.
Architectural Non-Goals
The Hub intentionally does not:
- execute primitive workloads
- interpret business logic
- redefine computation semantics
- optimize correctness through hidden computation
- depend on homogeneous infrastructure
- replace verification
- replace aggregation
- become an execution engine
The Hub coordinates execution.
It never becomes execution.
How to Verify Hub Behavior
A technical evaluator can verify the Hub's responsibilities by observing one execution.
Suggested verification path:
- Submit a workload.
- Inspect the execution contract.
- Observe planning metadata.
- Confirm shard planning.
- Inspect scheduling decisions.
- Observe Agent assignments.
- Review verification coordination.
- Inspect aggregation coordination.
- Compare preserved execution evidence.
The observed coordination should correspond to the architecture described in this document.
Related Documentation
Continue with:
- Scheduler Architecture
- Agent Kernel Architecture
- Aggregation Layer
- Execution Path
- Transport Architecture
- Storage Architecture
Final Mental Model
The Hub is not the place where computation happens.
It is the place where distributed computation becomes one coordinated execution system.
Without the Hub, there are independent Agents.
With the Hub, there is one execution runtime.
That distinction defines the Control Plane.