Fire/EMS trains a response-time predictor on operational datasets. Which data management practice best supports high-stakes civic AI?
Select an answer to reveal the explanation.
Short Explanation
When response-time models guide staffing talk, you need to know where the data came from. Keep versioned backups so nobody can shrug and say the data just appeared, but that's not enough.
Full Explanation
Fire/EMS response-time predictors influence staffing and resource conversations where integrity of training data matters. Retaining chain-of-custody for datasets used to train the predictor establishes who supplied data, what transformations occurred, and whether sources remain authorized—supporting auditability and integrity under high-stakes civic use. Maintaining versioned backups of training datasets for operational recovery doesn't track who supplied data or what transformations occurred, so it can silently bias response-time estimates with unauditable sources. Encrypting training datasets at rest with precinct-managed encryption keys protects confidentiality but hides who accessed or modified data, erasing accountability and making root-cause analysis of model regressions nearly impossible. Documenting feature engineering steps for response-time model reproducibility reviews captures model logic but treats data provenance as disposable once accuracy looks good, which fails when regulators, chiefs, or auditors later ask how the training data was sourced. Exam caveat: consequential public-safety AI requires durable dataset lineage and custody records as a data-management control, not merely a model-file checksum. Operational check: register Fire/EMS training datasets with source owner, hash, collection window, and handlers; block training jobs that lack custody metadata; and retain lineage alongside model cards for the response-time predictor.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.