Deterministic Randomisation Technical Reference

Deterministic Randomisation — Technical Reference

This is the exact reproducibility reference: tuple framing, named-draw protocol, mapping rules, statistical qualifications, and claim boundaries. If you only need to repeat a batch or reuse a visible seed, start with Randomisation and Seeds.

The application version/build is part of the reconstruction contract. These rules describe v3; they do not promise identical planner paths in every future FWG release.

The v3 contract

Deterministic draws use:

• engine: FWG-SHA256-v1
• draw model: named-draws-v1

Each draw hashes the UTF-8 JSON tuple:

[engine, model, domain, seed, path]

FWG reads the first 32 digest bits in big-endian order and maps them to an integer, pool choice, probability result, weighted choice, or unit float.

A fixed compatibility vector makes that contract independently testable:

input tuple:
["FWG-SHA256-v1","named-draws-v1","explorer","123456789012","1/start/pot1"]

SHA-256 digest:
ac54b7f3c4372d7ac8ae421dfceb015d4f62dbac5a1cba8329a0e2b206f7b38a

first uint32, big-endian:
2891233267

This vector tests tuple framing, UTF-8 serialisation, the hash primitive, digest extraction, byte order, and the raw 32-bit result. It does not test every planner path or every later mapping rule.

SHA-256 is used as a public deterministic sound-design mixing primitive. FWG is not a password, authentication, signature, secrecy, credential, key-derivation, or access-control system.

Threat model and deliberate non-goals

⚠️ The named-draw system is designed to provide:

• reproducible sound-design decisions;
• stable named addressing instead of one fragile sequential PRNG stream;
• a large default seed namespace;
• inspectable, versioned mapping rules; and
• enough recorded context to regenerate a patch and its output.

It is not designed to resist a malicious user who fabricates or edits a JSON record. There is no secret key, HMAC, digital signature, trusted timestamp, remote attestation, or tamper-evident log. Anyone who knows the seed, domain, path, and versioned rules can calculate the same draw.

A matching seed and record can demonstrate internal consistency and reproducibility. They do not, by themselves, authenticate who created the record, when it was created, which computer historically ran it, or whether some different workflow was also used. Those questions require ordinary provenance and chain-of-custody evidence. For most users, cloud-storage/version history, project files, backups, publication, and transfers are the practical provenance layer; specialised users can add external signatures or trusted timestamps. See Authenticating and Timestamping FWG Outputs.

Claim boundary

The strongest independently testable claims are:

• algorithmic: the identified executable maps the exact disclosed tuple to the recorded raw and mapped draws;
• reproducibility: a compatible implementation supplied with the effective inputs can regenerate the recorded planner decisions and output;
• input-boundary: the audited generator-only path has no documented input for an earlier work or features extracted from it; and
• negative security claim: the sidecar is not authenticated, signed, backed by a trusted timestamp, remotely attested, or tamper-evident. It does contain an ordinary created_utc field, but that field is not independently certified.

The construction does not independently establish historical execution, absence of browser compromise, absence of modified code, absence of external target-guided selection, or the motives and knowledge of a human operator.

Scope note: Reproduction proves that the disclosed recipe is sufficient. It does not prove that the recipe was the historical route by which the output was first created. Any stronger forensic claim must be supported by contemporaneous external provenance.

Default seeds

Bulk Random and Explorer generate default seeds as 26 characters from:

abcdefghijklmnopqrstuvwxyz234567

Every visible position has 32 possible symbols, so the generated-token namespace contains:

32^26 = 2^130

The browser obtains 26 bytes from crypto.getRandomValues() and uses the low five bits of each byte. Because 256 is exactly divisible by 32, every symbol has exactly eight byte preimages. The symbol mapping itself therefore adds no modulo bias, assuming the browser supplies uniform bytes as intended by the Web Crypto API.

It is more precise to describe this as a 130-bit default token namespace. Under the Web Crypto random-source and uniform-generation assumptions, each generated token is intended to carry 130 bits of generated uncertainty. The Web Crypto specification calls getRandomValues() cryptographically strong but explicitly provides no lower bound on information-theoretic entropy. FWG therefore does not measure or attest the true physical entropy available inside a particular browser, operating system, or device.

