Skilirium

Recognises nulls left to chance in a check predicate

K-714 · Skill knobit · Activity: Derive data quality rules · Competence: Data modelling

A predicate that evaluates to UNKNOWN for nulls, where nobody decided whether a null passes. A CHECK passes UNKNOWN; a DQ row predicate fails it; a violation query written as WHERE NOT (expr) silently drops it. And NOT IN against a subquery that returns a null matches nothing.

Can AI do this?

AI does this partly Some of the tested AI models master this; others do not show it. 6 of 10 models master it.

ModelTierProbability of masteryStatus
gemini-4-argonFlagship 83%Not shown
gemini-3.1-pro-previewFlagship 100%Mastered
gpt-6-astraFlagship 100%Mastered
claude-fable-5-1Flagship 100%Mastered
gemini-3.8-flashMid tier 100%Mastered
gpt-6.1-solMid tier 99%Mastered
claude-sonnet-5-5Mid tier 100%Mastered
gemini-3.5-flash-liteLow cost 43%Not shown
gpt-6-lunaLow cost 77%Not shown
claude-haiku-5-5Low cost 82%Not shown

Mastered means a probability of at least 90% that the model has this knobit, estimated from its graded answers. “Not shown” means the answers do not settle it either way. How the models are tested.

What it looks like in practice

Expected result: The predicate and the explicit null decision

How it is assessed: Flags the deficient case and passes the acceptable one. Deficient: Copied from the CHECK: interest_rate_type_code IN ('FIX','VAR') on an optional column — every current account with no rate type fails. Or WHERE account_currency_code NOT IN (SELECT currency_code FROM ref_currency) with one null code in the reference table: no violation ever found Acceptable: interest_rate_type_code IS NULL OR interest_rate_type_code IN (...) where null is allowed, and a separate completeness check where it is not; NOT EXISTS instead of NOT IN

Also known as: Nulls treated by accident (data quality rule)

Related knobits

Builds on

All 31 knobits of Derive data quality rules.

Source: Review checklist 07-dq-rules, row 14; ISO 9075; Codd 1979