A 311 program manager wants one design that can later swap foundation models without rewriting every department UI. What architectural requirement should the design emphasize?
Select an answer to reveal the explanation.
Short Explanation
311 shouldn't rebuild every department screen just because the city switches models. Put a thin abstraction in the middle—like a power strip—so the UIs stay plugged in while you swap which FM is on the other end.
Full Explanation
A 311 program manager who wants one design that can later swap foundation models without rewriting every department UI should emphasize model-provider flexibility through an abstraction layer. Department UIs and APIs call a stable municipal GenAI service interface; behind that interface, adapters invoke Bedrock model IDs or alternate providers. When procurement or performance drives a model change, only the provider adapter and configuration change—screens for public works, parks, and clerk intake stay stable. That is the architectural requirement for long-lived civic front ends sitting on a fast-moving FM market.
Hard-coding each department UI to a single vendor SDK and model ID couples presentation to a perishable backend choice and turns every model swap into a multi-app release. Duplicating the full chatbot UI once per foundation model vendor multiplies accessibility, branding, and security work without improving swap agility. Storing foundation-model system prompts only inside each mobile app binary makes prompt governance and model changes a client-release problem instead of a controlled server-side concern.
Exam caveat: abstraction and provider flexibility appear when stems ask about swapping FMs without rewriting applications—think interface stability, not “pick one SDK forever.”
Operational check: define a city GenAI API contract (messages, metadata, errors), implement one Bedrock-backed adapter behind it, prove a second model ID can be routed via config, and confirm no department UI embeds vendor-specific model IDs.