The generated token is already the text FWG hashes. It is not decoded or canonicalised as a binary Base32 value.

What random-source quality changes — and what it does not

Browser RNG quality matters to claims about how uniformly honest default seeds sample the namespace, how much uncertainty a generated token carries, and how often accidental duplicate seeds may occur. A weak, biased, or predictable generator can reduce those properties; hashing cannot manufacture entropy that was absent from the seed source.

That is not the main boundary for a post-hoc target-construction attack. An adversary trying to manufacture a seed for an already fixed output can choose candidate seed text directly and does not need to use FWG's honest seed generator at all. The relevant obstacle is the public seed-to-draw-to-output mapping and the size of the target's acceptance set. A weak honest RNG can make accidental repetition more likely, but it does not create a gradient from an arbitrary target output back to a satisfying seed.

If the same seed is unintentionally repeated under the same version, domain, paths, fixed settings, iteration, direction, and other effective inputs, the deterministic result repeats. That is inconvenient for novelty and batch uniqueness, but unlike nonce reuse in DSA, ElGamal, or related cryptographic systems, it does not disclose a secret key or compromise authentication because FWG has no such secret.

For any collision among n uniformly generated 130-bit default tokens, the birthday approximation is:

P(any duplicate) ≈ 1 - exp(-n(n-1) / 2^131)

Illustrative values are approximately:

1 million generated seeds   3.7 × 10^-28
1 billion generated seeds   3.7 × 10^-22
1 trillion generated seeds  3.7 × 10^-16
50% collision point         4.34 × 10^19 generated seeds

Even a duplicate complete seed is only the first event in a much longer consequential-collision chain. The same effective generation context must also be used; both outputs must be auditioned and selected; both must enter recorded music; both works must reach overlapping audiences; the shared element must be noticed and matter; and the dispute must be significant enough for at least one producer to incur the cost of legal action. That practical chain may dominate the real-world risk even before considering the already remote healthy-RNG collision probability.

A severely defective RNG could change those figures. Repeated state, a tiny effective support, or deterministic reuse across cloned environments could produce duplicate tokens far more often than the nominal birthday calculation. A catastrophic system-wide cryptographic RNG failure could also have consequences far beyond FWG, although a defect confined to the JavaScript-facing API would not automatically prove that a browser's TLS implementation uses the same broken path. For FWG, the immediate consequences remain duplicate creative material and weakened uncertainty claims rather than secret-key compromise.

Scope note: SHA-256 can make biased or structured seed text look computationally mixed, but it cannot raise the seed's information-theoretic entropy. A claim that a particular generated token carried 130 bits still depends on the browser random-source assumption. The narrower target-inversion claim does not.

Users may replace it with arbitrary text. Case, internal spaces, punctuation, dashes, and Unicode representation are significant. FWG does not apply Unicode normalisation, so visually identical composed and decomposed text can produce different draws. The current UI trims leading and trailing whitespace; committing an empty value generates a fresh default seed.

Timestamped generated seeds — considered, not adopted

Current result JSON already records created_utc. That is a useful, compact statement of when each export artifact was constructed, but it is not a trusted timestamp. In a batch, rendering and artifact construction may continue for minutes, so individual result sidecars can legitimately carry different creation times. The time associated with a seed would answer a different question again: when that particular seed was generated, which may be well before the file was rendered or exported.

A possible future construction would append a compact, lowercase Base32 encoding of epoch milliseconds to the existing 26-character random token, separated by a hyphen. This has two limited potential benefits:

• if a defective RNG repeats the same random token at different times, the complete seed strings would still differ; and
• the claimed seed-generation time would be computationally bound into the seed-to-output mapping, so those timestamp characters could not later be changed while preserving the same output without finding another satisfying seed.

