The Register

R-2026-10-18-A. Entry fingerprint

Entered 18 October 2026. From this date every entry carries a fingerprint: the SHA-256 checksum of its canonical text, taken on the day the entry goes in.

The canonical text is built the same way every time, so anyone can recompute it. The first line is the tag chr-entry-v1. Then come fifteen lines, one per field, in this order: id, section, scoring_date, sort_date, test, owner, date_source, status, measure, money, funding, argument, cost_to_date, supersedes_id, supersedes_hash. Each line is the field name, an equals sign, then the value. A field with no value is left empty after the equals sign. In each value, the text is normalised to Unicode NFC, every run of spaces, tabs or line breaks becomes one space, and spaces at the start and end are removed. The lines are joined by a single line feed, with no line feed at the end, and encoded as UTF-8. The fingerprint is the SHA-256 of those bytes, written as 64 lowercase letters and digits.

A new date is a new entry. It gets its own id and fingerprint and cites the old entry's id and fingerprint in supersedes_id and supersedes_hash. The old entry stays, with its old fingerprint.

Scoring is also a new entry. On the scoring date the result goes in as a new, dated entry with its own id and fingerprint, citing the scored entry's id and fingerprint in supersedes_id and supersedes_hash. The scored entry is not edited in place.

Every update publishes a manifest listing each entry's id and fingerprint, with the checksum of the CSV it was computed from. The manifest is kept in the public record and a Wayback Machine snapshot of it is taken at each update. Manifests are never replaced: each update adds a new one.

If an entry's fingerprint ever differs from the last manifest without a dated entry explaining why, that is itself a correction to be entered. The script that computes the fingerprints is published in the record at scripts/hash_entries.py, and anyone can run it on the downloaded CSV. The public record's commit history is already a chain of checksums; the fingerprints let a reader check a single entry without trusting this page.

This rule applies from 18 October 2026 forward. Entries scored on or before that date, including HR5334, stand as recorded.

R-2026-10-18-B. Cost to date

Entered 18 October 2026. Every entry carries a cost to date. It is filled in on the scoring date from a public source that shows the figures of whoever holds them: the department, Crown body, company, court, foreign government, the Bank of Canada or this desk. For governments that means sources such as the Public Accounts, a Departmental Results Report, the Main or Supplementary Estimates, a Parliamentary Budget Officer report, a written answer or Order Paper response, or an access to information release; for others, their own published reports, filings or records. The cell gives the amount, the source, its URL and the date it was read.

If no public figure exists on the scoring date, the cost sub-score is FAILED, and the entry names whoever holds the figure. "Cannot determine" is FAILED. There are no exemptions. The desk never estimates a cost to date. Before the scoring date, the cell reads OPEN.

Cost to date sits inside the existing cost sub-score. Like hype and means, it never changes the PASS or FAILED and never moves a cell.

This rule applies from 18 October 2026 forward and is never applied retroactively. Entries already on the register carry cost to date OPEN until their own scoring date. Entries scored on or before 18 October 2026, including HR5334, keep cost to date OPEN.

R-2026-10-18-C. Fingerprint layout version 2

Entered 18 October 2026. From this date the fingerprint uses layout chr-entry-v2. It is built exactly as the chr-entry-v1 layout in rule A, except that the first line is the tag chr-entry-v2 and three more lines follow the fifteen fields of v1, in this order: hype_score, means_score, cost_score. Every entry now carries all three sub-scores, each MATCHED, MIXED, FAILED or OPEN. An entry not yet resolved reads OPEN.

The reason for the change: the v1 layout left the hype, means and cost sub-scores outside the fingerprint, so a sub-score could have changed without any fingerprint showing it. Layout v2 closes that gap. Any column added to the register later needs a new layout and a dated rule entry; until then, that column is outside the fingerprint and the rule entry says so.

The v1 manifest of 18 October 2026 is kept unchanged in the record. From this update a v2 manifest is published alongside it, named entry-hashes-v2 followed by the update, and every build checks the data against both. No v1 fingerprint changes. The v2 fingerprints are new numbers for the same entries, not corrections.

A second update on the same day carries a letter after the date, as in 2026-10-18b, so no published file is ever overwritten.

R-2026-10-19-A. A capacity test on every levels plan

