docs: publish a design-decisions record - #17
Merged
Conversation
The reasoning behind the load-bearing decisions lived only in JSDoc comments and commit messages. A contributor asking why redaction anchors on written shape rather than on the validators had no findable answer — and the answer is a measurement, not an opinion. docs/design-decisions.md records eight such decisions with the evidence each rests on: format-never-existence; why a validator cannot be a detector; the measured false-positive rate per detector; the NUBAN residue proof and why it makes inferBanks useful but a silent detector dishonest; the python-stdnum precedent behind Tax ID vs TIN and vNIN vs NIN; the cite-a-source rule with the full list of what it has excluded; why detect() ordering is load-bearing including the 0.09% trade; and the bundle measurements behind the subpaths. Also records what is deliberately absent and why — prefix 0917, Yoruba and Pidgin label vocabulary, plate LGA decoding, VIN hex enforcement, historic area codes — so a future contributor does not 'fix' one of them without seeing the reason. This is possible because docs/ is now a committed directory: the local-only scratch space moved to .notes/ in .git/info/exclude. docs/ adds nothing to the published package (files is ["dist"], verified with npm pack). Linked from CONTRIBUTING.md.
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.
Documentation only. Independent of #16 — different files, no conflict.
What this unlocks
docs/is now a committed directory: the local-only scratch space moved to.notes/in.git/info/exclude. Verified thatdocs/adds nothing to the published package —filesis["dist"], andnpm pack --dry-runshows 0docs/files in the tarball.Why
Until now the reasoning behind the load-bearing decisions lived only in JSDoc comments and commit messages. A contributor asking "why is redaction anchored on written shape rather than on the validators?" had no findable answer — and the answer is a measurement, not an opinion.
What's in it
Eight entries, each with the evidence it rests on:
parseXnormalizes before testing, soisPhone("Total: NGN 8,031,234,567")istrue; redaction anchors on shape and uses the validator only to vetoisPhone, 0.4% for plate/passport)inferBanksuseful while making a silent detector dishonestpython-stdnumprecedent (de.idnr/de.stnr,in.aadhaar/in.vid) behind Tax ID vs TIN and vNIN vs NIN0917, Yoruba labels, Pidgin labels, plate LGA decoding, VIN hex enforcement, historic area codesdetect()ordering is load-bearing — including the measured 0.09% trade behind placing fixed-line ahead of NINredact.tsmust not import the bank datasetPlus a sources list and the known follow-ons.
The §6 list is the part I'd most want a future contributor to read. Each of those omissions looks like an oversight and is actually a decision — someone "fixing" the VIN pattern to
[0-9A-F]would start rejecting real voter cards.What I deliberately did not do
I did not move the README's
<details>content here, even though freeingdocs/was originally proposed for exactly that. Those explanations sit next to the code they justify, they work on npm where clicking away from the page is a real cost, and #16 already verified them. Moving them would be churn for marginal gain.So
docs/gets the thing that had no home — a contributor-facing design record — rather than material that already has a good one.Changeset is
patch.