Build log · CloudTune
What belongs in an execution receipt?
A completed job is only useful if someone else can understand what ran, which result belongs to it, and where the record stops being evidence.
CloudTune is an early ML infrastructure project for supervised fine-tuning on customer-operated infrastructure. I’m building the control plane, runner coordination, and evidence export around that workflow. A public research preview is now available at cloudtune.org; the application remains private.
Start at the execution boundary
A worker claims a job, reports progress, and eventually sends a result. The difficult cases arrive between those steps: a process disappears, a lease expires, another worker takes ownership, or a late result arrives from the previous attempt.
My engineering work focuses on contracts and ownership, lease recovery, generation fencing, and duplicate-result handling. The goal is a result whose relationship to the intended attempt can be inspected.
Keep the receipt portable
An exported record should carry enough context to identify its artifacts and check its signature without the control plane running. That makes review possible outside the original application. It also makes schema agreement between the server and offline verifier important: the two paths need to interpret the same input consistently.
Be precise about what was proved
A signature can establish that a key signed particular content and that the content has not changed. It does not by itself prove that training happened correctly or that the resulting model is useful. Execution evidence, model evaluation, and production qualification are separate questions.