Entered 19 October 2026. Each time an Immigration Levels Plan falls due under section 94(1) of the Immigration and Refugee Protection Act, the register enters one capacity test for that plan before it is tabled. PASS: any permanent resident target above the prior plan's target for the same year is made expressly conditional on at least one published, numeric capacity measure with a stated trigger (housing starts or completions against new residents, a dated corridor or financing milestone, or a productivity or investment series). PASS-NO-INCREASE: no increase, test not triggered. FAILED: an increase with no such condition. The entry sits in the section for recorded files, because it carries a third reading and its scoring day can move to within 3 days of tabling, with a hard stop at the statutory window. The next plan's entry goes in the day after the current one is scored. A companion reading of housing completions per additional resident may be entered; its baseline is filled only from a primary source and reads OPEN until then.

R-2026-10-19-B. Transfer files: delivered against committed

Entered 19 October 2026. The register may hold entries for single international assistance transfers, read from the department's own project data. Each is scored on a fixed date on three points: disbursed at or above committed, activity status closed or in finalisation, and a published result linked to the activity. Any one missing is FAILED. Limits: at most five transfer entries open at any time; only activities with a committed amount of CAD 50 million or more and a published planned end date. The figures are the department's own and are labelled as such; the register does not present them as an audit. A loss or fraud finding abroad is never attached to a Canadian file unless a source traces it to Canadian funds. No totals, rankings or commentary on recipients.

R-2026-10-19-C. Ratchet hold

Entered 19 October 2026. An entry that scores a reduction (a headcount, a spending share, a backlog) may carry a conditional hold entry: the lower level is still met on the same series three readings later. The hold is scored only if its parent is scored PASS. If the parent is FAILED, the hold is entered VOID on the same day, not extended. Holds sit in the section for recorded files, beside the register's other conditional entries.

R-2026-10-19-D. Sunsets that fire

Entered 19 October 2026. A statutory sunset, or a statutory review deadline, in a statute already tied to an entry on this register may be entered and scored on its own date. PASS: on that date the consolidated text shows the limit unamended and the power has lapsed, or the review report has been laid. FAILED: the limit was extended or removed, or the review was not laid, cited by bill number or Journals entry. This scores the statute's own date as written. It complements the entry that scores whether a new power carries a sunset at all (BOOMBUST-SUNSET). Statutes not tied to a register entry are not added.

R-2026-10-19-E. Instrument tag

Entered 19 October 2026. Where an entry involves public money, the money column begins with INSTRUMENT: followed by GRANT, LOAN, GUARANTEE, EQUITY or IN-KIND, set only when a primary page shows it, and otherwise INSTRUMENT: OPEN. For a loan or a guarantee, the cost to date on the scoring date gives the outstanding or guaranteed amount, from the Public Accounts of Canada or the lender's own published page, separately from any grant amount. The desk never estimates it.

