Transit security wants customized rider-alert models reproducible for incident review. Which practice best supports that goal?
Select an answer to reveal the explanation.
Short Explanation
If a weird rider alert goes sideways, you need the recipe card—not just a screenshot of the meal. Log seeds, hyperparameters, and data versions so the customized model can be rebuilt for the review.
Full Explanation
Transit security wanting customized rider-alert models reproducible for incident review needs training provenance: hyperparameters, seeds, data versions, and training configuration must be logged so investigators can rebuild or explain the customized model that produced a disputed alert. Reproducibility is an operational and accountability control for civic GenAI, not a research luxury.
Deleting training logs after each successful run to reduce storage fees destroys investigative evidence. Retraining nightly with random settings and no recorded configuration maximizes irreproducibility. Storing only final chatbot screenshots proves UI appearance, not model lineage or training conditions, and cannot support rigorous incident review.
Exam caveat: Screenshots and chat transcripts are outputs; reproducibility requires training configuration and data lineage. Cost-saving log deletion is a common wrong answer when stems ask about investigation readiness.
Operational check: Emit training job manifests to immutable or WORM storage with model hash, dataset version IDs, seed, hyperparameter block, code commit, and promoter identity. Periodically restore a prior rider-alert checkpoint from those records in a lab environment to prove rebuild capability before an incident forces the issue.