Confirmation
One row per (experiment, problem) confirmation stage: how many candidates were ranked, how many of them were confidently response-feasible at the confirmation's CI level, and whether the selection was therefore degenerate.
Separate from tblConfirmation rather than extra columns on it, for two reasons. The candidate table is one row per finalist, so these problem-level values would repeat on every row; and it gets no rows at all when confirmation is skipped for a single distinct finalist — which is exactly a case where knowing the selection could not discriminate still matters. A summary row is written whenever a confirmation stage ran.
A degenerate selection is one in which no candidate could be declared confidently feasible, so the comparator fell through to ranking by constraint violation alone and the objective played no part in choosing the winner. Always false for a problem with no response constraints.
numConfidentlyFeasibleAfterScreening is null when no screening stage ran. When screening did run, it is the count at the screening precision, so a degenerate row followed by a positive count here records a selection that screening rescued — and a zero records a screening stage whose replication count was too small for the constraint, which looks identical in every other respect.