AI & MODEL GOVERNANCE

AI & Model Governance Notice

How RTH governs third-party AI, local models, agents, and the planned RTH-owned LLM—from training-data provenance and evaluation to human review, monitoring, rollback, and retirement.

Effective: September 9, 2026  ·  Last reviewed: September 9, 2026  ·  Architecture: RTH Governance 2.0

Status: Current governance standard for applicable RTH public operations. Product-specific controls apply when the relevant product or program is enabled.

1. Purpose

RTH uses this notice to explain how AI and model governance will work across SuperstarIQ, RTH research and evidence workflows, content development, and future RTH-owned model development. RTH plans to develop proprietary large-language-model capability; that model will be subject to the same or stronger controls applied to outside models.

2. AI is a governed component, not an authority

RTH may use deterministic software, retrieval, rules, local models, third-party models, agents, and future RTH-owned models. The system may assist with organization, summarization, reflection, evidence handling, drafting, education, and bounded automation. AI is not permitted to impersonate a clinician, attorney, emergency responder, school evaluator, or other licensed professional.

3. Separate product processing from model training

Retrieval of a user's own information, temporary context sent to a model for a requested answer, personalization, and product memory are forms of product processing; they are not automatically model training. RTH will maintain separate controls and records for model inference, evaluation, fine-tuning, pretraining, retrieval indexes, and research datasets.

4. Training-data provenance

Every dataset approved for an RTH-owned model must have a dataset record describing origin, collection method, ownership or license, permitted purpose, restrictions, sensitive-data status, de-identification status, geographic or population limitations, quality checks, poisoning review, retention, and responsible approver. Publicly accessible information is not automatically approved for training merely because it can be viewed online.

5. Prohibited or restricted training data

  • data obtained without rights sufficient for the intended model use;
  • secrets, credentials, private keys, or unlawfully obtained data;
  • identifiable minor/student data for general-purpose model training;
  • identifiable health data for general-purpose model training without a separately approved, expressly authorized program;
  • connected-source data whose provider terms prohibit model training or evaluation;
  • confidential partner, litigation, settlement, employment, or proprietary records without documented authority;
  • research data outside the scope of the research consent, protocol, or data-use agreement.

6. Preferred training sources

RTH should preferentially use RTH-owned materials for which training rights are clear, properly licensed/open datasets compatible with the intended use, synthetic data with traceable generation provenance, curated public-domain material, and separately consented research/model-development datasets that have passed governance review.

7. Third-party model baseline

Outside model providers must be reviewed for confidentiality, retention, provider training, security, geographic processing, subprocessor use, deletion, incident notification, and contractual restrictions. Sensitive health workflows target zero-training and minimum-retention or zero-retention configurations. RTH will not assume consumer-facing AI terms are adequate for sensitive product data.

8. RTH-owned LLM development lifecycle

  1. define intended use, prohibited use, user population, and risk tier;
  2. approve training/evaluation datasets and source rights;
  3. document architecture, base model or components, licenses, dependencies, and compute environment;
  4. train or fine-tune with reproducible configuration and immutable run records;
  5. test privacy, memorization, bias, poisoning, prompt-injection, hallucination, cybersecurity, clinical/youth safety, and other relevant failure modes;
  6. run RTH domain benchmarks and independent/adversarial review appropriate to risk;
  7. prepare a model card and release decision record;
  8. deploy with monitoring, rate/permission limits, human-review gates, rollback, and incident response;
  9. re-evaluate material updates and retire models that no longer meet requirements.

9. Evaluation data separation

Training and evaluation datasets should be separated to avoid inflated performance claims. Benchmark cases, safety cases, and withheld validation sets must be protected against contamination where practical. Material benchmark leakage is a release-quality issue that requires remediation or disclosure.

10. Human review and prohibited autonomous actions

RTH does not authorize autonomous diagnosis, medication changes, return-to-play clearance, serious cardiac/implanted-device interpretation, emergency-care delay, unsupported legal deadlines, high-impact decisions about minors, or claims of clinical validation not supported by evidence. High-risk workflows must include human review or be disabled.

11. Agents and tool use

An AI model does not receive tool permissions simply because it can generate text. Agents must use least privilege, explicit tool allowlists, scoped credentials, confirmation for consequential actions, logging, budget/rate limits, and protections against prompt injection, indirect instructions, data exfiltration, and excessive agency.

12. Model cards and transparency

Before an RTH-owned model is used externally, RTH will maintain a model card or equivalent release record describing intended use, known limitations, evaluation scope, data-source categories, safety controls, version, significant changes, and prohibited uses. Public transparency may summarize those items without disclosing trade secrets or security-sensitive implementation details.

13. User feedback, incidents, and rollback

Material safety reports, privacy failures, unexpected memorization, evaluation regressions, security defects, or harmful outputs can trigger restricted routing, feature suspension, rollback, retraining, additional human review, or model retirement. RTH will retain enough release evidence to identify the model, prompt/configuration, data source, route, and relevant review history.

14. Intellectual property and open-source supply chain

RTH will review model, dataset, code, and weight licenses before use or release. Open-source or open-weight availability does not eliminate license, privacy, cybersecurity, export, safety, or attribution obligations. Model dependencies and provenance form part of the software and AI supply chain.

15. Youth baseline

General-purpose personalized conversational AI that processes personal or sensitive context is adult-first. RTH will not launch a personalized minor-facing AI mode unless a separate youth design passes privacy, safeguarding, parental/authorized-adult, educational, bias, safety, and evaluation review.

16. Research and improvement choices

RTH will distinguish ordinary service operation from optional research and model-development participation. Where consent is the appropriate basis, declining model-training or research participation should not remove access to unrelated core service functionality unless the research feature itself cannot operate without that data.

Privacy and data requests: privacy@restartingtheheart.com. Do not send medical records, passwords, authentication codes, government identifiers, or other unnecessary sensitive information by ordinary email.

Security reports: security@restartingtheheart.com. See the Vulnerability Disclosure Policy before performing security testing.

General questions may use the RTH contact page.