Microsoft Purview Data Map Sensitivity Labelling

Your testing has corrected two things in my earlier answer, and both corrections are right. Worth stating clearly so anyone reading this later gets the accurate version.

FIRST CORRECTION, AND IT MATTERS FOR YOUR SCOPE

I implied that UK Unique Taxpayer Reference and Electoral Roll Number would need a custom SIT. That was wrong. Both exist as Microsoft built-in sensitive information types.

https://learn.microsoft.com/purview/sit-defn-uk-unique-taxpayer-reference-number

https://learn.microsoft.com/purview/sit-defn-uk-electoral-roll-number

Both also appear under RegEx Classifications in the Data Map list, so all six of the UK identifiers in your summary have a built-in SIT behind them. You can drop the hedge in your requirement document. The only caveat left is tenant rule picker availability, which is a tenant state question rather than a platform limitation.

Do note that both are medium confidence and keyword dependent within a 300 character proximity. Electoral Roll is two letters followed by one to four digits, which is a weak pattern on its own, so in a database column with no surrounding keywords it may under detect. Worth testing that one specifically rather than assuming parity with NI number.

SECOND CORRECTION

You are right that Date of Birth is pattern based rather than machine learning. It sits under RegEx Classifications, not under Machine Learning based classifications. I grouped it wrongly.

That also means the shortcut I gave you was incomplete. Ignoring the Machine Learning section is necessary but not sufficient, because the RegEx section contains entries with no standalone built-in SIT equivalent either, Date of Birth and Email being exactly those. The reliable test is per classification, checking whether a built-in SIT of the same name exists, rather than by section.

Your framing is more accurate than mine was. Machine learning classifications and advanced named entities are excluded by design. Pattern based classifications without a published standalone SIT are a separate category, excluded for a different reason.

ON COLUMN LEVEL VERSUS ASSET LEVEL

Your point that the confirmed native target for Azure SQL is column level metadata, and that table level inheritance should not be assumed, is a useful correction to what I suggested. My asset grain advice comes from file based estates and does not transfer cleanly here. Treat your tested behaviour as authoritative over my general advice.

ON YOUR THRESHOLD DISTINCTION

Separating the 60 percent threshold from rule picker availability is the right call, and it is a distinction worth keeping explicit in the document. They fail differently. A threshold failure means the classification never appears at all, so there is nothing to label. A picker failure means the classification is visible in Data Map but has no eligible condition. Two different investigations, and the symptom looks identical from a report.

Your summary is a better reference than anything Microsoft currently publishes on this. Worth considering posting the table publicly once you are through validation.