Where the data lives, who can touch it, and how its provenance is locked.

This page states what happens to research data when it arrives, who can reach it, and how it is destroyed when a study ends. It also distinguishes personal operating practices from institutional controls that do not yet exist.

1. Where the data lives

Research data is stored on a single local machine. It is encrypted at rest — full-disk encryption on the device that holds it. It is not synced to any cloud service. There is no Dropbox, Google Drive, iCloud, or comparable background sync touching the data directories; the working folders are deliberately kept out of any sync path. Datasets governed by a Data Use Agreement or a restricted-access license stay on that one machine and are not copied to shared drives, personal cloud storage, or collaborator devices.

Backups, where a license permits them, are made to local encrypted media held under the same single-researcher control — never to a third-party cloud backup service.

2. Restricted patient data never enters an AI or chat context

Restricted patient-level data does not enter a chat window, an LLM prompt, or any AI model context. AI tools may assist with code and method using public documentation, synthetic fixtures, and disclosure-safe outputs only when the dataset’s governing terms permit that use. No individual record, identifier, row, private traceback, or private diagnostic is pasted into, uploaded to, or transmitted through an external service.

The terms govern the aggregate boundary too. PRO-ACT’s current access agreement prohibits public AI tools and code assistants from processing, analyzing, or interacting with its dataset. Accordingly, every PRO-ACT data-touching step is researcher-executed. AI assistance is limited to public documentation and code, one-way hashes, and disclosure-safe aggregate artifacts that have crossed the study’s fixed output boundary — never the dataset, private mappings, diagnostics, or logs. Other restricted cohorts are handled according to their own agreements rather than assumed to share one rule.

3. Who can access it

Access is held by one person — the sole researcher running this mission. No collaborators, contractors, or services currently hold credentials to the protected datasets. There is no shared account and no team with standing access. When that changes — as the work grows toward collaborators and a governing board — this page will be updated to describe the access controls that come with it.

4. Retention and destruction

Data is retained only as long as the active study and any required reproducibility window need it — and never longer than the governing agreement or license permits. Each restricted dataset is tracked to the terms it arrived under, including any retention limit or end-of-project destruction clause.

When the authorized retention or reproducibility period ends — or earlier when an agreement requires it — the raw data is destroyed: the encrypted source files and any local working copies and intermediate caches derived from the protected records are deleted, and encrypted backup media are wiped. What is kept afterward is the analysis code and the aggregate results — not the underlying patient-level data. If an agreement specifies a particular destruction method or requires written confirmation of destruction, that requirement is followed and recorded.

5. Abiding by each repository’s terms

Every dataset is used strictly within the terms it is released under. That includes:

• Non-commercial and share-alike licenses (for example CC BY-NC-SA): the work is non-commercial, attribution is preserved, and derived material is handled consistent with the license.
• Data Use Agreements (DUAs) for restricted clinical repositories: access scope, permitted uses, redistribution limits, and retention/destruction clauses are all honored as written.
• Non-commercial intent overall: this is a research mission, not a product. There is no sale, no commercial redistribution of source data, and no use outside the stated research purpose.

If a repository’s terms conflict with anything described on this page, the repository’s terms govern.

6. Human-subjects & ethics oversight

Technical safeguards are only part of a data-access review. This mission is currently run by an independent solo researcher without an institutional IRB of record. No university or hospital review board oversees the work by default.

What that means in practice:

• Strict operation under each program’s terms. Every dataset is used only within its governing Data Use Agreement, license, and access terms — the same commitment made in the section above, applied here to the ethics conditions a program attaches to access.
• Deference to required review. Where a program or dataset requires IRB review, a determination, or a documented exemption as a condition of access, that requirement is honored before the data is used. If access is contingent on an IRB pathway, an institutional or independent-IRB review will be arranged to satisfy it — rather than seeking a workaround.
• Accurate classification of the work. Public, de-identified secondary datasets — for example NHANES, HRS, and public DMS (deep mutational scanning) atlases — are handled according to the applicable program terms and research definitions. I do not claim a formal IRB determination or exemption where none has been granted. Restricted patient-level cohorts are handled under their own governing approvals, agreements, and any review their custodian requires.
• Protections that apply regardless of institutional status. There are no attempts to re-identify individuals in any dataset; data collection and retention are limited to what an analysis needs; and the local-only, never-in-an-LLM-context handling described elsewhere on this page is treated as a human-subjects protection, not only as a security measure.

Independent practice cannot substitute for institutional review. I do not assert an IRB approval, determination, or exemption that has not been granted. Wherever a data custodian requires its own review process, that process governs.

7. Provenance and reproducibility

A reported number is only trustworthy if it can be traced back to its source. Every current Research-page analysis is built so that the chain from input to reported figure is auditable:

• sha256-locked inputs. Each source dataset is fingerprinted with a sha256 hash, so the exact bytes an analysis ran against are pinned and any later change to the input is detectable.
• Script-generated numbers. The figures in the research write-ups are produced by code, not typed in by hand. Each reported value is emitted by a script and bound to the page through a managed figures manifest, so a number on the site and the number a script produced cannot silently drift apart.
• An audit chain. Locked input → analysis code → generated result → the value shown on the page. An authorized researcher with lawful access to the exact hash-matched inputs and code can reproduce the aggregate results without redistributing the underlying records. A hash identifies those bytes; it does not replace access to them.

Where this stands today

These controls are currently operated by a solo researcher, without separation of duties or formal institutional audit. They are in force, but they depend on my own compliance. I am building toward a governance structure with a board and named collaborators. As that develops, the access, oversight, and destruction processes will be tightened and this page will be revised to match.

Clinicians, data-access reviewers, and prospective collaborators are welcome to write to michael@rightfidelity.ai or review the ways to get involved → — Michael