That binding would substantiate but not prove time. The seed remains user-editable, the system clock may be wrong, and anyone can deliberately enter a seed containing arbitrary timestamp text before generating an output. A facially impossible or implausible date — for example, one long predating FWG or the relevant browser platform — would carry little evidentiary weight. A plausible embedded time could be compared with release archives, backups, commits, transfers, correspondence, and publication history, but would not replace external corroboration.

The proposal also has ambiguous semantics in a multi-seed application. START, END, Bulk, Explorer, hidden next-action state, and later randomisations may all use seeds generated at different times. A batch may then produce files over several minutes. An embedded timestamp would describe seed generation, not necessarily patch completion, render start, WAV completion, JSON construction, publication, or possession.

Recording a claimed seed origin such as browser_crypto, user_entered, GET_parameter, or imported would add little security or reconstruction value. Such a field would be trivial to edit, and the reproduction problem depends on the exact seed text and versioned mapping, not the story of how the seed was obtained.

A timestamp should not be treated as a fallback random source. A timestamp-only or timestamp-plus-weak-random fallback could make a much smaller effective search space look superficially like an ordinary generated seed. If this idea were ever adopted, the full 130 random bits should remain and the time suffix should be an additional diversity and contextual-evidence component only.

Current decision: retain the plain 26-character, 130-bit generated token. Do not append a timestamp and do not introduce a hidden fallback seed construction. Keep the question documented and open for reconsideration if defective-RNG resilience or evidentiary use becomes a concrete requirement.

Independent seed state and separated domains

The stable domains are:

• playground
• morph
• explorer
• bulk

The domain is part of the hashed tuple. An identical seed and path in two domains therefore hashes two different framed inputs. Their retained 32-bit outputs are expected to differ under ordinary SHA-256 assumptions, but they are not guaranteed to differ because truncation collisions remain possible.

The workspaces also keep separate seed state. Changing one workspace's next seed does not consume or advance another workspace's seed.

Visible and hidden seeds

Visible

• Bulk Random
• Bulk Explorer

Hidden next-action seeds

• Playground
• Morph START
• Morph END

Hidden seeds let ordinary endpoint Randomise actions remain deterministic without adding more controls to the endpoint interface.

Named paths

Choices use stable human-readable paths rather than one sequential PRNG stream.

Adding an unrelated draw does not shift every later choice, provided the existing engine/model/domain/seed/path construction and mapping rules remain unchanged.

Different paths are separately addressed, but all draws made from one seed are deterministic functions of that same seed. They do not create unlimited independent entropy. Under the ordinary assumption that SHA-256 behaves pseudorandomly on these distinct framed inputs, differently addressed outputs are expected to behave as computationally decorrelated values for this non-security use. That expectation is not a proof of statistical independence, and the planner can introduce its own dependencies by conditionally requesting, locking, rewriting, or ignoring draws.

Scope note: “Domain separation” is reasonable shorthand for including domain in the hashed tuple, but it must not be read as a keyed security guarantee. The practical claim is deterministic namespace separation: the same seed/path in different domains hashes different framed input bytes.

Changing the hash primitive requires a new random-engine identity. Changing the core tuple framing, encoding, digest extraction, or primitive mapping rules requires a new draw-model identity. The exact application version and executable hash remain part of the reproduction contract because a later planner may add paths, stop requesting paths, or assign path results to different sound-design decisions. Human-readable paths are protocol data inside a particular versioned planner, not eternal global identifiers whose semantics must remain unchanged in every future FWG release.

Because Render Diagnostics can expose named-draw paths plus mapped candidate/result values, shipping planner vocabulary uses semantic release-facing names rather than development-stage labels. Those exact strings matter when reproducing the recorded application version/build, but a later explicitly versioned planner may legitimately use different semantic paths.

Scope note: Reusing or repurposing a path in a later application version is not a cryptographic collision and need not reproduce the older planner. The defensible contract is exact reproduction with the recorded application version/build and its declared random engine/model. Silent semantic reuse inside the same declared versioned contract would be a defect; an explicit later version may intentionally differ.

Base Generator Chance namespaces the broad-preset lottery

