AI & Data Governance Framework

1. Purpose and scope

This framework describes how The Heather Cutler Foundation governs the artificial intelligence systems and data behind its public, agent-facing services: the Canadian trials MCP server, the Port to Care application MCP server, the site-search MCP, and the knowledge MCP in design. It sits above the per-service governance documents, which remain the operative rules for each service:

• Trials MCP governance v0.1 (2026-11-01), with amendment v0.2 (approved 2026-11-01).
• Port to Care MCP governance v0.1 — a draft awaiting formal approval; it is referenced here for structure, and nothing in this framework presents it as adopted.

The framework aligns the foundation's controls with the six principles of the September 15, 2026 joint resolution of Canada's federal, provincial and territorial information and privacy commissioners and ombuds, "Responsible use of artificial intelligence in health and health research" (announced October 29, 2026). That resolution is regulator guidance, not a statute. Section 8 maps our controls to its principles as an alignment exercise; it is not a compliance certification, and the foundation will obtain Canadian privacy advice before representing any document as a statement of legal compliance. Applicable law includes PIPEDA and provincial health-information statutes such as Newfoundland and Labrador's PHIA.

2. Accountability

• Accountable officer: the Executive Director (Christopher Cutler) owns this framework and every per-service governance document. Amendments require his approval; every amendment changes the document's version and date.
• Board: the board of directors is the foundation's governing body; the framework and material changes to it are reported to the board.
• Service-level responsibility: every service has a named governance document, a release gate, and a kill switch. Disabling a service takes precedence over keeping it available.
• No delegated decisions: no system the foundation operates makes a decision about a person. Grant decisions are made by foundation staff; trial eligibility is determined by trial teams at screening. Systems collect, retrieve, label, and route — nothing more.

3. Design rules that carry the governance

Governance in these services is enforced by construction, not by instructions to a model:

• Non-generative serving. The trials, Port to Care, and planned knowledge servers contain no language model. Tools execute database queries or validate structured fields and return records or fixed, foundation-authored strings. No code path generates free text.
• No field, no collection. Service inputs are constrained to fixed lists and registry values. The trials and knowledge services have no parameter that accepts personal health information, so it cannot be collected or stored.
• Separation. Each service is a separate Worker with a separate data store. The applications store and the trials mirror share no tables, no secrets, and no code path.
• Provenance on every record. Trial records carry the NCT number, the ClinicalTrials.gov source URL, the registry's last-updated date, and the foundation's last-synced date. Knowledge records carry source URLs, source date, retrieved date, verification status, and verified date.
• Honest emptiness. A query with no matching records returns an empty result and one human contact. Results are never padded, silently broadened, or substituted.
• Labels travel. Verification status is part of the record and is served with it, in machine-readable form: verified, registry mirror, pending medical review, or pilot/test notices, as applicable.

4. Data classification

• Public. Published pages and guides (with their review status), the 2026 report and its data (CC BY 4.0), the ClinicalTrials.gov mirror Handling: May be served openly; attribution and status labels must travel with the content
• Internal. Drafts, governance working documents, test corpora and scorecards, operational records, the internal AI risk and privacy register Handling: Never published; access limited to the foundation
• Personal information. Port to Care application fields: applicant and patient names, contact email, optional phone, community and province, travel purpose and approximate dates, amount requested, consent and attestation records Handling: Collected for application processing only; access restricted to the Executive Director and staff accounts he designates; every staff view is for processing that application; audit-logged
• Not collected. Diagnosis details beyond the applicant's attestation, health card numbers, income information, medical records, the care-team confirmation document itself (it travels by the existing email route) Handling: Refused by construction: no field accepts them, and unknown fields submitted by a client are rejected, not stored

5. Consent

• No Port to Care submission is possible without two server-side facts: a recorded consent and the applicant's recorded confirmation of a plain-language summary of exactly what is being submitted. The gate is in the server, not in instructions to the applicant's assistant; a client that skips either step is refused.
• The consent text is fixed in the service's governance document, shown before submission, stored with a timestamp and the language used (English or French), and covers storage for processing, contact about the application, and the records the foundation's charitable reporting requires.
• Consent is specific to the application. It does not transfer between organizations or services, and it is never bundled with consent for any other purpose.
• Withdrawal is by email to support@heathercutler.ca and may end the application.

