Parent and data
Identify the exact parent, tokenizer, datasets, and source hashes used by the run.
A useful run preserves its parent, data pins, controls, checkpoints, evaluations, and stopping reason. This page explains how to read that evidence without mistaking an active process or a lower loss for a finished model.
A result is interpretable only when the checkpoint and evaluator belong to the same declared experiment. The reading order below keeps a plausible number from becoming a claim it cannot support.
Identify the exact parent, tokenizer, datasets, and source hashes used by the run.
Compare against a baseline and size-matched control across more than one seed.
Check protected examples and domain scores beside the optimization target.
Inspect generated behavior; a good aggregate can still hide repetition or zeros.
Verify that model, optimizer, sampler, and evaluator state can resume exactly.
State what passed, what remains underpowered, and what the run did not test.
These are publication and evidence routes. They do not expose the local controller, private storage, credentials, or a live command surface through the public website.
Artifacts released through the AetherMoore Hugging Face account.
Hugging FaceLocal hardware and cloud providers can change. The durable part is the contract that limits time, cost, storage, data movement, checkpoints, and promotion.
Name wall time, phase limits, paid-compute ceiling, and stop conditions.
Pin inputs and reserve room for every checkpoint that must survive.
Run one owned worker with bounded authority and resumable state.
Measure against the frozen panel before choosing or extending a checkpoint.
Preserve cost, state, outcome, failures, and the next safe resume point.
The website intentionally does not promise a live backend or expose local health URLs. Current run state belongs in authenticated operator receipts. Public visitors get the stable protocol, released artifacts, and evidence that is safe to publish.