Forge Pool

Appearance

Core Concepts ​

How Forge Pool Actually Works ​

This page explains the operational concepts behind Forge Pool.

If you understand these concepts, the rest of the system becomes much easier to reason about.

The System at a Glance ​

Forge Pool consists of:

  • Web Core
  • Hub
  • Agents
  • the Planetary Kernel
  • primitive families and profiles
  • deterministic aggregation
  • platform memory surfaces
  • ledger and observability layers

These are not interchangeable terms.

Each has a specific role.

The Planetary Kernel ​

The Kernel is the deterministic execution substrate of Forge Pool.

It:

  • enforces execution semantics
  • normalizes workload classes
  • decouples domain adapters from compute truth
  • preserves replay and audit structure
  • allows the execution system to expand through primitive families and profiles

Adapters are projections.

The Kernel is the substrate.

Learn more: → Execution Model

Web Core ​

Web Core governs:

  • authentication
  • authorization
  • billing ledger
  • project isolation
  • rate limits
  • policy validation
  • job registration
  • public API lifecycle

Web Core does not execute workloads.

It governs access before execution begins and shapes the public response surface after execution completes.

Hub ​

The Hub is the deterministic orchestrator of the runtime.

It is responsible for:

  • shard planning
  • agent scheduling
  • policy enforcement at execution level
  • verification routing
  • aggregation coordination
  • artifact emission
  • replay metadata generation

The Hub does not perform heavy compute itself.

It enforces execution structure.

Agents ​

Agents are shard-level execution workers.

They:

  • receive shard assignments
  • execute deterministic kernels
  • return partial results
  • report execution metrics
  • participate in verification when required

Agents may run on:

  • CPU
  • GPU
  • heterogeneous hardware

No single agent defines truth.

Truth emerges from deterministic aggregation.

Primitive Families ​

A primitive family is a canonical execution class.

Examples include:

  • mc@1
  • graph@1
  • search@1
  • media@1
  • tensor@1
  • ensemble@1

Primitive families define computational class.

They are not route names and not marketing labels.

Profiles ​

Profiles specialize a primitive family into a workload-specific execution shape.

Examples:

  • insurance.v1
  • eta.v1
  • matmul.v1
  • transcode.v1

A valid mental model is:

  • primitive family = execution class
  • profile = workload specialization

For example:

  • matrix multiplication is better understood as tensor@1 + matmul.v1
  • media transcode is better understood as media@1 + transcode.v1

Jobs ​

A job is a single Kernel execution request.

It contains:

  • ctx — identity and billing context
  • op — primitive family, version, profile
  • args — workload parameters
  • seed — randomness control
  • policy — execution constraints

Jobs are:

  1. registered
  2. sharded
  3. executed
  4. aggregated
  5. optionally verified
  6. archived as replayable truth surfaces

Jobs are immutable once completed.

Shards ​

A shard is a deterministic partition of a job.

Example:

1,000,000 iterations
→ 10 shards
→ 100,000 iterations each

Shards allow:

  • horizontal scaling
  • fault isolation
  • verification sampling
  • heterogeneous scheduling
  • elastic compute expansion

Shard planning is deterministic.

Determinism ​

Forge Pool enforces:

  • deterministic shard planning
  • seed-controlled randomness
  • deterministic aggregation
  • replayable execution traces

Same contract → same output.

Determinism enables:

  • replay
  • audit
  • regulatory defensibility
  • institutional trust

Learn more: → Determinism
→ Replay

Verification ​

Verification strengthens distributed correctness.

It may include:

  • shard duplication
  • cross-agent consistency checks
  • result hashing
  • statistical validation
  • workload-specific integrity checks

Verification is optional, but structural.

It is policy-controlled.

Adapters ​

Adapters translate domain-specific input into canonical Kernel workloads.

Examples:

  • insurance risk → mc@1 with an insurance profile
  • ETA forecasting → mc@1 with eta.v1
  • matrix multiplication → tensor@1 with matmul.v1
  • media transformation → media@1 with transcode.v1

Adapters:

  • validate domain payloads
  • map them to the Kernel contract
  • shape outputs for domain consumption

Adapters are interface layers.

They do not define execution semantics.

Memory Surfaces ​

Execution without memory is incomplete.

Forge exposes supporting memory surfaces such as:

  • Blob storage
  • KV state
  • VMem
  • replay artifacts
  • snapshot and artifact references

These surfaces enable:

  • multi-step workflows
  • state-aware pipelines
  • deterministic replay over time
  • artifact persistence

Memory turns distributed execution into an operational computer.

Credits and Ledger ​

Forge Pool uses deterministic accounting around execution.

Clients:

  • spend credits for execution

Providers:

  • earn credits for validated shard execution

Billing derives from:

  • execution time
  • resource usage
  • verification overhead
  • workload type
  • policy choices

All usage is recorded in the ledger.

System Summary ​

Forge Pool consists of:

  • HQ — control interface
  • Web Core — governance and public API layer
  • Hub — deterministic orchestrator
  • Agent mesh — execution layer
  • Kernel — execution contract
  • aggregation layer — deterministic reduction
  • memory surfaces — artifact and state support
  • ledger — economic layer

Together, they form a distributed deterministic execution system.

Mental Model ​

Forge Pool is not merely “where compute runs.”

It is how compute becomes:

  • reproducible
  • verifiable
  • replayable
  • defensible

Understanding this structure lets you design correctly on top of it.