Thanks for flagging this.
The Helsinki values themselves are fine: SUEWS allows alb_min == alb_max for a constant albedo, and only objects when alb_min > alb_max. The sample config does this for evergreen trees (both 0.1).
The error comes from alb_id, the initial albedo. In the sample config each surface’s alb_id is set to its alb_min, 0.12 for deciduous and 0.18 for grass. When you change alb_min and alb_max, alb_id is left pointing at the old range, and that is a hard error at config load rather than a warning.
The fix is to set alb_id to null on those two surfaces:
initial_states:
dectr:
alb_id:
value: null
grass:
alb_id:
value: null
SUEWS then derives it from lai_id and the alb_min/alb_max pair, giving exactly 0.16 and 0.19, and the validation report lists it under NO ACTION NEEDED as auto-calculated. Setting it explicitly to 0.16 and 0.19 works too, since the check is inclusive. The field is documented on the vegetation initial state page.
One thing to avoid: do not delete the alb_id key altogether. The config itself is still valid, but the updated YAML that suews validate writes puts the key back at the wrong indentation, nested inside decidcap_id, and that file then fails to load. I have reproduced it and will get it fixed.
Worth noting separately that alb_min == alb_max switches off the seasonal albedo cycle for that surface, because the daily update scales the change by (alb_max - alb_min). If 0.16 is a growing-season value, you may prefer it as alb_max with a lower leaf-off alb_min.
Your wider point is tracked in #1007, and the auto-initialisation came out of that discussion (#1132). Useful evidence for that thread.
Did the 0.12 and 0.18 come from Database Prepare itself, or from the sample config you started from?