{"version":"2.1.271","anchor":"publish-source-pin-verification-gains-an-explicit-revalidati","canonical_anchor":"publish-source-pin-verification-gains-an-explicit-revalidati","heading":"Publish source-pin verification gains an explicit revalidation path with tracked provenance 'lane'","tier":"internal","area":"Publishing","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271\/e\/publish-source-pin-verification-gains-an-explicit-revalidati","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271","markdown":"### Publish source-pin verification gains an explicit revalidation path with tracked provenance 'lane'\n\nPublishing now tracks how a file's source bytes were captured and can re-verify them before trusting a cached copy\n\n**What**\n\nWhen publishing content, Claude Code now records a \"lane\" describing how the source bytes were originally captured \u2014 one of \"admitted\", \"confined\", \"plain\", or \"pinned\" \u2014 alongside the existing hash and size checks. It also adds a dedicated step that re-checks, using the method appropriate to that lane, that the source hasn't changed before trusting a cached read of it.\n\n**Why**\n\nThis makes publishing more resistant to publishing stale or tampered content, by re-verifying the source through the right method for how it was originally obtained rather than assuming a cached copy is still valid.\n\n- Area: Publishing\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}