A municipal AI platform team needs versioned deployment and rollback for a customized permitting foundation-model adapter. Which practice best supports that need?
Select an answer to reveal the explanation.
Short Explanation
When a permitting adapter goes sideways, you want a labeled shelf of prior versions—not a mystery file on someone's laptop. A model registry with versioning and rollback is that shelf for customized FM deployments.
Full Explanation
A municipal AI platform team that needs versioned deployment and rollback for a customized permitting foundation-model adapter should use a model registry with versioning and tested rollback. The registry records which adapter (or model package) is approved, what data/prompt assumptions it was evaluated against, and which version is live in permitting. Rollback is a controlled promotion of a prior registry version—not archaeology on someone’s laptop—so a bad adapter does not strand the city on an unrecoverable overwrite.
Overwriting the only production adapter in place with no version history removes the ability to revert after a permitting regression. Storing adapters only on an engineer’s laptop with no registry entry breaks continuity, auditability, and multi-admin operations. Relying on chat memory of which file was probably last uploaded is not a deployment practice and fails change-management scrutiny.
Exam caveat: customized FM lifecycle management on AWS-style platforms centers on registry, versioning, approval, and rollback—the same discipline as other production artifacts.
Operational check: publish adapter versions to the registry, require promotion approvals, rehearse rollback in staging by reverting the live pointer, and confirm permitting traffic serves the intended version ID after each change.