--- title: "How a Metacenta review is assessed" description: "The method behind every Metacenta review: what each dimension asks, how a score is worked out, what severity and confidence mean, and which published rules we cite." url: "https://metacenta.com/standard" updated: "2026-09-23" tokens: 1338 --- Check suite 1.30 # How a review is assessed Every Metacenta review runs the same versioned set of checks and states which version it ran. This page sets out that method, so you can judge the criteria as well as the findings. The current version is **1.30**. ## What the standard is A fixed set of checks, each one testing a single condition in the artefacts you send. Each check belongs to one dimension. It reads named files and repository metadata, never your warehouse data. Every finding names the check that raised it, the file or model it concerns, and what to change. If you disagree with a finding, you can see the rule behind it and argue with the rule. ## How a score is worked out A dimension scores from 0 to 100. Each check that feeds it gives a pass rate: items that passed, divided by items examined. The score is the average of those rates. Only checks that measure a pass rate per item feed a score. A check that reports one finding per group, or one for the whole project, appears as a finding and moves no number. A credential written into a DAG file is one example: it is reported as high severity, because partial credit is the wrong idea for a leaked secret. Beside every score, we state which checks it rests on, including when only one of four could answer. ## Severity Severity says how much a finding matters if it is left alone. - **Critical**: the project is broken now, such as a dependency cycle or a model that failed to build. - **High**: likely to produce wrong or missing numbers, or a gap in something other people rely on. - **Medium**: a weakness that makes errors more likely or slower to find. - **Low**: worth fixing when the area is next touched. - **Info**: a pattern worth knowing about, not a defect. The same check can raise different severities. A gap in a final model that others read ranks higher than the same gap in a staging model. Severity and the number of findings together set the priority. A critical finding goes to the top of the list. So do ten or more high findings of one kind. ## Confidence Confidence says how sure we're that a finding is real. - **High**: read from a structured field, such as a model with no `unique` test. - **Medium**: read from templated SQL, or from a convention the project appears to follow. - **Low**: a heuristic with known legitimate exceptions. An unreferenced model may simply be a final table. We use these three bands and no percentages. A figure like "97% confident" would claim a precision we can't measure. ## When a check cannot answer A check that found nothing and a check that could not look are different results. The report keeps them apart. - **Could not assess**: the artefact didn't carry what the check needs. The result is unknown, never clean. - **Not applicable**: the project has nothing of that kind, such as no incremental models. - **Not supplied**: you didn't send the artefact. If you chose not to share it, we record that as your choice, not a gap. A dimension with no check able to answer shows no score, not 100. ## Published rules we cite Where a check corresponds to a rule someone else published, the finding names that rule. Today we cite 28 rules from [dbt_project_evaluator](https://dbt-labs.github.io/dbt-project-evaluator/) (dbt Labs) and [OpenSSF Scorecard](https://scorecard.dev/) (Open Source Security Foundation). Each citation states how close the match is: **equivalent**, **narrower**, **broader** or **related**. Where the match isn't exact, we explain the difference. A citation means our check corresponds to their rule. It doesn't mean the project is certified by, or compliant with, anyone. ## Migration Assurance: when the data counts as the same Migration Assurance compares the data only when the client chooses to send reconciliation results. A difference of up to 0.010% counts as within threshold, and anything larger as different. A client may set their own threshold, and the report then says it's theirs. Equal counts never make two tables the same. Rows must also match by key. Where they can't be matched, for example between two different warehouses, the verdict is could not establish. ## Versions, and comparing two reviews The version changes when the criteria change: a check added or removed, a severity moved, or a new input to a score. Wording and layout changes don't move it. Two reviews of the same project compare cleanly when they ran the same version. When they didn't, we state which scores are affected. We don't compare your project with other companies, and we don't publish a maturity rating. ## Frequently asked questions ### Can we see the checks before we commission a review? Yes. Ask through the enquiry form and we will send the list for suite 1.30, with the published rule each one cites where there is one. ### What if a finding is wrong for our project? Tell us why. A person reviews every finding before the report goes out and cuts any that don't warrant your time. Scores still count every check, so a cut can't make a project look cleaner than it is. [Ask about a review](https://metacenta.com/enquire?src=standard&via=md) ## Related pages - [What the review covers and what it costs](https://metacenta.com/) - [What we do with what you send](https://metacenta.com/privacy) - [Terms of engagement](https://metacenta.com/terms)