Forge Pool

Appearance

Determinism Model ​

Determinism is not an optimization in Forge Pool.

It is part of the execution contract.

Without determinism:

  • auditability collapses
  • replay becomes unreliable
  • billing and verification become disputable
  • distributed execution loses legal and operational defensibility

Forge therefore treats determinism as a first-class Kernel requirement.

What Determinism Means in Forge ​

Given identical execution contract inputs, the Kernel must produce identical final outputs.

That includes identical:

  • workload identity
  • profile identity
  • canonical args
  • seed behavior
  • reduction semantics

In practical terms, identical requests must yield identical results under the same runtime doctrine.

Deterministic Guarantees ​

Given identical:

  • op.name
  • op.version
  • op.profile
  • canonical args
  • seed
  • reduction rules
  • relevant execution-policy semantics

the Kernel guarantees:

  • identical shard planning behavior
  • identical shard seed derivation
  • identical partial execution meaning
  • identical aggregation outcome
  • identical replay references sufficient for rerun and audit

What Is Allowed to Vary ​

Not every operational property must remain identical.

These may vary without violating determinism:

  • agent identity
  • routing order
  • geographic placement
  • exact wall time
  • transient infrastructure path

Determinism governs result truth, not transport coincidence.

Sources of Non-Determinism ​

The system is explicitly designed to mitigate common sources of drift:

  • uncontrolled random number generation
  • floating-point instability
  • inconsistent shard partitioning
  • nondeterministic reduction ordering
  • implicit time-based entropy
  • hidden environment-sensitive branching

If any of these influence final result meaning, determinism is broken.

How Forge Mitigates Non-Determinism ​

The Kernel enforces determinism through:

  • controlled seed discipline
  • deterministic shard derivation
  • versioned execution semantics
  • stable reduction ordering
  • explicit workload identity
  • replay-grade metadata capture

This allows the system to remain reproducible even when infrastructure itself is heterogeneous.

Seed Discipline ​

Randomness is allowed.

Uncontrolled randomness is not.

Forge supports two seed modes:

Derived ​

The Kernel derives a deterministic root seed from the execution contract.

Explicit ​

The caller supplies the root seed directly.

In both cases, shard-level seeds must be derived reproducibly from the root seed and shard identity.

This is how probabilistic execution becomes replayable instead of merely stochastic.

Shard Reproducibility ​

Determinism requires shard planning itself to be reproducible.

That means identical inputs must lead to:

  • compatible shard boundaries
  • stable seed derivation
  • stable reducer expectations
  • stable result interpretation

A workload cannot be considered deterministic if it only preserves final reduction while varying the semantic meaning of shards.

Reduction Stability ​

Distributed execution is only deterministic if reduction is deterministic.

This means:

  • reduction ordering must be controlled
  • reducer semantics must be stable
  • workload-specific aggregation rules must be versioned
  • agent return order must not alter final output meaning

Reduction is part of execution truth, not a convenience layer after execution.

Versioning and Determinism ​

Determinism is always tied to workload identity.

That means:

  • primitive family version matters
  • profile version matters
  • reducer behavior matters
  • execution semantics version matters

If any of these change, output differences may be valid.

That is not a determinism failure. That is a version change.

What Breaks Determinism ​

The following violate Kernel doctrine:

  • time-based entropy inside execution
  • hidden randomness not tied to seed discipline
  • local semantic overrides of workload meaning
  • reducer changes without version changes
  • hidden environment state that changes result meaning
  • agent-specific behavior that leaks into final result truth

These are not implementation details. They are contract violations.

Why Determinism Matters Strategically ​

Forge Pool is designed for workloads where trust matters:

  • financial workloads
  • insurance workloads
  • risk systems
  • scientific execution
  • regulated analytical environments

In these domains, “close enough” is not good enough.

Determinism is what turns distributed execution into something defensible.

Relationship to Replay ​

Replay depends on determinism, but is not identical to it.

  • determinism says the same contract must yield the same outcome
  • replay says the system preserves enough truth to reproduce and audit that outcome later

Replay is impossible without determinism.

Final Note ​

Forge does not treat determinism as an implementation preference.

It treats determinism as part of the public promise of the Kernel.