For Unrestricted and Absurd, the persisted Base Generator Chance is not merely a threshold applied to one fixed random word. Its integer percentage prefixes the per-file sound-design namespace once, almost like an additional deterministic salt while leaving the visible Random Seed unchanged.

For example, an Unrestricted START decision at iteration 9 can use:

80/9/start/generator_type
80/9/start/engine_family/base

Changing the control to 83 addresses different deterministic draws:

83/9/start/generator_type
83/9/start/engine_family/base

The prefix applies to the broad-preset file's random START/END sound design and random Morph-policy decisions, so changing the percentage deliberately selects a different deterministic sound-design lottery across the batch. Returning to the same seed + percentage reproduces the same decisions. Named draws outside that broad-preset design namespace are not shifted because the system remains address-based rather than sequential.

The percentage therefore forms part of the effective random-planning input and is recorded in broad-random generation context.

32-bit mapping and modulo bias

One named path produces one unsigned 32-bit value in the range 0 through 2^32 - 1.

Integer ranges and ordinary pool choices use direct reduction:

uint32 mod span

When span divides 2^32, the mapping is exactly uniform. This includes important FWG spans such as 2, 256, 512, and 4096.

When span does not divide 2^32, a small modulo bias exists. Let:

M = 2^32
q = floor(M / span)
r = M mod span

Then r outcomes receive q + 1 possible 32-bit source values and the remaining outcomes receive q source values. No outcome's absolute probability differs from the ideal uniform probability by as much as 2^-32, approximately:

0.00000000023283064365

That is about one part in 4.3 billion of absolute probability. It should not be confused with the relative skew of a very rare bucket or with the total distance between two complete distributions.

For example, the largest current public integer span found in the named planners is the Absurd Pitch Offset magnitude range of 2,400,000 hundredth-cent values. For that unusually large span:

• the maximum absolute per-outcome probability error is approximately 1.33 × 10^-10;
• the maximum relative deviation of one bucket from its ideal probability is approximately 0.0318%; and
• the total variation distance from an exactly uniform 2,400,000-way distribution is approximately 0.0137%.

That is acceptable for exploratory sound design and would be unacceptable as an unmentioned assumption in a security protocol. FWG is explicitly the former.

Probability draws use floor(p × 2^32) as a threshold, so their absolute probability error is also less than one 32-bit step. Weighted choices place cumulative weight boundaries on the same 32-bit grid. Unit floats are uniform over exactly 2^32 discrete values in [0, 1), not over a continuous mathematical real interval.

The direct modulo mapper is fit for purpose. Rejection sampling could remove the mathematically measurable bias, but even under extraordinary use it would provide no measurable musical or workflow benefit. It would require a versioned retry rule, could consume more than one digest-derived value for a named decision, and would change existing deterministic outputs. Any later change would require a new draw-model identifier rather than silently redefining named-draws-v1.

Scope note: “No measurable musical or workflow benefit” is a product judgement supported by the quantified scale of the bias and FWG’s purpose; it is not a mathematical theorem. A scientific sampler, lottery, adversarial protocol, or compliance regime could reasonably require exact categorical uniformity even where FWG does not.

The named-draw trace studies use idealised uniform-choice probabilities such as log2(pool size). Their reported bit totals intentionally ignore this tiny mapping bias and are not exact cryptographic entropy measurements.

Why retain only 32 digest bits?

The browser computes the complete SHA-256 digest for every named path. Retaining the first 32 bits does not reduce the hashing cost; it simplifies the deterministic mapping that follows.

A single unsigned 32-bit value:

• is represented exactly by ordinary JavaScript number arithmetic, without BigInt conversion or cross-runtime BigInt details;
• maps directly into FWG’s current integer ranges, pool indices, chance thresholds, weighted choices, and 2^32-step unit-float grid;
• keeps one named path tied to one compact, fixed-size raw result and straightforward compatibility vectors; and
• provides far finer numerical granularity than any current musical control or practical sound-design workflow can use.

