Распространенная проблема, когда программное обеспечение работает на машине разработчика, но дает сбой в другом месте, указывает на архитектурную проблему. Это происходит потому, что критически важные части поведения системы не зафиксированы в системе контроля версий, что делает рабочую станцию разработчика неявной, недокументированной зависимостью. Различия в версиях среды выполнения, архитектуре ЦП, файловой системе, локали, часовых поясах, нативных библиотеках, сертификатах, переменных среды, разрешении зависимостей или инструментах сборки могут привести к этим сбоям. Эти расхождения означают, что системе не хватает полного и воспроизводимого определения условий сборки и выполнения. Практики воспроизводимой сборки направлены на решение этой проблемы, обеспечивая, чтобы заявленные источники и входные данные приводили к проверяемым артефактам. В настоящее время репозитории часто содержат исходный код и конфигурацию, но исключают операционные предположения. Например, разные комплекты разработки Java (JDK) могут изменять поведение службы. Код, зависящий от часового пояса хоста, может давать разные результаты из-за различий в среде выполнения виртуальной машины Java. Аналогично, локаль по умолчанию, которая влияет на операции, чувствительные к локали, может наследоваться из среды, что приводит к несогласованным результатам.