Configuration Model and Lifecycle

Start with one editable GenerationConfig YAML document, validate it, then submit it to the executor selected by that configuration. Keep the resolved YAML with its output: it describes the requested dataset, while the generated store retains record and generator provenance.

From template to validated job

  1. Copy a maintained template and edit its YAML; Local execution owns the runnable local sequence.

  2. Validate it. Hydra composes YAML, interpolations, and command-line overrides; Pydantic validates the resolved mapping against RFGen’s schema. A failed configuration does not start generation or write records.

  3. Generate only after validation succeeds.

The CLI reference is authoritative for command options. The configuration API defines Hydra resolution and Pydantic model behavior, while the configuration schema defines YAML fields and validation rules.

Execution is selected by the job

The shipped local executor runs synchronously. A remote executor is a submission boundary: generate submits canonical shard specifications and returns after printing provider status and cancellation commands. Local execution and Remote Spark execution explain the modes; the generation API defines their shared contracts.

Declare what the run observes

A run declares what it observes through one nonempty ordered projections list, and supplies one plan template beside it. Both are mandatory: a configuration missing either is refused before anything is composed, by rfgen validate and rfgen generate alike. There is no second architecture to fall back to — the source/composer path this section once offered as the alternative is retired.

Each sample mints one ScenePlan, runs every projection against its shared SceneClock, and writes exactly one aggregate Signal Dataset record. A multi-receiver scene keeps every receiver inside that record as a named subtree rather than fanning the sample out. See Generate one unified observation dataset.

Provenance follows generated data

Generation derives a canonical specification for each shard. Its content-addressed shard ID uses the validated configuration hash and shard index. Stored records include scene and generator provenance. Use Inspect and audit a dataset to examine a store and Storage for the storage model.