How DfG works
A plain-language guide to governed data access
The problem we're solving
Health data is valuable for research. But accessing it today means months of paperwork, opaque approval processes, and no way for a citizen to know what happened to their data once they said yes.
DfG changes that. We put governance on the record — consent grants, access decisions, analysis runs, revocations — so that every party can see exactly what occurred, why it was permitted, and what the outcome was.
What consent means here
When a citizen grants permission, it is recorded as an evidence event with a receipt. The grant specifies exactly who may use the data, for what purpose, and which data types are covered.
Consent can be withdrawn at any time. Revocation is a new event — the original grant is preserved in the audit trail so there is always a complete record. After revocation, no new research access is permitted under that grant.
What researchers see
A credentialed researcher can ask: "how many people in my consented cohort meet these criteria?" They get a count. Not names. Not records. Not a list of anyone.
When they run an analysis, they receive an aggregate result — a mean, a distribution, a comparison between groups — along with a consent receipt that links the output to the specific consent state that authorised it.
If the cohort is too small to protect individual privacy, the result is suppressed entirely.
What this sandbox is
This is a Wave-1 environment. It uses no real personal data — all records are generated and unrelated to any living person. The governance logic, consent flows, and evidence trail are real; the analytics compute runs behind a stable service boundary that will be backed by confidential compute infrastructure in later waves.
The seams — the five interfaces between DfG and its compute layer — are live and documented. Swapping in real infrastructure is a one-line configuration change.