Contract language for a 311 bot requires exit and data-portability clauses if the vendor fails or is acquired. What lock-in management practice is this?
Select an answer to reveal the explanation.
Short Explanation
Vendors fail; cities still need 311 next Monday. Bake exit and portability into the contract so the bot’s brains can move—don’t trap the knowledge in a locked toy box.
Full Explanation
Requiring exit and portability clauses so civic AI platforms can be moved if the vendor fails is the correct lock-in management practice for 311 bot contract language. Vendors get acquired, change products, or fail; cities still need continuity of resident services and ownership of knowledge bases, configurations, and logs. Exit and data-portability clauses establish how content and settings can be exported in usable formats and on what timeline, reducing hostage scenarios when the commercial relationship ends. The practice works because municipal continuity planning must include AI platform exit, not assume perpetual vendor goodwill.
Accepting proprietary formats with no export path to save a few dollars fails by concept: short-term savings create long-term lock-in that can halt 311 knowledge reuse. Assuming the vendor will kindly migrate data for free if they shut down fails by concept—uncontracted kindness is not an exit plan, especially during vendor distress. Building the entire 311 knowledge base only inside an unexportable vendor UI fails by concept: sole custody inside a closed UI maximizes lock-in and recovery failure if the vendor disappears.
Exam caveat: portability clauses should specify formats, frequency, and assistance—not vague “cooperation” language alone. Keep 311 / municipal service continuity framing. Operational check: require contractual exit and export rights for knowledge, configs, and relevant logs; periodically test an export; keep canonical content in city-controlled repositories where practical; and verify a successor platform could be stood up without starting from zero.