{"version":"2.1.265","anchor":"model-catalog-resolution-now-takes-an-explicit-provenance-ar","canonical_anchor":"model-catalog-resolution-now-takes-an-explicit-provenance-ar","heading":"Model catalog resolution now takes an explicit provenance argument","tier":"internal","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265\/e\/model-catalog-resolution-now-takes-an-explicit-provenance-ar","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265","markdown":"### Model catalog resolution now takes an explicit provenance argument\n\nModel catalog resolution now passes a provenance value when rebuilding the catalog\n\n**Unclear.** What the provenance value is used for, or what changes for the user, is not shown by the evidence.\n\n**What**\n\nThe internal function that reconciles the model picker's catalog state now calls the catalog builder with an object that includes a `provenance` field (tracking where the catalog data came from), instead of just passing the raw catalog value as before.\n\n**Why**\n\nThis is an internal refactor to the model catalog machinery. The evidence doesn't show what using provenance changes for a user of the model picker.\n\n- Area: Elsewhere\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}