A housing authority is hardening lifecycle governance for production AI. Which documentation set is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
If you can’t find the model card, data sheet, and change log, you don’t really know what’s running against housing cases. Those artifacts are the memory of the system.
Full Explanation
Production AI in a housing authority needs lifecycle documentation that survives staff turnover and vendor changes: model cards that describe intended use and limitations, data sheets that describe training/operational data characteristics and rights, and change logs that record versions, approvals, and material modifications. Together these artifacts support oversight of eligibility, waitlist, or maintenance prediction systems; enable audit reconstruction; and make safe change management possible when models or data pipelines shift.
Relying on a hallway rumor that “someone trained something once” fails provenance—rumors are not reviewable artifacts. Marketing slogans with no technical or data provenance fail by concept: slogans do not document data sources, performance bounds, or update history. A single screenshot with no version or change history fails durability and traceability; screenshots freeze a moment without controlled versioning.
Exam caveat: documentation depth should scale with risk tier, but production systems that affect housing decisions generally warrant model cards, data sheets, and change logs as a baseline set—not optional niceties. Operational check: for each production AI system, verify the three artifact types exist, are linked from the inventory, and are updated on the same cadence as model or data changes, with ownership assigned in the RACI.