How a review is assessed

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.

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 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 says how sure we are 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 cannot measure.

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 did not 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 did not 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.

Where a check corresponds to a rule someone else published, the finding names that rule. Today we cite 28 rules from dbt_project_evaluator (dbt Labs) and OpenSSF Scorecard (Open Source Security Foundation).

Each citation states how close the match is: equivalent, narrower, broader or related. Where the match is not exact, we explain the difference.

A citation means our check corresponds to their rule. It does not mean the project is certified by, or compliant with, anyone.

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 do not move it.

Two reviews of the same project compare cleanly when they ran the same version. When they did not, we state which scores are affected.

We do not compare your project with other companies, and we do not publish a maturity rating.