Validation
What a bounded test has to prove before a platform bet
Status disclosure
Planned study
Public research brief. No findings are published as completed fieldwork. The study plan may still change. Fieldwork has not begun.
Can the technical path be invalidated against real cases, exceptions, and recovery before the platform bet?
The expensive mistake is selecting a platform before the workflow, the failure modes, and the recovery path have been tested against real cases. This brief frames technical validation as a bounded experiment with an invalidation rule, not as a proof that the software can run a happy path.
Evaluation is a demo on clean data, then a purchase, then an integration surprise.
Exception handling, audit, and human review are deferred until after the system is live.
Reliability is judged by the lab path rather than by the operating cases that actually fail.
How we would work it
Define representative cases, failure modes, and review paths before a vendor bake-off.
Test integration, permissions, and recovery against the workflow that would actually run.
Keep the validation small enough that a failed test can stop the spend.
What has to be true
- Would a silent failure surface to the person who can act on it?
- Does the test include the messy cases, or only the ones that make the software look ready?
- What result would be enough to reject the platform without restarting the selection process?