Deterministic randomness by virtualizing wasi:random

[lann]

Guest languages route randomness through wasi:random — including transitive dependencies and runtime internals (hashmap seeds). So instead of SDK-level RNG discipline (unenforceable convention), composition can inject determinism structurally: a provider component exports wasi:random to the suite, deterministically seeded under runner control. No guest cooperation needed, in any language; there is no ambient entropy to cheat with.

Shape

• The provider exports wasi:random to the suite and a seed-control surface to the runner core — the context-provider topology again, and plausibly the same component: the factory already marks case boundaries, so new-context(seed) can reseed the wasi:random stream per case, even on a shared suite instance.
• Default seed derived from the case name (reproducible-by-name with zero configuration); runner overrides for exploration runs or replay.
• Results schema (L4): record the effective seed per case; runners support replay by re-provisioning a recorded seed.
• Composition: one more provider node in the component-test CLI: compose via wac-graph, not wac script + binary #19 wac-graph (sibling of, or folded into, the context provider).

This doubles as a flagship demonstration of component-native test infrastructure: native harnesses fight for determinism with preload hacks and per-language RNG plumbing; here it is one node in the composition graph.

Limits (do not oversell)

1. Determinism ≠ randomness alone. Clocks (wasi:clocks is virtualizable the same way — cf. webrtc-datachannels' Shadow lab for where full network/time determinism leads), host-import completion order, and cooperative scheduling nondeterminism remain. This makes the case's own logic replayable, not the whole execution.
2. insecure-seed is consumed at instance startup (hashmap seeding): per-case reseeding governs get-random-bytes streams; instance-level seeds are set once. Clean under instance-per-case runners; a documented nuance for shared instances.
3. Pass-through policy: suites testing cryptography may need real entropy semantics for specific cases; the provider should support pass-through, selectable by runner policy.