New Workflow Engine Uses Content Addressing to Make Build Results Portable Across Machines

Workflow engines face a persistent problem: after code or data changes, they must decide whether existing cached results remain valid. Most systems answer by checking timestamps or metadata stored locally on one machine—which means every collaborator and every fresh checkout has to recompute the same correct work.

The Portability Problem#

Traditional build systems tie result validity to location. A file timestamp, or a provenance record written beside one copy of a project, means that determination is worthless if you move to a different machine or share the work with a colleague. They see no evidence that the result is already correct and rebuild it from scratch. More sophisticated content-addressed engines (like Nix) solve this by requiring a background service or an external data store—operational overhead that many teams avoid.

OxyMake's Approach#

Researchers at arXiv present OxyMake, a workflow engine that decouples result validity from execution context. Rather than storing proof of correctness in one place, OxyMake derives a result's identity as a pure function of what its rule declares: the command text, all inputs, parameters, and environment variables. On a given platform and toolchain version, the same declaration always produces the same identity, no matter which copy of the project hosts the computation or which developer runs it.

The key innovation is simplicity: OxyMake achieves this without background services or external stores. A single Rust binary makes the determination locally, ensuring that two developers or two machines with identical inputs and declarations will recognize the same result as valid.

What This Enables#

Achieving portable identity is not the same as automatic result reuse—cached results still need to travel between locations. But identity is the prerequisite for reuse to be decidable at all. Once OxyMake can reliably identify a result, teams can safely share or cache it across boundaries.

The authors describe the engine's design, measure performance over repeated executions, and formally verify three state-layer specifications through model-checking within a bounded state space. They emphasize that guarantees extend only as far as the workflow declarations explicitly cover—no further.