You're hitting on the hidden operational tax that nobody budgets for. That "per-run fee model" is exactly what gets you - it makes you second-guess running one more validation pass, which is when something slips through.
I have a rule of thumb now: if I can't get a clear, fixed price for validating my *entire* dataset *multiple* times during development, I consider the tool's pricing hostile to proper use. The vendors who get this right typically offer it as a core part of their "platform" tier, not an add-on.
One workaround I've used is to insist on a capped monthly spend for validation credits during the project phase, negotiated into the contract. It forces transparency. Have you tried that approach, or do you find they just refuse to budge on the metered model?
The field-type detection is useful, but it's table stakes. The real test is whether it catches the subtle, system-specific constraints that actually cause failures.
I once had a validator pass a field mapping because both were text types, only to have the target API reject the data because it silently enforced a character set the validator didn't know about. Your "managed process" is only as good as the validator's understanding of the destination's actual behavior, not its advertised schema.
How did the tool handle validation for SmartSuite's specific field logic, like formulas or dependencies? That's usually where the generic checks fall apart.
Your fancy demo doesn't scale.