Using more digest bits would reduce the already immaterial modulo bias and path-level collision rate. It would not add independent seed entropy, improve SHA-256 itself, or provide a measurable musical or workflow benefit - even under extraordinary use. Changing the retained width or extraction rule would also change deterministic outputs and require a new draw-model identifier.

Scope note: The retained width is adequate for the current mapped control domains, but it is also a real compatibility and collision boundary. A future feature that required more than 2^32 distinguishable raw outcomes, materially lower path-collision rates, or a security property would need a new model rather than relying on this rationale.

Path-level collisions and complete-patch matches

A retained 32-bit value has only 2^32 possible results. A path-level collision occurs when different seeds produce the same retained 32-bit value for the same named path. Such collisions are expected and are not a defect. Across uniformly distributed candidate inputs, the birthday approximation reaches a 50% chance of at least one repeated raw 32-bit value after roughly 77,000 samples of the same path.

Mapped choices often contain far fewer than 2^32 outcomes, so many seeds necessarily select the same result for one parameter. A mapped-choice collision is therefore much more common than a raw 32-bit collision. FWG does not use either one as a unique patch identifier.

Different named paths from one seed can also retain the same raw 32-bit value. Under the ordinary pseudorandom-output assumption, even that raw cross-path equality is rare within a current trace: approximately 1 in 41 million for 15 draws and 1 in 3 million for 54 draws. More importantly, raw equality is not ordinarily an error condition. Some paths interpret the word through different mappings — for example, a 0–4095 slider, a Wavetable Type pool, a filter/off choice, or a probability threshold — while other paths may use the same mapping or may resolve to the same final setting. In every case, FWG permits equal control values as valid sound-design outcomes and does not require named draws to be unique.

Cross-path equality would become a defect only if some future code incorrectly relied on raw named draws being unique identifiers or treated equal mapped settings as invalid. Current planners do neither.

These are distinct questions:

• collision: can any two inputs be found that share a result? Truncation makes raw path collisions generic at about 2^16 samples by the birthday rule;
• preimage-style search: given a required result or vector of results, can a satisfying seed be found? The work depends on the acceptance set and searched seed distribution;
• second-preimage-style search: given one disclosed seed/recipe, can a different acceptable seed/recipe be found? This again depends on what counts as equivalent; and
• complete audio equivalence: can another patch or workflow render the same or acceptably similar WAV? Many-to-one DSP, inactive controls, quantisation, cleanup, and broad perceptual criteria can make this easier than matching every recorded draw.

The difficulty of deliberately matching a complete patch depends on the simultaneous effective constraints across its relevant paths, the number of acceptable alternatives, the seed namespace being searched, planner dependencies, and non-random settings. It is not the security strength of one 32-bit value or the 256-bit width of the underlying digest.

Scope note: SHA-1/SHA-256 collision results, 32-bit truncation collisions, seed preimage search, trace-vector matching, exact-patch matching, and perceptual target matching are different problems with different costs.

Successful and failed actions

Bulk and Explorer use the following seed-advance rule:

• success advances the visible seed;
• cancellation, validation failure, or render failure retains it.

This supports exact retry after an interrupted job while reducing accidental duplicate batches after success.

URL seed parameters

Whitelisted parameters in the page URL's query string, commonly called GET parameters, can set the next random seed for testing or reproduction. Add them after ?, using the documented parameter names:

• explorer_seed
• bulk_seed
• morph_seed_start
• morph_seed_end

They do not:

• load a patch;
• start randomisation;
• start export; or
• form a general URL patch format.

Playground deliberately has no URL seed override.

Seed, trace, and complete patch

A seed does not replace the complete JSON record.

Reproduction may also depend on:

• application version;
• domain and batch index;
• selected Bulk pool or Explorer rules;
• named paths and planner;
• current endpoint and Morph state;
• direction;
• render and cleanup settings; and
• optional MPC geometry.

Ordinary Bulk Random result sidecars store the seed, random engine/draw model/planner identity, selected pool/profile/branch context, resolved complete patch, and file-specific settings needed for reconstruction. The full internal named-draw execution trace is not repeated in ordinary user sidecars. Detailed trace work can instrument the planner directly or use Render Diagnostics when user-facing support evidence is needed. Morph endpoint randomisation can store the endpoint's random-origin seed, generated snapshot, and later changed fields.

