OK, using your April 31 for an example:
Field check: Field is “day of month”. Allowed inputs are whole numbers, 1-2 digits. Therefore, when inputting the day in the month of April, you could input 1, 31, or 66. Are these all valid and all reasonable? No. But they're all allowed in the field check. Field check is just in the computer's mind what type of input is allowed. Computer input types are things like numbers (with or without decimals would be different types); text; or a true/false. So, field check wouldn't be as specific as “Of it's April only 1-30; if it's May then 1-31; if it's February in a leap year then 1-29 otherwise 1-28”, just “number with decimals, number without decimals, text, or true/false” and “length of value” (text 256 characters, or text 3 characters, or text 1000 characters, etc.). This is done by programming a field to only accept a certain input. Have you ever entered your social security number in a field as 123-45-6789 and had the 89 cut off cause it was limited to 9 characters, and had to re-eneter as 123456789? This is a field check. The field is limited to 9 characters. Or entered it as 123-45-6789 and then had the form give an error that only numerical values are allowed in this field? That's also a field check; only numbers are allowed, so “-” is rejected. For example, this prevents someone from accidentally entering their credit card number in the zip code field when making a payment.
Data Validity: This is just “does it follow a standard format”. For April 30, submitting a date of 4/30/95 would work – standard date formats include #/##/##, ##/##/##. ##/##/####, etc. Data validity test is checking to make sure that the input follows an expected format for the field that was entered. Unlike a field check, I don't think this one usually stops the data from being entered, but is used for verification later. So, if you've got a data export in Excel with 10,000 rows of information, and one of the birthdate columns instead of saying 4/30/95 for the college student instead says 123 Column Drive, you know that the record has the columns messed up and got their street address in the birthdate column. This happens a lot with exported data, honestly – one column will be blank for a record, and for some reason the export will move all the rest of the data over a column, so you end up with an address in a date. A data validity test would catch this and alert the data user so that the record could be corrected.
Data Reasonableness: So far, none of these have really checked to make sure that the amount was reasonaable. All of these would have allowed 19/60/1012 as the birthdate of the college kid in the records. So, reasonableness goes a step beyond the others – instead of just saying it has to be a number, it says the month must be a number between 1 and 12, the day has to be a number between 1 and 31 (or gets more specific and sets a limit for each month, and the year has to be a number between certain limits (the specifics vary depending on what you're looking at – for college kids, that means people who are currently alive, so I'd say 1900 through present). This detects typo's – maybe 19/60/1012 was really Oct 12, 1960, but someone typed it in a different order.
Closed-loop verfication: Not sure, and the results I found on Google were related to authentication (like logging in with a PIN and a password, not just a password), so I don't think that's what you were looking for…so someone else will have to explain that one. 😀
.