Labels and the fingerprint. Rules A, B and D also put EVIDENCE-HOLDER: SELF (the owner's own data) or EVIDENCE-HOLDER: INDEPENDENT (a body other than the owner) at the start of the measure column. These labels, and the INSTRUMENT tag, are written inside columns that already exist (test, measure, money, date source), so they are inside the chr-entry-v2 fingerprint. No column is added by these rules, so no new fingerprint layout is needed and chr-entry-v2 stays in use. A column added later still needs its own layout and rule entry (rule entry C of 18 October 2026).

These rules apply from 19 October 2026 forward and are never retroactive. No existing entry is changed.

R-2026-10-19-F. Next on the clock

Entered 19 October 2026. The page shows, above the table of entries, the five nearest live entries not yet scored, on or after the date of the update, in scoring-date order, with scoring date, id, section and owner, and one line naming every live entry past its scoring date and not yet scored. It is display only and is rebuilt with each update, so it reads as at the update date. No column is added and no entry is changed; the chr-entry-v2 fingerprint is unaffected.

R-2026-10-19-G. Snapshot check

Entered 19 October 2026. After each update the page, the dated CSV and the dated manifest are saved to the Wayback Machine, and scripts/check_wayback.py checks that every recorded snapshot answers with its archived date. A missing or unresolved snapshot is reported, not hidden; where an update has none, the register says so in its failure or correction notes rather than leaving the gap silent.

R-2026-10-19-H. Cap guard on transfer entries

Entered 19 October 2026. The limit of five open transfer entries in rule entry B of 19 October 2026, and its CAD 50 million floor, can be changed only by a new dated public rule entry that states the old limit, the new limit and the reason. No transfer entry beyond the limit in force is entered before that rule entry is published. scripts/add_entry.py refuses a sixth open transfer entry (ids beginning XFER-), and a pipeline test proves it.

R-2026-10-19-I. Third mirror

Entered 19 October 2026. A third public copy of this repository is planned on Codeberg (codeberg.org), as a pull mirror of the GitHub repository, so the record survives the loss of any one host. Status: PENDING SETUP. The mirror address is added to this page by a later dated rule entry once it is live and its CSV checksum matches this copy.

R-2026-10-19-J. Third copy on Codeberg

Entered 19 October 2026. The third public copy named in rule entry I of 19 October 2026 is at https://codeberg.org/citizen-held-record/register. Status: LIVE (manual copy, refreshed by the desk after each update). It is a copy, not an automatic mirror: after each update the desk refreshes it and checks that its head commit and the checksum of the dated CSV match this repository. If they do not match, the register says so in its correction notes and names the update the copy last matched.

These rules apply from 19 October 2026 forward and are never retroactive. No existing entry is changed.

R-2026-10-22-A. Reading aids and essay links (display only)

Entered 22 October 2026. The page shows three display-only aids, rebuilt with each update from the table: a status summary at the top (counts by status and section, entries past their scoring date and not yet scored, and entries due in the next 30 days), a box on how to read the page with one worked example, and a list of the essays that set tests. The essay column shows a link to the published essay where one exists, read from data/essay-links.csv in this record, which maps an entry id to the essay's title, address and publication date. Each row id links to that row. No column is added to the CSV and no entry is changed: a row's own argument field stays as entered, and where the two differ the published essay link is the reading aid and the entry is the record. The essay-links file is outside the chr-entry-v2 fingerprint; changes to it are listed in the public record's commit history. Where an entry as entered shows an internal desk working reference (a working file name or note), the page and README show "[internal desk reference hidden in display, 22 Oct 2026]" in its place; the entry, the CSV and the JSON stay as entered, and each such case is listed in a dated correction entry.

This rule applies from 22 October 2026 forward and is never retroactive. No existing entry is changed.

R-2026-10-24-A. Housekeeping

Entered 24 October 2026. Housekeeping (24 October 2026): internal working notes (approval notes, timestamps, internal file references) are not part of the record and may be removed from any row. Removal never changes a row's outcome, date, owner, test, sources or result, and is shown in the published file fingerprints.

How it is shown. Each removal is listed in data/housekeeping-log.csv with the date, the update, the row id, the field, and the row's fingerprint before and after. The changed row gets a new fingerprint in the next dated manifest, and that manifest names the log and its checksum. The build accepts a changed fingerprint only when the log lists it, and only when the change is in the date source, measure, money, funding or essay field and either deletes text or replaces it with OPEN; any other change still stops the build. Earlier dated files stay as published, so anyone can compare a row before and after. This is the one exception to the rule that an entry is never edited after it goes in.

First use, update 2026-10-24a: rows BM1, KAMLOOPS-EXCAV, EA-REFORM (date source), QC-SEATMATH (essay) and COVID-RESIDUE (measure).

This rule applies from 24 October 2026 forward.

Correction, 25 October 2026. The sentence "This is the one exception to the rule that an entry is never edited after it goes in" is restated: entries are append only for substance; internal working notes may be removed under R-2026-10-24-A, and, from a test, internal approval notes only under R-2026-10-25-A, each removal logged with the row's fingerprint before and after.

R-2026-10-25-A. Housekeeping in the test field

Entered 25 October 2026. Rule entry R-2026-10-24-A is extended to the test field, for one purpose only: removing internal approval notes, such as a note that a change was approved or when it was approved. Nothing else in a test may be removed under this rule. Removal never changes a row's outcome, date, owner, test meaning, sources or result. Where an approval note cannot be taken out without changing what the test says, it stays as published.

How it is shown. As under R-2026-10-24-A, each removal is listed in data/housekeeping-log.csv with the date, the update, the row id, the field, and the row's fingerprint before and after, one line per fingerprint layout. The build accepts a changed test only when the log lists it and the change deletes one stretch of text; a test can never be replaced with OPEN, and any other change still stops the build. Earlier dated files stay as published, so anyone can compare a row before and after.

First use, update 2026-10-25a: row HOUSING-STARTS (test). In the same update, row BEC1 (date source) has an approval note removed under R-2026-10-24-A. The rows before the change are in public-live-rows-2026-10-24c.csv (and, for the v1 layout, public-live-rows-2026-10-18.csv).

This rule applies from 25 October 2026 forward. R-2026-10-24-A stays as entered.