# Version the prompt and tools with the model

A model identifier alone cannot reproduce an application response. Capture the configuration that shapes its inputs, available actions and accepted outputs.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Create a release manifest

Define a configuration record containing the model reference, prompt artifact, tool schema versions, retrieval settings and validator version. Include the evaluation dataset and source snapshot used to assess it.

Use immutable artifact identifiers where the platform supports them. Avoid a manifest that points every field at a mutable "latest" value. It may be convenient during development, but it cannot explain a historical result reliably.

Keep secrets out of the manifest. Reference the required deployment or credential configuration through the application's normal secret-management path.

```json
{
  "release": "extractor-2026-09-candidate-2",
  "modelRef": "configured-provider-version",
  "promptVersion": "invoice-fields-v6",
  "toolSchemaVersion": "document-read-v2",
  "validatorVersion": "invoice-contract-v4",
  "evaluationSet": "invoice-reviewed-v8"
}
```

## Resolve one configuration per task

When a request starts, record the selected release with its run identifier. Use that configuration consistently through the task unless the workflow explicitly supports a version transition.

For long-running agents, save the workflow and operation versions too. A model configuration explains generation, while execution state explains completed effects. Both are needed if the task pauses across a deployment.

Return the release identifier in internal traces and support records, not as clutter in the user interface. Operators need to correlate a regression with the configuration that produced it.

## Validate compatibility before routing traffic

Run schema and semantic checks against the candidate. Confirm tool arguments still satisfy the business contract and that output parsing does not depend on incidental formatting from the old model.

Test malformed and incomplete results through the fallback path. A candidate that produces valid output most of the time can still expose a broken retry or unvalidated plain-text fallback.

Compare the entire configuration against the baseline. If prompts and retrieval settings also change, record those differences so a reviewer does not attribute every outcome to the model alone.

## Keep the prior configuration executable

Test restoration using the old manifest against the current application. Confirm required endpoints, prompt artifacts and tool schemas remain available for the observation window.

If compatibility cannot be maintained, define a narrower fallback such as pausing the affected capability or routing to a manual process. Document the limitation before release. A manifest is useful when it can both reproduce the candidate's conditions and support a real recovery decision.

## Sources

- [Microsoft Learn: evaluation and observability](https://learn.microsoft.com/en-us/azure/foundry/concepts/observability)