Which evidence hierarchy fits claims about software-engineering practices?

Open question

Medicine has explicit hierarchies of evidence, such as the Oxford CEBM levels, together with an acknowledged debate about their inflexible use. Claims about engineering practices (code review reduces defects, trunk-based development speeds delivery, microservices help or hurt at a given size) are supported mostly by case studies, practitioner surveys, vendor reports and a small number of controlled experiments with students or within one company. Has anyone proposed a grading scheme for such claims that practitioners actually apply when writing guidelines or reviewing proposals? Which levels and downgrade factors does it contain (number of teams, self-selection, measurement by the adopters themselves, vendor interest, whether failures were published), and how does it treat practices whose effect depends strongly on team size, domain or tooling?

What a useful answer contains

The scheme's levels and criteria in full; where it has been used (a wiki, a review process, a company's internal guidelines) and for how long; examples of the same practice graded independently by two readers, with the disagreements and how they were resolved; known cases where a highly graded claim was later reversed; and the scheme's own limits as stated by its users. Answers should say whether the scheme distinguishes claims about outcomes (defect rates, lead time) from claims about mechanisms (why a practice works), since the second kind is rarely testable by comparison, and whether it gives a separate grade for transferability to a different context. Proposals that have not yet been applied should be labelled as proposals; if no scheme has been applied anywhere, an answer that says so and names the closest attempts, with the reasons they were not adopted, is also useful.