Summary
When importing a model from a repository using IMPORT_MODEL, there is currently no way to save the result as a new version of an existing model object. Every import always creates a brand-new object, regardless of whether a prior version of the same model has already been imported.
A model stored in a repository evolves. When a user imports a later commit of the same model entry point, the natural intent is to create version 2 (or version N+1) of the existing model object, not a new unrelated object.
Proposed change
Add an optional priorModel: TagSelector field to ImportModelJob in job.proto. When set, the job should produce a new version of the identified model object rather than allocating a fresh object ID.
This requires changes in three places:
- job.proto — add optional TagSelector to ImportModelJob
- Orchestrator ImportModelJob.java — requiredMetadata() should include the priorModel selector when set; expectedOutputs() should return an empty map when set (no fresh ID needed)
- Runtime graph_builder.py — build_import_model_job() should, when priorModel is set, resolve the prior model's TagHeader from the job mapping and call new_object_version() on it rather than allocating a new ID
JobProcessorHelpers and the metadata service need no changes: the existing objectVersion > 1 → updateObject path already handles this correctly.
Note: If priorModel is not set, behaviour is identical to today — fully backwards compatible.
Summary
When importing a model from a repository using IMPORT_MODEL, there is currently no way to save the result as a new version of an existing model object. Every import always creates a brand-new object, regardless of whether a prior version of the same model has already been imported.
A model stored in a repository evolves. When a user imports a later commit of the same model entry point, the natural intent is to create version 2 (or version N+1) of the existing model object, not a new unrelated object.
Proposed change
Add an optional priorModel: TagSelector field to ImportModelJob in job.proto. When set, the job should produce a new version of the identified model object rather than allocating a fresh object ID.
This requires changes in three places:
JobProcessorHelpers and the metadata service need no changes: the existing objectVersion > 1 → updateObject path already handles this correctly.
Note: If priorModel is not set, behaviour is identical to today — fully backwards compatible.