A bank team wants a new neural network for card-fraud alerts. Published studies already report how logistic regression and gradient-boosted trees score on the same public fraud tables with the same alert metric, and the team has not read those results. What should the team do before designing a new architecture?
Select an answer to reveal the explanation.
Short Explanation
Check the scoreboard before you design a new play. Those published fraud results already tell you what a plain model can do on the same tables and the same alert metric. Starting a custom network first is how you spend a month rediscovering a number you could have read.
Full Explanation
Published baselines show what simpler models already achieve on the shared tables and the shared alert metric. Reading those scores gives the new design a comparison point before any architecture work begins, and it can show that a logistic model or a boosted tree is already strong enough to change the plan. Designing the network first and opening the studies only after a demo misses that comparison during the design itself. Treating novelty as a reason to skip the studies assumes a custom network will win without evidence from the reported scores. Replacing the alert metric with training loss does not remove the need for a baseline; it throws away the metric the studies and the alerts share. Writing those published scores down before design also stops the team from changing the metric after the network exists. Exam caveat: a published score is a comparison, not a promise that the bank's own transactions will match the public table. Operational check: put the cited logistic and boosted-tree scores next to the proposed architecture in the design note before any new training job is queued.