Model Act Generated from the NSIR / CLIP Clean-System Framework
Long Title
An Act to establish systems integrity requirements for high-impact public systems; to require system mapping, auditability, appealability, reversibility, citizen legibility, and automation readiness before high-impact public systems are digitized, automated, integrated, or accelerated; and to strengthen democratic correction, public accountability, lawful administration, and machine-assisted self-government.
Preamble
Whereas public systems exercise authority over rights, benefits, obligations, access, eligibility, enforcement, public services, public funds, infrastructure, security, and the conditions of civic life;
Whereas democratic government requires that public power remain lawful, visible, accountable, challengeable, auditable, reversible where possible, and capable of correction;
Whereas artificial intelligence, automation, digital platforms, data-sharing systems, vendor systems, and integrated administrative workflows can increase the speed, scale, opacity, and lock-in of public administration;
Whereas a public system that is opaque, unappealable, unauditable, legally unclear, or impossible to correct should not be accelerated by automation;
Whereas the purpose of public modernization is not machine government, but machine-assisted self-government;
Whereas high-impact public systems should be mapped, audited, repaired, and made democratically correctable before being automated, digitized, or integrated at scale;
Therefore, Parliament enacts as follows.
Part 1 — Short Title, Purpose, and Principles
1. Short Title
This Act may be cited as the Public Systems Integrity Act.
2. Purpose
The purpose of this Act is to ensure that high-impact public systems are designed, operated, reviewed, and modernized in a manner that preserves lawful authority, public purpose, citizen legibility, auditability, meaningful review, error correction, reversibility, and democratic accountability.
3. Core Rule
A responsible public authority shall not deploy, expand, automate, digitize, integrate, or materially alter a high-impact public system unless the system has been mapped, assessed for systems integrity, and determined to be sufficiently lawful, auditable, appealable, reversible, citizen-legible, and safe for the proposed use.
4. Sequence of Public-System Modernization
High-impact public systems shall follow the sequence:
1 map first;
2 audit second;
3 repair third;
4 automate fourth.
5. Interpretation
This Act shall be interpreted in a manner consistent with:
1 constitutional rights and freedoms;
2 the rule of law;
3 procedural fairness;
4 responsible government;
5 access to justice;
6 privacy and data protection;
7 public accountability;
8 public-sector duty of care;
9 federal, provincial, territorial, municipal, and Indigenous jurisdictional responsibilities;
10 democratic correction and public legitimacy.
6. Non-Substitution Principle
Nothing in this Act replaces Parliament, legislatures, courts, tribunals, Indigenous rights, public consultation duties, lawful administrative discretion, or democratic decision-making.
Systems integrity review may map, assess, diagnose, classify, recommend, and require reporting.
It shall not decide political values, override constitutional obligations, or substitute technical analysis for lawful democratic authority.
Part 2 — Definitions
7. Definitions
In this Act:
“affected person” means a person, household, organization, community, business, Indigenous government, public body, or legal entity whose rights, benefits, obligations, eligibility, access, legal status, service level, enforcement exposure, property, liberty, privacy, safety, or public interest may be materially affected by a high-impact public system.
“AI system” means a machine-based system that, for explicit or implicit objectives, generates outputs such as predictions, classifications, recommendations, rankings, content, risk assessments, summaries, decisions, or decision-support outputs that influence public administration.
“algorithmic system” means any computational, statistical, rules-based, machine-learning, artificial intelligence, or automated process used to support, recommend, prioritize, classify, route, approve, deny, enforce, or otherwise influence a public decision or public service.
“automation” means the use of software, algorithmic processes, workflow rules, artificial intelligence, robotic process automation, decision-support tools, or other computational systems to perform or influence administrative functions
“audit trail” means a record sufficient to reconstruct the authority, data, rules, workflow, automation, human review, decision rationale, output, appeal, correction, and system changes relevant to a public decision or public-system operation
“citizen-legible” means understandable to an ordinary affected person through plain-language explanation sufficient to identify the system’s purpose, responsible authority, decision process, data use, appeal path, correction process, and accountability mechanisms.
“clean public system” means a public system whose purpose is clear, authority is lawful and bounded, data is accurate and correctable, decisions are traceable, outputs are measurable, appeals are meaningful, failure modes are visible, audit trails are preserved, vendors are inspectable, harms are reversible where possible, and automation is gated by democratic correction.
“critical public system” means a high-impact public system whose failure could materially affect constitutional rights, essential services, public safety, emergency response, national security, critical infrastructure, public finance, legal status, public trust, or continuity of government.
“data-flow map” means a documented account of what data is collected, generated, inferred, shared, retained, accessed, corrected, deleted, or reused within a public system.
“failure mode” means a foreseeable way in which a public system may fail to achieve its public purpose, violate rights, create delay, produce error, obscure authority, prevent appeal, become captured, generate unreviewable decisions, create irreversible harm, or resist correction.
“high-impact public system” means a public system that materially affects rights, benefits, obligations, eligibility, access to essential services, enforcement, legal status, public safety, housing, immigration, taxation, health, education, child welfare, policing, emergency powers, infrastructure, procurement, national defense, or other significant public interests.
“meaningful human review” means review by a human decision-maker with authority to inspect the relevant record, consider additional evidence, correct relevant data, provide reasons, vary or reverse the decision where appropriate, and identify systemic error where present.
“public authority” means a department, ministry, agency, Crown corporation, tribunal, regulator, public office, municipality, delegated authority, contractor acting under public authority, or other body exercising public functions under law.
“public system” means an organized arrangement of law, authority, institutions, personnel, data, workflows, budgets, vendors, technology, decisions, outputs, appeals, reviews, and feedback mechanisms through which public authority is exercised.
“responsible authority” means the public authority legally responsible for the design, operation, procurement, deployment, oversight, or modernization of a public system.
“rollback” means the ability to suspend, reverse, limit, decommission, correct, or restore a public system, process, data flow, automation, policy, or decision pathway when it becomes unlawful, harmful, inaccurate, unappealable, unauditable, insecure, or inconsistent with public purpose.
“systems integrity review” means a structured review of a high-impact public system to determine whether the system is lawful, purposeful, mapped, auditable, appealable, reversible, resilient, citizen-legible, resistant to capture, and safe to automate or operate at scale.
“system map” means a documented representation of the purpose, authority, actors, institutions, data flows, decision points, workflows, outputs, feedback loops, appeal paths, audit trails, automation components, vendors, risks, and correction mechanisms of a public system.
Part 3 — Application
8. Application of Act
This Act applies to every high-impact public system operated, procured, funded, authorized, delegated, substantially modified, digitized, automated, or integrated by a public authority.
9. High-Impact Classification
A public system shall be classified as high-impact if it affects, or is reasonably likely to affect:
1 constitutional or legal rights;
2 eligibility for public benefits;
3 access to essential public services;
4 public housing, shelter, health, education, immigration, taxation, policing, child welfare, or social services;
5 public safety, emergency response, national security, or critical infrastructure;
6 enforcement, inspection, investigation, licensing, permitting, or sanctions;
7 public procurement, public funds, or public assets above a prescribed threshold;
8 legal status, identity, mobility, property, livelihood, or personal liberty;
9 public access to digital identity, public portals, or data-sharing systems;
10 any other matter prescribed by regulation.
10. Critical Public Systems
A responsible authority shall designate a high-impact public system as critical where system failure could create serious harm to rights, essential services, safety, infrastructure, security, public finance, public trust, or continuity of government.
Critical public systems shall be subject to enhanced review, reporting, auditability, and rollback requirements.
11. Prohibition on Avoidance
A responsible authority shall not divide, outsource, relabel, procure, delegate, or technically reclassify a public system for the purpose of avoiding the requirements of this Act.
12. Contractors and Delegated Authorities
Where a public authority uses a contractor, vendor, delegated body, platform provider, or third-party system to perform or support a high-impact public function, the responsible authority remains accountable under this Act.
Part 4 — Duty to Map Public Systems
13. System Mapping Duty
Before implementing, materially altering, automating, integrating, or expanding a high-impact public system, the responsible authority shall prepare a system map.
14. Contents of System Map
A system map shall identify:
1 the public purpose of the system;
2 the legal authority for the system;
3 the responsible authority and accountable officials;
4 affected persons and affected communities;
5 institutions, agencies, contractors, vendors, and decision-makers involved;
6 inputs, workflows, decision points, and outputs;
7 data collected, generated, shared, retained, corrected, deleted, or reused;
8 AI, automation, algorithmic, or decision-support components;
9 human roles and review points;
10 appeal, complaint, redress, and remedy pathways;
11 audit trails and recordkeeping mechanisms;
12 failure modes and foreseeable harms;
13 rollback, suspension, correction, and decommissioning pathways;
14 public reporting mechanisms;
15 feedback loops through which error and failure return to decision-makers.
15. Public Version
The responsible authority shall publish a citizen-readable version of the system map unless publication would create a demonstrable security, privacy, or legal risk.
Where full publication is restricted, the responsible authority shall publish a summary sufficient to explain the system’s purpose, authority, affected population, data use, automation role, appeal path, auditability, and accountability safeguards.
16. Restricted Annex
Where national security, cybersecurity, privacy, law enforcement, or commercial confidentiality requires restriction, the responsible authority shall prepare a restricted annex available to authorized reviewers, auditors, courts, oversight bodies, or legislative committees.
Confidentiality shall not eliminate auditability.
Part 5 — Systems Integrity Review
17. Review Requirement
A responsible authority shall complete a systems integrity review before a high-impact public system is:
1 created;
2 materially altered;
3 digitized;
4 automated;
5 integrated with another public system;
6 connected to an AI, algorithmic, or automated decision-support system;
7 outsourced to a vendor;
8 expanded in scale, scope, authority, data use, or affected population.
18. Core Review Questions
A systems integrity review shall determine:
1 whether the system has a clear public purpose;
2 whether the system has lawful and bounded authority;
3 whether the system has been mapped;
4 whether affected persons can understand how the system affects them;
5 whether affected persons can receive reasons;
6 whether affected persons can access meaningful human review;
7 whether errors can be corrected;
8 whether harms can be reversed where possible;
9 whether the system preserves sufficient audit trails;
10 whether vendors and technical systems are inspectable;
11 whether the system has visible failure modes;
12 whether the system has sufficient resilience and continuity safeguards;
13 whether the system is resistant to capture, drift, or hidden expansion;
14 whether the system is safe to automate, digitize, or scale.
19. Review Axes
A systems integrity review shall assess the system across the following axes:
1 public purpose;
2 legal authority;
3 system mapping;
4 output conversion;
5 auditability;
6 redress and appeal;
7 reversibility;
8 feedback strength;
9 capture resistance;
10 AI and digital exposure;
11 data integrity;
12 vendor dependency;
13 citizen legibility;
14 resilience under stress;
15 implementation and repair capacity.
20. Classification of Findings
Each finding in a systems integrity review shall be classified as one or more of the following:
1 sourced fact;
2 official data;
3 legal authority;
4 audit finding;
5 expert assessment;
6 systems inference;
7 scenario risk;
8 operational risk;
9 recommendation;
10 claim requiring further review.
21. Automation Readiness Rating
A systems integrity review shall assign the system an automation readiness rating:
1 Not Ready — the system is unmapped, unlawful, unappealable, unauditable, irreversible, unsafe, or insufficiently citizen-legible.
2 Conditionally Ready — the system may proceed only after specified repairs are completed.
3 Limited Ready — the system may proceed for low-risk or supervised use subject to monitoring, human review, and rollback safeguards.
4 Ready — the system satisfies the requirements of this Act and may proceed with prescribed safeguards.
5 Prohibited Use — the system shall not be automated or deployed for the proposed purpose because risk cannot be adequately mitigated.
22. Repair Sequence
Where a system is classified as Not Ready, Conditionally Ready, or Limited Ready, the responsible authority shall prepare a repair sequence identifying:
1 immediate risks;
2 legal changes required;
3 administrative changes required;
4 data-quality repairs required;
5 appeal or redress repairs required;
6 audit-trail repairs required;
7 vendor or procurement changes required;
8 rollback or reversibility changes required;
9 public communication requirements;
10 date for reassessment.
Part 6 — Public Purpose and Authority
23. Public Purpose Statement
Every high-impact public system shall have a public purpose statement.
The statement shall identify:
1 the problem the system exists to address;
2 the public good it serves;
3 the outcomes it is expected to produce;
4 the harms it is expected to reduce;
5 the affected population;
6 the authority responsible for results.
24. Authority Map
Every high-impact public system shall have an authority map.
The authority map shall identify:
1 statutory authority;
2 regulatory authority;
3 delegated authority;
4 administrative discretion;
5 responsible officials;
6 review bodies;
7 appeal bodies;
8 oversight bodies;
9 limits on power;
10 affected rights and interests.
25. No Unmapped Authority
A responsible authority shall not exercise, delegate, automate, or operationalize a high-impact public power unless the authority is identified in the authority map.
26. Material Expansion of Authority
A material expansion of authority, data use, automation, enforcement, eligibility determination, service exclusion, or affected population shall trigger a new or updated systems integrity review.
Part 7 — Data Integrity and Data-Flow Mapping
27. Data-Flow Map
Every high-impact public system shall maintain a data-flow map.
28. Contents of Data-Flow Map
A data-flow map shall identify:
1 what data is collected;
2 the legal authority for collection;
3 the source of the data;
4 who may access the data;
5 where the data is stored;
6 where the data is shared;
7 whether data is inferred, derived, scored, or classified;
8 whether data is used in AI, automation, or decision-support;
9 how long data is retained;
10 how data may be corrected;
11 when data must be deleted, archived, anonymized, or de-identified;
12 risks created by data errors, reuse, sharing, or integration.
29. Data Correction Path
An affected person shall have a practical pathway to request inspection and correction of relevant personal or case data used in a high-impact public decision.
30. Material Data Error
Where a decision was materially influenced by incorrect, stale, incomplete, unlawfully obtained, or misapplied data, the responsible authority shall provide a correction process and, where appropriate, reconsideration or remedy.
31. Secondary Use
Data collected for one public purpose shall not be used for a materially different high-impact purpose without legal authority, public notice, and systems integrity review.
Part 8 — AI, Automation, and Digital Exposure
32. Automation Disclosure
A responsible authority shall disclose whether AI, automation, algorithmic scoring, decision-support, rules engines, predictive analytics, generative systems, or automated workflows are used in a high-impact public system.
33. AI and Automation Register
A responsible authority shall maintain a public register of AI, automation, algorithmic, and decision-support systems used in high-impact public administration.
34. Contents of Register
The register shall include:
1 system name;
2 responsible authority;
3 public purpose;
4 affected population;
5 legal authority;
6 automation role;
7 decision or process affected;
8 data categories used;
9 human review mechanism;
10 appeal path;
11 audit status;
12 incident history where appropriate;
13 vendor involvement;
14 date of last review;
15 next review date;
16 automation readiness rating.
35. Prohibited Automation
A responsible authority shall not deploy automation in a high-impact public system where:
1 the legal authority is unclear;
2 affected persons cannot receive reasons;
3 meaningful human review is unavailable;
4 the decision pathway cannot be audited;
5 material errors cannot be corrected;
6 harm cannot be reversed where reversal is necessary;
7 vendor systems cannot be inspected;
8 the system has been classified as Not Ready or Prohibited Use.
36. Human Accountability
No public authority shall avoid accountability by attributing a public decision to AI, automation, a vendor system, a model, a database, or a workflow.
A human public authority remains responsible for every high-impact public decision.
Part 9 — Reasons, Human Review, Appeal, and Remedy
37. Reasons Requirement
An affected person shall receive understandable reasons for a high-impact public decision.
38. Contents of Reasons
Reasons shall identify:
1 the decision made;
2 the authority relied on;
3 the relevant facts or data;
4 the role of AI or automation, if any;
5 the responsible authority;
6 the available review or appeal path;
7 the method for correcting relevant errors;
8 the available remedy, if applicable.
39. Meaningful Human Review
An affected person shall have access to meaningful human review of a high-impact automated, AI-assisted, or system-driven decision.
40. Powers of Human Reviewer
A human reviewer shall have authority to:
1 inspect the relevant record;
2 consider additional evidence;
3 correct relevant data;
4 require explanation of automation or workflow influence;
5 provide reasons;
6 vary or reverse the decision where appropriate;
7 recommend systemic correction where recurring error is identified.
41. Appeal and Remedy
A high-impact public system shall provide a clear appeal or remedy pathway.
The pathway shall identify:
1 who may appeal;
2 what may be challenged;
3 applicable timelines;
4 decision-maker on review;
5 evidence that may be considered;
6 remedies available;
7 process for systemic correction;
8 process for urgent relief where delay would cause serious harm.
42. No Illusory Review
A review process shall not satisfy this Act if the reviewer lacks authority to inspect the record, correct data, consider evidence, provide reasons, or vary the decision.
A rubber stamp is not review.
A chatbot is not appeal.
A form letter is not accountability.
Part 10 — Audit Trails and Recordkeeping
43. Audit-Trail Duty
Every high-impact public system shall preserve records sufficient to reconstruct material decisions, workflows, data uses, automation roles, human reviews, appeals, corrections, and system changes.
44. Contents of Audit Trail
An audit trail shall include, where applicable:
1 authority used;
2 data relied on;
3 rules applied;
4 workflow steps;
5 automation or AI involvement;
6 model version or rules version;
7 human review;
8 decision rationale;
9 notice to affected person;
10 appeal or complaint;
11 correction made;
12 system changes;
13 vendor involvement;
14 security or incident logs;
15 rollback or suspension action.
45. Retention
Audit records shall be retained for a period sufficient to support appeal, audit, legal review, public accountability, and systemic correction.
46. Tampering and Destruction
A person shall not knowingly destroy, alter, conceal, or prevent access to records required for auditability under this Act.
Part 11 — Vendor Auditability and Public Control
47. Vendor Auditability Requirement
A public authority shall not procure, deploy, or rely on a vendor-provided digital, automated, AI, case-management, identity, data-sharing, or decision-support system for high-impact public administration unless the contract preserves public auditability and public control.
48. Required Contract Terms
A contract for a high-impact public system shall include:
1 audit rights;
2 access to relevant logs;
3 documentation requirements;
4 performance testing;
5 security review;
6 incident reporting;
7 data portability;
8 interoperability;
9 subcontractor disclosure;
10 decommissioning support;
11 exit rights;
12 public authority control over public records;
13 prohibition on undisclosed material system changes;
14 compliance with this Act.
49. Vendor Secrecy
Trade secret, intellectual property, commercial confidentiality, or contractual secrecy shall not prevent authorized audit, legal review, oversight, or investigation of a high-impact public system.
50. Exit Capability
A responsible authority shall maintain a practical exit plan for high-impact vendor systems.
The exit plan shall identify:
1 alternative service continuity;
2 data export process;
3 record preservation;
4 transition requirements;
5 decommissioning process;
6 risk to affected persons;
7 fallback procedures.
Part 12 — Reversibility, Suspension, and Rollback
51. Reversibility Duty
A high-impact public system shall be designed, where possible, to allow harmful, unlawful, inaccurate, unappealable, unauditable, insecure, or inconsistent operations to be paused, corrected, limited, rolled back, or decommissioned.
52. Suspension Authority
A responsible authority shall suspend or limit a high-impact public system where the authority has reasonable grounds to believe the system:
1 lacks lawful authority;
2 creates serious and uncorrected harm;
3 produces material error at scale;
4 prevents meaningful human review;
5 lacks auditability;
6 relies on materially incorrect data;
7 is insecure;
8 is inconsistent with public purpose;
9 cannot be operated in compliance with this Act.
53. Emergency Suspension
Where delay would likely create serious harm, the responsible authority may suspend a high-impact public system immediately, subject to written reasons and subsequent review.
54. Decommissioning
A high-impact public system shall be decommissioned where repair is not feasible, lawful operation is impossible, or continued operation would create unacceptable risk to rights, safety, legality, public trust, or democratic accountability.
55. Rollback Plan
Every critical public system shall maintain a rollback plan identifying:
1 conditions triggering rollback;
2 authority to initiate rollback;
3 affected systems and services;
4 data preservation requirements;
5 notice to affected persons;
6 continuity of service plan;
7 post-rollback review;
8 public reporting obligations.
Part 13 — Reporting, Dashboard, and Public Transparency
56. Annual Public Systems Integrity Report
A responsible authority shall publish an annual public systems integrity report.
57. Contents of Annual Report
The annual report shall include:
1 high-impact systems operated;
2 systems mapped;
3 systems reviewed;
4 automation readiness ratings;
5 systems not ready for automation;
6 AI and automation systems registered;
7 appeal gaps identified;
8 auditability gaps identified;
9 rollback gaps identified;
10 repair sequences completed;
11 unresolved high-risk systems;
12 vendor dependency risks;
13 incidents and corrective actions;
14 planned reviews for the following year.
58. Public Dashboard
The government shall maintain a public systems integrity dashboard.
59. Dashboard Indicators
The dashboard shall include indicators for:
1 number of high-impact systems identified;
2 number of systems mapped;
3 number of systems reviewed;
4 number of systems automated;
5 number of systems classified Not Ready;
6 number of systems classified Conditionally Ready;
7 number of appeal gaps;
8 number of auditability gaps;
9 number of data correction gaps;
10 number of vendor auditability gaps;
11 number of rollback gaps;
12 repair progress;
13 next review dates.
60. Citizen-Readable Summaries
Every high-impact public system shall have a citizen-readable summary explaining:
1 what the system does;
2 who runs it;
3 who is affected;
4 what data is used;
5 whether AI or automation is involved;
6 how decisions are made;
7 how to appeal;
8 how errors are corrected;
9 how the system is audited;
10 how harm can be reversed where possible.
Part 14 — Independent Review and Red-Team Testing
61. Independent Review
A systems integrity review for a critical public system shall include independent review by persons with appropriate expertise in law, public administration, systems engineering, data governance, cybersecurity, privacy, audit, accessibility, and affected-domain knowledge.
62. Red-Team Review
A critical public system shall be subject to red-team review where failure could materially affect rights, safety, public trust, essential services, or democratic accountability.
63. Red-Team Questions
A red-team review shall ask:
1 how the system could fail;
2 how the system could be captured;
3 how the system could hide error;
4 how the system could deny meaningful appeal;
5 how the system could be misused;
6 how vendor dependency could weaken public control;
7 how automation could amplify harm;
8 how rollback could fail;
9 how affected persons could be excluded;
10 how the system could resist correction.
64. Public Challenge Process
The responsible authority shall establish a process through which affected persons, civil society, journalists, public servants, auditors, experts, Indigenous governments, and other public bodies may submit evidence of system failure, auditability gaps, appeal gaps, data errors, or automation risks.
Part 15 — Security, Confidentiality, and Bounded Accountability
65. Protected Information
Nothing in this Act requires public disclosure of information where disclosure would create a serious and demonstrable risk to national security, cybersecurity, privacy, law enforcement, personal safety, or lawful confidentiality.
66. Bounded Accountability
Where information cannot be made public, the responsible authority shall provide:
1 a public summary at the highest safe level of abstraction;
2 a restricted record for authorized reviewers;
3 audit access sufficient to verify legality, accountability, and compliance;
4 written reasons for withholding public disclosure.
67. No Secrecy Without Review
Confidentiality shall not eliminate the requirement for authorized audit, legal review, oversight, and accountability.
Part 16 — Compliance, Orders, and Remedies
68. Compliance Orders
An authorized oversight body may issue a compliance order requiring a responsible authority to:
1 prepare or update a system map;
2 complete a systems integrity review;
3 publish a citizen-readable summary;
4 correct a data-flow map;
5 establish meaningful human review;
6 repair an appeal gap;
7 preserve audit trails;
8 suspend unsafe automation;
9 review vendor contracts;
10 prepare a rollback plan;
11 report on repair progress.
69. Systemic Correction Orders
Where recurring system failure is identified, an oversight body may order the responsible authority to prepare a systemic correction plan.
70. Individual Remedy
Where an affected person suffers material harm due to a failure to provide reasons, meaningful review, data correction, appeal, auditability, or lawful process required by this Act, the affected person may seek remedy through the applicable review, appeal, tribunal, court, ombuds, or oversight process.
71. Protection Against Retaliation
No person shall suffer retaliation for reporting a systems integrity failure, auditability gap, data error, unsafe automation, unlawful authority, or serious public-system risk in good faith.
Part 17 — Regulations
72. Regulations
The Governor in Council may make regulations:
1 prescribing high-impact public systems;
2 prescribing critical public systems;
3 establishing systems integrity review standards;
4 establishing automation readiness criteria;
5 establishing dashboard indicators;
6 prescribing audit-trail retention periods;
7 prescribing vendor contract requirements;
8 prescribing public reporting formats;
9 prescribing citizen-readable summary requirements;
10 establishing review schedules;
11 exempting systems where equivalent or stronger protections exist;
12 establishing phased implementation timelines.
73. No Regulation May Defeat Purpose
No regulation made under this Act shall defeat the purpose of ensuring lawful, mapped, auditable, appealable, reversible, citizen-legible, and democratically correctable public systems.
Part 18 — Statutory Review, Sunset, and Coming into Force
74. Statutory Review
A committee of Parliament shall review this Act within three years after coming into force and every five years thereafter.
The review shall examine:
1 whether the Act improves public-system visibility;
2 whether it reduces auditability gaps;
3 whether it improves appeal and redress;
4 whether it prevents unsafe automation;
5 whether it creates unnecessary bureaucracy;
6 whether it supports lawful modernization;
7 whether amendments are required.
75. Pilot Phase
This Act shall be implemented through a pilot phase applying first to prescribed high-impact systems, including:
1 public-sector AI or automated decision systems;
2 digital identity or data-sharing systems;
3 housing approval and delivery systems;
4 infrastructure approval systems;
5 emergency powers or crisis-governance systems;
6 public benefits or eligibility systems;
7 procurement systems involving high-impact digital or AI vendors.
76. Coming into Force
This Act comes into force on a day fixed by order of the Governor in Council.
Different provisions may come into force on different days.
Schedule A — NSIR Systems Integrity Review Template
A systems integrity review shall include:
1 system name;
2 responsible authority;
3 public purpose;
4 legal authority;
5 affected population;
6 system boundary;
7 system map;
8 authority map;
9 data-flow map;
10 decision pathway map;
11 AI and automation exposure;
12 vendor dependency review;
13 appeal and redress review;
14 auditability review;
15 reversibility review;
16 failure-mode register;
17 evidence classification;
18 automation readiness rating;
19 repair sequence;
20 citizen-readable summary.
Schedule B — Automation Readiness Gate
A high-impact public system may not be automated unless the responsible authority demonstrates that:
1 the system has a clear public purpose;
2 authority is lawful and bounded;
3 the system is mapped;
4 data flows are mapped;
5 affected persons can receive reasons;
6 meaningful human review exists;
7 appeal or remedy exists;
8 audit trails are preserved;
9 vendors are auditable and exit-capable;
10 errors can be corrected;
11 harms can be reversed where possible;
12 system failure modes are identified;
13 rollback mechanisms exist;
14 citizen-readable summaries are published;
15 the system has been classified as Ready or Limited Ready.
Schedule C — Citizen-Readable System Summary
A citizen-readable system summary shall answer:
1 What does this system do?
2 Who is responsible for it?
3 Who can be affected by it?
4 What law authorizes it?
5 What data does it use?
6 Does it use AI or automation?
7 What decisions does it make or support?
8 How can I get reasons?
9 How can I ask for human review?
10 How can I correct wrong data?
11 How can I appeal?
12 How is the system audited?
13 What happens if the system fails?
14 Can the system be paused, corrected, or rolled back?
Schedule D — Failure Mode Register
A failure-mode register shall identify:
1 failure mode;
2 affected population;
3 triggering condition;
4 likely harm;
5 severity;
6 probability;
7 detectability;
8 responsible authority;
9 existing control;
10 missing control;
11 repair action;
12 deadline;
13 status;
14 review date.
Schedule E — Vendor Integrity Requirements
A vendor supporting a high-impact public system shall provide:
1 documentation sufficient for audit;
2 access to relevant logs;
3 security testing cooperation;
4 incident reporting;
5 data portability support;
6 decommissioning support;
7 subcontractor disclosure;
8 change notification;
9 support for human review;
10 support for audit trails;
11 compliance with public records law;
12 exit transition assistance.
Final Standard
The Public Systems Integrity Act exists to make public systems visible before they become faster.
It does not prevent modernization.
It prevents blind acceleration.
It does not require perfect systems.
It requires correctable systems.
A public system should not be automated until it can be mapped.
It should not be scaled until it can be audited.
It should not be trusted until it can explain itself.
It should not govern citizens unless citizens can challenge it.
The standard is simple:
Do not automate what you have not mapped.
Project Page: AI Does Not Fix Government. It Amplifies It (Part 1) https://x.com/SkillsGapTrain/status/2065348053645861271
Disclaimer: This is an open-source educational system that is being developed for learning, research, frontier systems engineering and prototyping, intended to help students, teachers, public-sector builders, policy analysts, political leaders, corporate leaders and responsible organizations explore next-generation governance systems for humanity; it is not legal advice, policy authority, certification, or deployment-ready public infrastructure. Executive Summary of Audit of current development status is located at bottom of Part 3 of Project Page.