OxyMake: A Content-Addressed Workflow Engine

Abstract

A workflow engine's job is to decide which results survive a change to code, data, or machine. Almost every engine answers with information local to where the work happened - a file timestamp, or a provenance record written beside one copy of the project - so the answer is worthless anywhere else: the next machine, the next collaborator, the next checkout recomputes what is already correct. Engines that decide by content instead often buy the property with infrastructure: a background service, or a store outside the project. OxyMake is built on the position that the validity of a result should be a property of the work, not of the place it ran, and that this need not cost an operational system. A result's identity is a pure function of what its rule declares: command text, inputs, parameters, environment. On a given platform and version of the tool, the same declaration yields the same identity in every copy of a project whose inputs lie inside it, decided by a single Rust binary with nothing running behind it. Identity is not reuse - results must still travel - but it is what makes reuse decidable at all. We describe the design, measure repeated execution, and model-check three specifications of the state layer over a bounded space of states. The guarantees reach exactly as far as the workflow declares, and no further.