An insurer replaces the policy files that ground a claims agent and keeps no history of the prior file or of who replaced it. Model changes are already logged. What else should the architect require?
Select an answer to reveal the explanation.
Short Explanation
When a policy file is replaced and its old version disappears, you can’t tell what the agent used to read. You need an audit trail showing what changed and who changed it; model logs don’t record file replacements. A longer prompt or a satisfaction score won’t recover that history, and a new model deployment won’t preserve it either.
Full Explanation
Audit trails cover data changes as well as model changes. The claims agent is grounded on policy files, and replacing those files without keeping a history hides which wording the agent used previously. You should require an audit trail for grounding-file replacements that records what changed and who changed it; model logging is already in place but does not fill this gap. A longer prompt asking the agent to mention whichever file name it thinks it used records a guess in the answer, not the replacement or its history. A satisfaction score that falls when adjusters dislike an answer measures their reaction and says nothing about the prior file or who replaced it. A new model deployment on every policy edit treats a data change as a model change, while immediately deleting the previous policy file destroys the history you need. Exam caveat: the trail needs to retain the prior content or a reliable pointer to it; a name-only log cannot show what the old clause said. Operational check: replace a test policy file, then inspect the audit record to confirm it shows the editor, time, and enough old and new text to distinguish the clauses. In a test environment, restore the prior file from that record and confirm its text matches what the record retained.