Targets, shards & pooling

A target is a contract

A target is a substrate plus a pinned walk contract that every shard must satisfy: the geometry (with a content hash), the diffusivity, the save grid, the capability tiers, and a walk_profile — a hash of everything that determines the sampled distribution (simulator + version, per-compartment D, feature radii, field grid, susceptibility scale). Two shards with the same walk_profile and geometry sample the same distribution and are poolable; a different simulator or version produces a different hash and is refused.

target/
  target.json          # the contract + shard ledger
  <id>__inner.ply.xz   # archived geometry (open PLY, xz)
  <id>__outer.ply.xz
  shards/              # curated, accepted shards
  inbox/               # uncurated submissions, awaiting QA

A shard is one independent walk

Contributors claim a disjoint seed (a random 48-bit self-assignment — no allocator needs to be running) and walk one shard. Independence is what makes pooling honest: overlapping seeds would double-count. Each shard records its own seed so collisions are detectable.

Pooling on replay

The pool is never a monolith you rebuild; it's the set of shard files, combined at decode time:

• each shard replays to a complex signal, weighted by its total spin-weight;
• the weighted average is the pooled estimate;
• the pooled Monte-Carlo floor is measured, not assumed — a split-half over the shards gives an unbiased σ that falls as 1/√ΣN.

Completeness is two-dimensional

A target is done when the measured floor clears σ* and the pool reaches the target walk length — enough walkers, walked long enough. A cheap optimistic estimate is shown for progress, but only a measured floor can flip a target to complete. See what it means to solve a substrate.