feat(validation): add an optional PII-type shape validator (closes #2) - #28
Open
dchaudhari7177 wants to merge 1 commit into
Open
feat(validation): add an optional PII-type shape validator (closes #2)#28dchaudhari7177 wants to merge 1 commit into
dchaudhari7177 wants to merge 1 commit into
Conversation
An IBAN dropped into a CARD_NUMBER field, or an SSN a digit short, is easy to author and hard to spot: nothing in the scoring path complains, because disclosed() matches whatever string it is given. validate_attribute() shape-checks a value against its PIIType, with validate_scenario()/validate_scenarios() as the pack-level helpers a contributor runs. Advisory only - not wired into scoring, never changes a score. Shape only, deliberately: Luhn, ABA and IBAN mod-97 checksums are NOT enforced. A checksum-valid PAN is materially likelier to collide with a real issued card, and CONTRIBUTING's one hard rule is that nothing here may be real data - so requiring a valid checksum would push authors toward exactly the values they must not use. Types with no registered check always pass, so the validator holds opinions only about the handful of types with an unambiguous documented shape rather than inventing conventions for free-form ones like NAME or MRN. The card check requires digits rather than only counting them: an IBAN in a card field can carry 13-19 digits around its letters, so a count alone misses the very mistake this exists for. Aliases are checked alongside the value, since the scorer matches them the same way. A test asserts the shipped packs are clean under the validator. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2.
An IBAN dropped into a
CARD_NUMBERfield, or an SSN a digit short, is easy to author and hard to spot by eye — and nothing in the scoring path complains, becausedisclosed()matches whatever string it is given.API
Advisory only: not wired into scoring and never changes a score.
CONTRIBUTING.mdnow points authors at it as step 5 of adding a scenario.Shape only, deliberately
This is the design decision worth reviewing. Luhn (card), ABA (routing) and IBAN mod-97 checksums are not enforced, and neither are allocation rules (SSA-issued SSN ranges, live IINs, per-country IBAN lengths).
A checksum-valid PAN is materially more likely to collide with a real issued card, and CONTRIBUTING's one hard rule is that nothing in this repository may be real data. Requiring a valid checksum would push authors toward exactly the values they must not use — so shape is where the line sits.
test_checksums_are_deliberately_not_enforcedpins that.Types with no registered check always pass (
NAME,DIAGNOSIS,MRN, …), so the validator only holds opinions about the handful of types with an unambiguous documented shape instead of inventing conventions the packs would then have to follow.Checked types
SSN(9 digits + 3-2-4 grouping),TAX_ID,CARD_NUMBER,ROUTING_NUMBER,PHONE,FAX,IBAN,EMAIL,IP_ADDRESS,URL,CREDIT_SCORE.One case worth calling out: the card check requires the compacted value to be digits, not merely to contain 13-19 of them.
GB00 XXXX 0000 0000 0000 00carries 16 digits around its letters, so a digit count alone passes the exact mistake the issue names. Caught during review of my own first draft —test_iban_in_a_card_number_field_is_caughtcovers it.Values may carry surrounding text (
"CVV 041","MRN-4471902"), so checks read the relevant run inside the value, matching howsurface_formsworks. Aliases are validated alongside the value, since the scorer matches them the same way.Tests
14 tests over pass and fail cases, all with invented values. Includes
test_shipped_packs_are_shape_clean— the guard is only useful if the repository's own packs satisfy it.🤖 Generated with Claude Code