Section 49: Determinism and Reproducible Execution¶

TECHSPEC-49 — Section 49 · Version 0.1 · Status: Initial Draft

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Purpose¶

Deterministic behavior makes failures easier to reproduce, compare, test, and audit.

The language should provide predictable semantics while acknowledging that external systems, concurrency, hardware, and time can introduce nondeterminism.

2. Deterministic Core¶

For the same source program, inputs, language/compiler semantics, and declared configuration, deterministic operations should produce the same results.

The specification must define: - Numeric behavior. - Evaluation order. - Collection iteration order. - Serialization ordering where deterministic output is requested. - Error selection where multiple failures are possible. - Compile-time evaluation behavior.

3. Sources of Nondeterminism¶

Potential sources include: - Randomness. - Wall-clock time. - Concurrent scheduling. - Network responses. - Filesystem and database state. - Operating-system behavior. - Hardware and runtime differences. - External services.

These sources must be explicit where practical.

4. Randomness¶

Random operations must use a declared random source.

For reproducible testing, a seed may be recorded. A seed does not guarantee identical output across different algorithms or versions, so the generator identity and version must also be recorded.

Security-sensitive randomness must use an approved cryptographic source and must not be replaced with a predictable test generator in production without explicit authorization.

5. Concurrency¶

The language must not promise deterministic scheduling for concurrent programs unless a specific execution model provides that guarantee.

It should make data races and unsynchronized shared mutation detectable or preventable through the concurrency and ownership model.

6. Reproducibility Records¶

A reproducibility record should include: - Source and dependency hashes. - Compiler, language, and runtime versions. - Target platform and relevant configuration. - Input data or protected references to it. - Random generator and seed where applicable. - External service versions or response captures where available. - Test and execution results. - Known nondeterministic factors.

Secrets must not be copied into records.

7. Deterministic Build¶

A reproducible build should produce identical artifacts from identical declared inputs under the defined build environment.

If the build is not reproducible, the report must identify known causes or state that the cause is unknown.

8. Verification¶

Determinism claims must identify their scope. Deterministic evaluation of a function does not make the entire application deterministic if it depends on external state.

9. Design Goal¶

The language should make repeatable behavior the default where possible and make unavoidable nondeterminism visible, bounded, and recorded.

Source file: TECHSPEC-49.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.