It seems you would need a shared test execution and result repository system to have any shared tools or scripts for measurement. Test result schema is all too often specific to the toolset and sometimes the system under test.

That said, I am not so sure this is an arduous problem. Assuming your system stores test results in some kind of database, then establishing consistency is a matter of querying passing executions over all executions on a per test basis. If one wants to be even more precise, also keep track of the number of distinct failures per test (some tests may fail more than once but in different ways). My own definition is if a test either always fails (with the same failure) or always passes then it is consistent - otherwise it is inconsistent. This is usually a trivial query in any repository.

I do recommend changing the execution practices. It is insufficient to have a daily run of a test (I assume "daily" approximates "new build"). You ought to have multiple iterations per test per build, ideally hundreds, so that you can establish granularity to at least the .01 level. In my own experience, I find that product teams can chase a test's flake factor down to .001 or better when needed (or feasible, depending on the type of test), and to establish that you need many iterations. We started what we call a "reliability run" several years ago, and the information value of that investment has paid back many times over.