Configuration

Maturity: verified

RFFM separates authoring fragments, the resolved application recipe, code-owned component dispatch, and provider launch policy. Those four values answer different questions and are stored separately.

Composition and validation

configs/config.yaml is the Hydra root. The caller explicitly selects one file from configs/experiment/. That preset chooses dataset, input pipeline, normalization, patching, model, objective, optimizer, training, and checkpoint groups. Hydra resolves defaults and interpolations; Pydantic then validates the complete mapping with unknown fields forbidden.

This process finishes before data, models, artifacts, or cloud resources are created.

Component selection

Model, objective, and optimizer groups each contain:

implementation: readable_registry_key
parameters: {}

The application catalog maps the key to a concrete parameter validator and builder. The shipped keys are:

  • model: tiny_causal_iq;

  • objective: next_patch_prediction;

  • optimizer: adamw.

Each registration rejects parameters it does not own. These are code-owned definition IDs, not user-maintained compatibility versions.

Identities

The application computes two SHA-256 identities:

  • resolved-config hash: every field in the complete application recipe;

  • training-contract hash: the subset that must match across bounded resume, excluding output location, maximum step, and checkpoint location.

Logical run identity is validated separately. A content hash does not replace a run ID, attempt ID, component definition ID, dataset snapshot ID, or checkpoint content hash.

Provider configuration

Files under configs/launch/ are not Hydra groups and are never merged into the application recipe. The selected file supplies the Google Cloud project, region, service account, machine, accelerator, and replica count to the submission adapter. The committed L4 and A100 configurations preserve the same application recipe while selecting different worker hardware.

See Also