6. Retention principles

• Personal information is kept only as long as the purpose it was collected for, and the foundation's charitable and legal record-keeping obligations, require; it is then destroyed, except anonymized counts.
• Operational data with no continuing purpose (one-time status codes, rate-limit data) expires in days.
• Mirror and knowledge data are refreshed on a schedule, and staleness is disclosed on the record rather than hidden.
• Specific retention schedules are set in each service's governance document. The Port to Care schedule is currently a proposal inside a draft governance document and is not confirmed; this framework deliberately states the principle only.

7. Verification and human-review gates

• Verified is a human act. Information carries a verified label only after a person has checked it against its source. Nothing automated sets a verified flag, and no system edits a verified record; when a source changes, the affected information is checked again by a person before it is relied on.
• Model output is proposal-grade. Where a language model assists the foundation's work, everything it produces is treated as an unverified draft: it is checked before it is stored or used, it is never labelled verified, and it is never relied on until a person has confirmed it against the source.
• Measured before trusted. Before any model or prompt change is relied on, it is tested first and the result recorded. Changes that fail testing are not used.
• Release gates. No change to a public service ships while its checks fail. Those checks include honesty and misuse cases — a service must keep refusing what it is not for, including medical advice and eligibility decisions.
• Medical review is a separate, higher gate. Content is labelled "Pending medical review" until a qualified medical professional has actually reviewed it; a review is recorded only when one has happened, with reviewer metadata. Pending content is never served as reviewed.
• Scope discipline for knowledge content. What enters the foundation's governed knowledge base is decided deliberately, case by case. Expanding it requires the Executive Director's approval.

8. Alignment with the FPT joint resolution principles

Alignment, not certification — how the controls above correspond to each principle:

• Privacy protective. Data minimization by construction (no field, no collection); patient-side profiles for trial matching, so the foundation receives anonymous filter parameters only and holds no health-data custody; separate stores per service; consent and confirmation gates enforced server-side; confirmation emails carry no medical detail.
• Valid and reliable. Provenance on every record; verified and unverified labelling that travels with the data; human verification as the only path to verified status; testing recorded before any model change is relied on.
• Safe. Prohibited-content rules per service (no eligibility decisions, no medical advice, no approval predictions); testing as a release gate; kill switches; the incident rule that a suspected privacy incident stops the service first.
• Human rights affirming. People decide — grants, eligibility, and reviews are human acts; every automated channel names a human route and the email route to apply stays open alongside the application service; bilingual (English/French) service strings, reviewed as a pair; question design that always offers "not sure," so uncertainty is never scored as failure.
• Transparent. TEST BUILD and pilot notices served in responses; registry mirror vs. verified status visible in answers; this framework and the Responsible AI Policy published for approval as public documents; research records carrying structured attribution (publisher, title, section, date, source link, licence) so findings are never detached from their source.
• Accountable. A named accountable officer; versioned governance with approval gates; audit logs (sync runs with counts; application events by ID, event, and timestamp, with no free-text health content in the log); incidents recorded in the governing document with date and cause.

9. Incident and escalation principles

Stated at the level of detail appropriate for a public document; internal procedures are not published.

• A suspected privacy incident stops the affected service first, before any fix is attempted, and is reported to the Executive Director the same day.
• Records relevant to the incident are preserved; the audit log is the first source of truth.
• If an incident affects identifiable individuals, they are notified as applicable law requires, with the foundation's privacy obligations under PIPEDA and provincial law governing the response.
• Incidents — including a wrong listing presented as open, or an eligibility statement made in the wild — are recorded in the service's governance document as dated amendments with the cause, and the fix is verified against the release gate before the service returns.

10. What this framework does not do

• It does not authorize any new system. Each service, and each new use of a language model, requires its own governance or amendment and the Executive Director's explicit go-ahead, stage by stage.
• It does not cover the foundation's general Privacy Policy, Terms of Use, Medical Disclaimer, or editorial standards, which stand on their own and are linked, not duplicated, by the Trust Centre.