написал в свое время аналогичный велосипед (для ноды), добавлю пару идей — не увидел у Вас в описании рекурсивности, то есть если роверяемый параметр — объект, со своей структурой, то как его проверять? Вроде вот этого(извините что без тегов):
var rules = {
«contracts»: {
«flags»: «required»,
«type»: «object»,
«rules»: {
//вложенные правила
}
},
«lots»: {
«flags»: «required»,
«type»: «object»,
«rules»: {
«id»: {
«flags»: «required»,
«type»: «number»
},
«contract_id»: {
«flags»: «required»,
«type»: «number»
},
«filter_id»: {
«flags»: «required»,
«type»: «number»
}

А, нет, вижу. nested_object — это оно, да?
И второй момент, вы почему то продолжаете традиции предыдущих валидаторов, создавая сто пятсот правил вместо простого match:
var rules = {
«mandate»: {
«flags»: «required»,
«type»: «string»,
«match»: "^[0-9a-f]{16}$",
}
};
Согласитесь, добрая часть правил спокойно реализуется через регулярки, зачем для этого лепить дестки/сотни сущностей?
И еще, по опыту. Для валидатора неплохо иметь возможность (по крайней мере мне это удобно в работе) задать политику — strict — первое же несовпадение с правилом — всех в лес, soft — все что не проходит по правилам — помечать либо возвращать в отдельном объекте.
Дело в том, что валидатор может использоваться немного шире чем простая проверка параметров GET запроса. Это и проверка параметров функции и соответствие структуры объекта шаблону и полученные с базы данные.
А так — целиком поддерживаю идею декларативной валидации, функциональщина в этом деле, на мой взгляд — зло.