With Render Diagnostics enabled through the ?render_diagnostics=a URL query parameter, rendered Bulk Random, Bulk Explorer, and Morph random-origin sidecars can additionally include a verbose mapped named-draw trace. The diagnostic trace is optional support/verification evidence, ignored on import, and does not replace the compact ordinary provenance records.

A JSON sidecar is ordinary editable data. Reproducing its output verifies that the disclosed recipe is sufficient and internally consistent. It does not make the sidecar self-authenticating.

Seed entropy, reachability, and audible variation

The prominent bit counts describe different things:

• one generated default token selects from a 2^130 namespace;
• SHA-256 produces a 256-bit digest for each named path;
• FWG retains 32 bits from each digest for that mapped draw.

None of those numbers is automatically the entropy of a final patch or WAV.

For one fixed planner and one generated default seed, the independently supplied randomness cannot exceed the uncertainty in that seed, with 130 bits being the intended default under the browser-RNG assumption. The hash can expand the seed into enough deterministic draws to describe a much larger theoretical combination of settings, but only a sparse seed-selected subset of that theoretical space is reachable.

User-entered seeds are bounded to 128 UTF-8 bytes in the current application. The shortest ordinary committed user seed may be one character; the hash core can process an empty string, although the normal UI treats a blank committed value as a request for a fresh default. String length is not an entropy measurement: a known or deliberately chosen seed may provide little or no uncertainty.

A simple planner may expose much less effective variation because many seeds can converge on identical or equivalent outcomes. A complete patch assembled from separately randomised START and END origins may incorporate more than one seed and may therefore contain more independent input uncertainty than one default token if those origins were themselves generated independently. Merely storing two seed strings does not establish independence.

Audible effect is not distributed evenly across mathematical information. A choice that changes engine family, silence/noise state, or a major Morph relationship may matter much more perceptually than several bits spent on an inactive or barely audible parameter.

If a default seed is generated uniformly from the 2^130 token namespace and the acceptance criterion effectively identifies only one or very few tokens, exhaustive recovery is computationally infeasible with known classical methods. Broad audible similarities, equivalent parameterisations, and targets accepting many outputs can occur under many different seeds and can be vastly easier to find.

A useful abstract model is to define an explicit acceptance predicate over candidate seeds. If a fraction α of the searched seed distribution is acceptable and no exploitable structure is known, blind search takes about 1/α trials on average. The difficult part is justifying α; a trace-bit sum is not automatically that justification because named decisions can be dependent, conditional, inactive, many-to-one, or perceptually irrelevant.

Scope note: Every search-hardness statement should name the target, acceptance tolerance, seed distribution, planner, fixed settings, and attacker capabilities. “A sufficiently constrained target” is intentionally conditional and should not be promoted into a universal security level.

Why SHA-256?

SHA-1 already outputs more than the 32 bits retained for each named draw, and its known collision weakness is not the same as the complete multi-path seed-preimage problem relevant here. SHA-256 does not increase the raw-result granularity of one draw beyond 32 bits or increase the default token namespace beyond 2^130.

SHA-256 was chosen for the first public named-draw contract primarily to avoid a distracting argument based only on the headline that SHA-1 is broken. It is also a current standard primitive, has no known practical weakness relevant to this construction, and has essentially the same browser implementation complexity as SHA-1 because both are exposed through the same Web Crypto digest interface. The public named-draw contract uses SHA-256.

That rationale should not be misread as assigning “256-bit security” to FWG. The searched default-token namespace is 2^130; one path exposes only 32 retained bits; the planner is many-to-one; and the application is unkeyed and unauthenticated. SHA-256’s generic collision, preimage, and second-preimage properties are properties of the full hash construction, not automatic end-to-end security strengths for this system.

The choice does not make FWG a general cryptographic-security system. In particular, an unkeyed SHA-256 digest is not a signature or authentication mechanism.

