For Programme Operators
A foundation handing over grantee data will ask how it is handled before it signs anything. This page answers that for an institutional reader, including the parts where the honest answer is that a control is not built yet.
Pursuing DFSA Innovation Testing Licence · DIFC, Dubai
The Data
Three sources, three different visibility rules. The rule that matters most: raw grantee evidence does not flow to the programme by default, because the programme asked for a finding, not a document dump.
Who can see it: Visible to programme staff you authorise, to FounderGrade operations staff on a need basis, and to the assigned verifier only in the reduced form needed to run the check.
Who can see it: Visible to the assigned verifier and to the grantee. Released to the programme in the form the milestone definition agreed, which is usually the finding and the reasons rather than the raw material.
Who can see it: Visible to the programme and the verified party. Published only where the programme chooses to publish.
Controls
Each control states what we commit to operate, then states honestly what exists today. Nothing here is presented as certified or audited.
Role-scoped access with least privilege, per programme and per engagement. Programme staff see their own programme only. Verifiers see only the engagements assigned to them.
Current status: Role model implemented in the prototype. Enforcement moves server side at launch.
Grantee evidence is never published, never anchored to a public record and never shared with other programmes. Only a cryptographic digest of the written reasons is ever made public.
Current status: Designed and documented. No production storage exists yet.
Evidence is retained for the engagement plus 24 months, then deleted. Findings and audit entries are retained permanently because a verification record that can be deleted is not a record. Personal data inside evidence is deleted on request where no legal retention obligation applies.
Current status: Policy set. Automated retention jobs are a launch deliverable.
Programmes export every finding, reason, audit entry and milestone mapping as structured data at any time, including on exit. Grantees export their own findings. Export is not gated behind a plan tier or a notice period.
Current status: Export implemented in the console as an illustrative preview only.
A public sub-processor list with the purpose and region of each, and 30 days notice before a new one is added, so a programme can object before it takes effect.
Current status: The list will be published at launch. No sub-processor is engaged today because no data is processed.
Every action on a verification record writes an immutable entry: who requested evidence, who submitted it, who verified, what the finding was, who appealed and what changed. Programmes read their own trail directly and export it.
Current status: Visible in the programme console today against illustrative sample records.
A verifier needs enough grantee material to reach a finding, and no more. The programme needs enough of the finding to make a release decision, and no more. Neither of those is served by moving every document to every party, so we do not.
Blind Review and Conflicts
These rules are part of the published verification standard, restated here because a programme will ask about them during procurement rather than during onboarding.
A calibrated expert drawn from the verification pool, matched by sector and by the milestone type under review. Verifiers are named to the programme and to the grantee, and their calibration status is on the record.
A verifier is disqualified where they hold or have held equity, tokens, debt or an advisory position in the grantee, have worked for or with the grantee inside the last 24 months, are related to a founder or officer, or have an open commercial discussion with the grantee.
A verifier is disqualified where they sit on the programme's selection committee, council or board, where they authored the grant application, or where their compensation varies with the outcome of the finding. Verifier pay is fixed by tier and is identical whatever the finding is.
Assessment review is blind to grantee identity where the evidence permits it. Milestone verification frequently cannot be blind, because confirming a deployment or a counterparty requires identity. Where blindness is not possible we say so on the finding rather than pretend otherwise.
Every verifier signs a conflict declaration per engagement. Any conflict discovered mid-engagement triggers immediate recusal, the finding is voided and the milestone is reassigned at our cost.
Attestation-based record keeping is an established pattern in grant tooling, so programme operators reasonably ask how a verification is anchored. Here is exactly what is recorded, what is public, what never leaves the platform, and how a third party checks a finding without asking us.
| What Is Recorded | Where It Lives | Who Can See It | Detail |
|---|---|---|---|
| That a verification engagement was opened | Anchored | Public | A milestone identifier, the programme identifier and a timestamp. No evidence and no narrative. |
| The finding: Corroborated, Contradicted or Unable To Verify | Anchored | Public | The outcome, the standard version applied, the verifier tier and a timestamp. |
| A cryptographic digest of the written reasons | Anchored | Public | A hash only. Anyone holding the reasons document can confirm it is the one that was recorded, and nobody can read it from the hash. |
| The written reasons themselves | Off Chain | Programme and Parties | Held in the platform record, released to the programme and the verified party, and exportable by both. |
| The evidence the grantee submitted | Off Chain | Parties Only | Never anchored, never published. Confidential material stays confidential by design, not by policy alone. |
| Verifier identity | Off Chain | Programme and Parties | Disclosed to the programme and the grantee for conflict checking. The public record carries the tier and calibration status, not a name. |
| Appeals and overturned findings | Anchored | Public | An overturn is recorded as a new entry referencing the original. Nothing is deleted or rewritten. |
That a verification engagement was opened
Anchored · Public
A milestone identifier, the programme identifier and a timestamp. No evidence and no narrative.
The finding: Corroborated, Contradicted or Unable To Verify
Anchored · Public
The outcome, the standard version applied, the verifier tier and a timestamp.
A cryptographic digest of the written reasons
Anchored · Public
A hash only. Anyone holding the reasons document can confirm it is the one that was recorded, and nobody can read it from the hash.
The written reasons themselves
Off Chain · Programme and Parties
Held in the platform record, released to the programme and the verified party, and exportable by both.
The evidence the grantee submitted
Off Chain · Parties Only
Never anchored, never published. Confidential material stays confidential by design, not by policy alone.
Verifier identity
Off Chain · Programme and Parties
Disclosed to the programme and the grantee for conflict checking. The public record carries the tier and calibration status, not a name.
Appeals and overturned findings
Anchored · Public
An overturn is recorded as a new entry referencing the original. Nothing is deleted or rewritten.
The rules a finding is produced under are published in the verification standard, and the division of labour between tooling and people is published in the methodology.
Procurement questions, a security questionnaire or a data processing agreement draft go to security@foundergrade.ai. See also the privacy policy, terms and trust and security.
For Programmes
Every commitment on this page applies to a pilot from the day the scope is signed.
Pursuing DFSA Innovation Testing Licence · DIFC, Dubai
