0001 — FMU export metadata is not reproducible

ID	0001
Class	KNOWN-LIMITATION
Severity	1
Status	blocked
Models	—
Found	2026-09-20 audit of 581b8091
Decision needed	Should FhFmuExport gain --uuid and --generation-time options, or honour SOURCE_DATE_EPOCH, so that two exports of the same model produce byte-identical metadata?

Evidence

src/fmu/fhFMUexport/FmuUuid.cpp:10-20 seeds a Mersenne twister from std::random_device and returns a fresh random UUID on every call:

std::random_device entropySource;
...
uuids::uuid_random_generator uuidGenerator{generator};
return uuids::to_string(uuidGenerator());

src/fmu/fhFMUexport/FmuGenerationTimestamp.cpp:8-21 reads the wall clock:

const auto now = std::chrono::system_clock::now();

Both values reach modelDescription.xml — as guid in FMI 2.0 and instantiationToken in FMI 3.0, and as generationDateAndTime in both — and the token is repeated in resources/iomapping.xml.

Effect

Two exports of the same model from the same playpen differ. Three consequences:

• An FMU cannot be rebuilt and compared against a published one to confirm it came from the source it claims.
• A build that exports the same model on several platforms and merges the results — the only way to produce a multi-platform FMU, since the exporter emits binaries for its own platform only — cannot verify that the platforms agree by hashing. It must parse the XML and blank these fields before comparing.
• Caching and change detection in downstream pipelines see every export as new.

This is a limitation rather than a defect: the values are legal, and FMI requires only that the token in modelDescription.xml and resources/iomapping.xml match within one FMU, which they do.

Possible fix

1. Add --uuid <value> and --generation-time <iso8601> to ExportOptionsParser, used in place of the generated values when given. Explicit, testable, no effect on any existing invocation.
2. Honour SOURCE_DATE_EPOCH for the timestamp and derive the UUID from a hash of the model file and the bundled library set. Reproducible with no extra flags, but changes the default behaviour and makes the UUID a content hash rather than a random identifier, which some hosts may key on.

Option 1 is the smaller change and leaves the default untouched.

Test that would prove it

Export the same model twice and diff the two modelDescription.xml files: guid / instantiationToken and generationDateAndTime differ at HEAD. With option 1, export twice passing the same --uuid and --generation-time and assert the two archives' modelDescription.xml and resources/iomapping.xml are byte-identical.

Risk

Option 1 adds two options and no default behaviour change, so the risk is confined to the new code path. Option 2 changes what every existing export produces and would need the FMU test suite re-run. Neither is a prerequisite for any current work: a consumer that needs to compare exports can blank the three fields before diffing.