Supply a model or a build workspace

Before you start

You need a model or workspace that can name one exact version of itself, and the descriptor for the workflow you intend to run.

Read the descriptor first. It lists the formats that workflow accepts and the runtime it will load them into. Converting a model before you have read that is how a conversion gets done twice.

Bind the exact version

Model registries, artifact stores and source repositories all offer a version identifier. Use it, and pin the bytes beside it:

"input": {
  "snapshot": {
    "version_id": "<registry version, tag digest or commit>",
    "content_sha256": "<the digest of those exact bytes>"
  }
}

A branch name, a latest tag or a mutable folder is not a version. If your store cannot name one, package the exact files yourself and pin that package: how snapshots are pinned.

Read the formats and the runtime requirements

Two things have to line up before a model run is worth quoting. The format has to be one the workflow accepts. The declared runtime also has to be able to load your particular build of that format.

So check the version of the framework or conversion tool you exported with, not just the file extension. A format name is a family, and a file from an unsupported version of the same family is still refused.

Where a workflow reads a model registry or an experiment store directly, register it as a source and reference it by credential_ref. The request carries the reference; it never carries the secret.

Strip secrets before you snapshot a workspace

A source workspace is the easiest input to leak from, because build tooling leaves credentials in it as a matter of course. Sweep it before you take the digest.

Look for signing material, environment files, a token in a build configuration, a cached network credential, and anything a test fixture holds for convenience. A credential in an input falls under rejected_credential and is refused rather than stored, but the safer position is that it never left your machine.

Executable assets stay in the lane the workflow admits

Build and test workflows do run your code, and they run it inside a bounded, isolated workspace under one approved job. Nothing arbitrary is admitted.

The workflow declares what it will execute. A script your spec did not declare does not run. An extra step left in the workspace is not picked up because it happens to be there.

Pin your dependencies into the snapshot too. A dependency resolved while the job runs is not part of what you pinned. Its digest is therefore absent from your provenance record, and a later run is not comparable to this one.

What success looks like

Your quote echoes the version you pinned, together with the maximum charge and the deadline you set. Read it, then approve separately.

After the run, provenance.json binds the input, workflow, model, schema and envelope digests together, and result-manifest.json is written last as the only complete-bundle marker. Matching model digests on both sides is what makes two runs comparable.

If the version or the format is refused

If the version moved between quoting and admission, admission answers REPLAN_REQUIRED. Re-pin at the current version, quote again, and approve again.

If the format or runtime is refused, the reason names which of the two failed. Re-export from a supported version rather than renaming the file, and check the declared runtime again before you retry. Worked examples live under the Core ML Lab walkthrough.