Most breach notification guides are prose. They age quietly, they cannot be tested, and when a reader asks “which section says that” the answer is a shrug. We wanted something a breach coach could rely on at two in the morning and a lawyer could check in five minutes. This note explains how the two free tools on this site are built, what they refuse to do, and how they are kept current.
Datasets first, decisions second
Each tool is a dataset with a small decision layer on top.
The breach notification decision tool runs on rules.json: 38 regimes across federal, provincial, territorial, health and sector law. Each regime records who must notify whom, the statutory timing as written, whether the instrument sets a number of hours, the trigger threshold, the record keeping duty, the penalties, the primary sources with the section cited, and the date the entry was last verified against those sources.
The harm assessment tool runs on tests.json: 28 statutory harm tests. Each quotes the test (real risk of significant harm, risk of serious injury, significant harm, harm or embarrassment, or no threshold at all), lists the factors the statute or regulator names in their order, the examples of harm the statute gives, the record the organization must keep, and the sources with a verification date.
Both files are published under CC BY 4.0 at /tools/breach-notification/rules.json and /tools/harm-assessment/tests.json. Anyone can load them into their own tooling, and anyone can check an entry against its source.
What the engines do, and do not do
The decision layers are short, readable TypeScript with unit tests. The notification engine works out which regimes apply from jurisdiction, sector and a handful of organization flags, and computes deadlines only where an instrument sets a clock. It never decides the legal threshold for you: regimes gated on harm are labelled “assess” until the harm assessment says otherwise, and duties with no harm threshold are labelled “notify” whatever the harm score.
The harm engine applies the two prongs every Canadian regulator uses, sensitivity of the information and probability of misuse, to a set of answers, and writes out the reason for every point it adds or removes. Weights are documented choices; the statutes say what the factors are, not how to add them, so the page explains the matrix and the one rule we hold firmly: unknown facts make an assessment incomplete rather than confident. The conclusion is then phrased in each applicable statute’s words.
Neither tool sends an answer anywhere. The datasets are embedded in the page, the engines run in the browser, and the hand-off between the two tools travels in the URL fragment, which browsers never send to a server. A case file you save is a download to your own disk.
Sourcing rules
Every entry needs a primary source: the statute, the regulation, or the regulator’s own guidance. Where a legislation site blocks automated reads, the entry cites the regulator’s reproduction of the section and is marked on the page, so a reader knows the wording came from the commissioner’s guidance rather than the consolidated Act. Those entries are first on the quarterly list.
No figure appears without a source. Where we could not confirm a figure, the text says what is true without it. No entry uses secondary commentary for a deadline or a threshold; law firm bulletins are used only to confirm that a bill has or has not moved.
Keeping it current
Two scheduled reviews run against the repository. A monthly scan checks every source link, reads the regulator and counsel feed for amendments, in-force dates and new guidance, and opens a pull request for anything that changed, with the source sentence quoted. A quarterly review re-opens every source whether or not anything looks changed and refreshes the verification date on every entry it can confirm; entries it cannot confirm keep their old date and are listed. A validator fails the build when a regime id the engine relies on goes missing, when a date is malformed, or when an entry has not been verified in four months.
Changes ship through pull requests, never direct edits, and every one lands in the change log. Readers can report a correction from either tool page; corrections go the same route.
What it is not
The tools are general information, generated from the answers entered. They are not legal advice and they do not replace counsel. They exist so that the conversation with counsel starts from a sourced list and a written assessment rather than from a blank page.