Scheduler Architecture
The Forge Scheduler is responsible for one architectural problem:
Determining where and when execution should occur without changing what execution means.
The Scheduler is part of the Control Plane.
It never performs computation.
It never defines workload semantics.
Its responsibility is to transform one execution plan into optimal execution placement while preserving the execution contract.
The Placement Problem
Distributed execution introduces a placement problem.
A workload may be executable on hundreds or thousands of eligible Agents.
The runtime must determine:
- which Agents should participate
- how work should be partitioned
- how execution should adapt to changing infrastructure
- how verification should be scheduled
- how fairness should be preserved
- how placement decisions remain replayable
The Scheduler exists to solve these questions consistently for every workload.
Scheduler Philosophy
The Scheduler optimizes execution placement.
It never optimizes execution truth.
Performance may change.
Infrastructure may change.
Agent availability may change.
Execution semantics must not.
This separation allows Forge to optimize operational efficiency while preserving deterministic execution.
Relationship to the Hub
The Hub and Scheduler solve different problems.
| Hub | Scheduler |
|---|---|
| Owns execution coordination | Owns execution placement |
| Accepts execution contracts | Maps execution plans to infrastructure |
| Produces execution plans | Produces placement decisions |
| Coordinates verification | Places verification work |
| Coordinates aggregation | Coordinates execution locality |
The Hub decides what must happen.
The Scheduler decides where and when it should happen.
Primary Responsibilities
The Scheduler is responsible for placement decisions throughout the execution lifecycle.
Capability Matching
Determine which Agents are capable of executing a workload.
Capability evaluation may consider:
- supported primitive families
- hardware capabilities
- memory capacity
- accelerator availability
- software compatibility
- runtime version compatibility
Capability matching establishes eligibility.
It does not determine priority.
Placement Optimization
Determine the most appropriate placement for every execution shard.
Placement may consider:
- latency
- throughput
- reliability
- historical performance
- resource utilization
- geographic proximity
- workload affinity
Placement affects efficiency.
It must never affect execution semantics.
Resource Balancing
Distribute work across the planetary execution fabric.
Objectives include:
- avoiding hotspots
- maintaining utilization
- preventing starvation
- maximizing parallelism
- preserving operational stability
Balancing is continuous throughout execution.
Dynamic Rebalancing
Infrastructure changes during execution.
Agents may:
- disconnect
- recover
- slow down
- become overloaded
- join the network
The Scheduler continuously adapts placement while preserving execution identity.
Operational adaptation should not redefine execution correctness.
Verification Placement
Verification itself requires scheduling.
The Scheduler determines:
- which shards require verification
- where redundant execution occurs
- where integrity policies execute
Verification placement belongs to the Scheduler.
Verification semantics belong to the Verification subsystem.
Fairness Coordination
Forge is designed for planetary infrastructure.
The Scheduler therefore balances:
- performance
- opportunity
- provider participation
- workload distribution
- operational efficiency
Fairness is treated as an architectural property rather than an accounting feature.
Scheduling Lifecycle
Scheduling is a continuous decision process.
Observe Runtime State
│
▼
Evaluate Eligible Agents
│
▼
Score Placement Candidates
│
▼
Assign Execution
│
▼
Monitor Runtime
│
▼
Adapt Placement
│
▼
Observe Runtime StateThe Scheduler continuously reevaluates operational conditions without modifying execution semantics.
Placement Policies
Different workloads emphasize different optimization goals.
The Scheduler supports policy-driven placement strategies.
Examples include:
Latency-Oriented
Prioritize response time for interactive workloads.
Throughput-Oriented
Maximize aggregate execution throughput for large distributed jobs.
Verification-Oriented
Increase redundancy and validation coverage.
Fairness-Oriented
Promote balanced participation across compute providers.
Cost-Oriented
Reduce execution cost while preserving execution guarantees.
Locality-Oriented
Prefer infrastructure that minimizes data movement.
Policies influence placement.
They never redefine computation.
Agent Evaluation
Eligible Agents are continuously evaluated using multiple operational signals.
Signals may include:
- availability
- historical reliability
- execution throughput
- observed latency
- hardware suitability
- bandwidth
- verification history
- current utilization
- geographic location
- execution history
The precise scoring model may evolve over time.
The architectural responsibility remains constant.
Scheduling Invariants
The following properties must remain true.
Placement never changes execution semantics.
Scheduling never modifies execution contracts.
Scheduler decisions remain observable.
Verification placement remains explicit.
Resource optimization remains independent of workload meaning.
Scheduling preserves replayability.
Equivalent execution contracts should preserve explainable placement decisions.
Heterogeneous Infrastructure
The Scheduler assumes infrastructure diversity.
Participating Agents may differ in:
- processor architecture
- operating system
- cloud provider
- geographic location
- available memory
- accelerator hardware
- network quality
- storage performance
Infrastructure diversity is expected.
Scheduling exists because infrastructure is heterogeneous.
Failure Model
The Scheduler assumes continuous operational change.
Examples include:
- Agent disappearance
- network degradation
- queue growth
- transport interruption
- infrastructure overload
- verification rejection
- shard retry
- temporary isolation
The Scheduler continuously recomputes placement decisions while preserving execution integrity.
Observability
The Scheduler continuously emits operational metadata.
Examples include:
- placement decisions
- Agent scores
- scheduling latency
- rebalance events
- verification placement
- queue depth
- dispatch timing
- runtime utilization
These signals allow scheduling behavior to be inspected and analyzed.
Contribution to Execution Evidence
The Scheduler contributes placement metadata to Execution Evidence.
Examples include:
- placement decisions
- selected Agents
- scheduling timestamps
- placement policy
- rebalance history
- verification routing
- locality information
This information allows placement decisions to be understood during replay and audit.
Architectural Guarantees
The Scheduler is designed to preserve:
- deterministic placement discipline
- explicit scheduling policies
- replayable placement metadata
- heterogeneous infrastructure support
- continuous operational adaptation
- fairness across providers
- observable scheduling decisions
- separation between placement and computation
Architectural Non-Goals
The Scheduler intentionally does not:
- execute workloads
- define primitive semantics
- modify execution contracts
- aggregate results
- perform verification
- interpret business logic
- optimize correctness through hidden computation
Its responsibility ends at execution placement.
How to Verify Scheduler Behavior
A technical evaluator can inspect Scheduler behavior by observing one execution.
Suggested verification path:
- Submit a workload.
- Inspect the execution plan.
- Observe shard placement decisions.
- Compare selected Agents.
- Observe scheduling metadata.
- Trigger a rebalance scenario.
- Inspect verification placement.
- Review preserved scheduling evidence.
The observed placement decisions should correspond to the architecture described in this document.
Related Documentation
Continue with:
- Agent Kernel Architecture
- Aggregation Layer
- Scaling Architecture
- Transport Architecture
- Network Architecture
Final Mental Model
The Scheduler does not decide what a workload means.
It decides where that workload should execute.
Execution meaning belongs to the runtime.
Execution placement belongs to the Scheduler.
That distinction preserves both performance and execution integrity.