Reproducibility limits

⚠️ Repeatability requires the recorded application version/build, matching effective inputs, and a sufficiently compatible runtime. The publicly archived executable is the authority for that application version. Forward verification is intentionally easy: supply the disclosed seed and record to the identified build and compare the result. Current schema-13 result sidecars and Explorer recipes already include a passive runtime_environment block containing the page URL and browser/platform information that the loaded page can observe, including User-Agent Client Hints where the browser exposes them. These fields are reported diagnostic/reconstruction evidence, not authentication, and some values may be unavailable or browser-dependent. FWG remains self-contained and has no runtime library imports; future versions could extend the runtime record if new browser/runtime dependencies make additional evidence useful.

The browser cannot reliably report a definitive “ECMAScript edition implemented by this engine” as one runtime field. The application can declare the language edition it targets, while browser/engine versions provide diagnostic evidence about the implementation that executed it. Locale or language preferences such as en-NZ are not useful reconstruction fields unless a deterministic code path actually depends on locale-sensitive behaviour.

A runtime self-test digest could identify that two environments behave differently, but a digest alone would not tell a reconstructing examiner how to reproduce the old behaviour. If such a test is added, its model identifier, complete fixed inputs, algorithms exercised, expected bytes, and digest rule should be published together. Runtime metadata and explicit test inputs are diagnostic aids; the archived executable and comparison of the reconstructed output remain the substantive evidence.

A newer version may intentionally introduce a new random-engine or draw-model identity when a core compatibility-breaking mapping change is necessary. It may also change planner path use or DSP under a new application version while retaining the same core tuple-to-draw primitive. Reproducing an old output therefore means using the old recorded build, not assuming every future FWG version will render it identically.

Seed text is not Unicode-normalised. The exact stored string matters. Browser or implementation defects, edited files, changed planner rules, and missing render context can all prevent reproduction.

The current sidecar identifies the FWG version and render settings, but a stronger forensic record should also preserve relevant runtime identity, such as the browser/engine version and user-agent information available to the page. Those fields would not authenticate the record, but they could explain floating-point, Web Audio, or browser-version differences encountered when reconstructing an older output.

Scope note: Runtime/browser identity is a legitimate low-cost addition for future JSON. User-agent strings can be reduced, frozen, spoofed, or privacy-limited, so they are diagnostic context rather than remote attestation.

Technical references

• NIST FIPS 180-4 - Secure Hash Standard
• NIST - Hash Functions
• W3C Web Cryptography Level 2
• Bruce Schneier - SHA-1 Broken
• Bruce Schneier - Snake-Oil Warning Signs

See Proof of Zero Prior-Work Knowledge and Forensic Evidence.

Seed-size boundary

User-entered seed text is exact, case-sensitive, and Unicode-representation-sensitive. FWG trims leading/trailing whitespace and accepts at most 128 UTF-8 bytes. Generated 26-character Base32 seeds are well below this ceiling. The limit prevents repeated named-draw hashing of very large pasted text and keeps application-generated sidecars inside the supported import budget.

No random decision, no draw

Named draws are address-based, so FWG does not need placeholder random calls to keep later decisions aligned. If a choice has only one possible value, an integer range is fixed, a probability is exactly 0% or 100%, or a policy guarantees that a field will be neutral before rendering, current planning uses the fixed result without hashing that path.

For Base Generator Chance specifically, 0 fixes the category to Scanning and 100 fixes it to base; the family inside that category is still selected by its own named draw.

Phase-Coherent Mode and named draws

Phase-Coherent Mode is not a random sound-design draw. It consumes no named PRNG draw and is excluded from seeded random-preset selection. This makes controlled A/B testing possible: under the same compatible build, seed, rules, and fixed settings, On and Off select the same random patch; Phase-Coherent Mode then applies its deterministic completed-wavetable registration policy without consuming random draws.

The mode is nevertheless persisted/exported because it can change the rendered PCM. Exclusion from random selection must not be confused with exclusion from reconstruction metadata.