Data Rights & Evidence Portability
Your evidence.Your control.
Last updated: February 2026
Portable evidenceCustomer-controlledGDPR-alignedNo vendor lock-in
Good Proof is designed so verification artefacts remain usable outside our UI. Portability reduces vendor lock-in risk and supports independent audit, procurement, and counterparty review. This page explains what you can export, how portability works, and how to make data rights requests where applicable.
Data roles (controller vs processor)
Website & sales interactions
Mind Chill is the controller for personal data submitted via our website (for example, sprint bookings, contact requests, and sales/support emails).
Customer programme usage
Where a customer uses Good Proof within their workflows, we typically act as a processor and the customer is the controller for the underlying personal data, unless otherwise stated in the contract.
What this page covers
This page covers two things:
Evidence portability
How Good Proof Stamps and Evidence Packs can be exported and reused across systems without vendor lock-in.
Data rights
How to request access, deletion, correction, restriction, objection, or portability of personal data where applicable.
Good Proof is scope-bound, expiry-aware, and human-final when it matters. It is not a certification.
Evidence portability (no vendor lock-in)
Good Proof outputs are designed to be contract-referenceable and system-portable. A buyer, auditor, regulator, or counterparty can review the artefact without needing privileged access to our internal tools.
Stable specs
Published specs for what a Stamp is and how it is verified
Consistent naming
Consistent field naming across artefacts and API outputs
Status lifecycle
A status lifecycle that communicates validity over time
Exportable bundles
Exportable evidence bundles for your own system of record
What you can export
Depending on the product and programme scope, you can export:
Good Proof Stamp
A contract-referenceable verification artefact that identifies the action scope, what was verified, when it was verified, and the verification authority.
Status Link
A counterparty-facing status surface showing the current lifecycle state (e.g., VALID / NEEDS_REFRESH / WITHDRAWN / NOT_VERIFIED) for audit and operational checks.
IDA Evidence Pack
A human-readable and machine-readable evidence bundle containing the verification context, relevant attestations, and evidence references for review rooms.
Verify API response data
Machine-readable verification outputs for ingestion into GRC, CI/CD, ticketing, procurement workflows, and agentic automation.
export-formats.json
{
"stamp": "JSON + PDF",
"status_link": "URL + embed",
"evidence_pack": "JSON + PDF bundle",
"verify_api": "REST JSON response"
}
"stamp": "JSON + PDF",
"status_link": "URL + embed",
"evidence_pack": "JSON + PDF bundle",
"verify_api": "REST JSON response"
}
Status link visibility
Status links can be configured for public counterparty verification or restricted sharing depending on programme requirements. We aim to keep status surfaces minimal and focused on verification state, not raw payload disclosure.
Formats and specs
Portability works when formats are stable. Exports are provided in human-readable and machine-readable forms. Use these canonical references:
Stamp Spec
Canonical stamp field definitions
Verify API
Machine-readable verification endpoint
IDA Evidence Pack
Human + machine evidence bundle
Specimens
Example artefacts for review
If a buyer requires a procurement-ready export format mapping for your internal systems, book a Stamp Sprint.
Customer control and system of record
In enterprise deployments, the customer is typically the system of record for regulated workflows. Good Proof generates verification artefacts and status lifecycles that can be stored alongside your:
Tickets or cases
Contracts or third-party risk files
Model logs or agent run records
Change approvals and exception approvals
You can mirror exported artefacts into your own storage for retention, governance, and independent review.
Data governance & rights
Integrity rule: we do not rewrite issued Stamps
Good Proof Stamps are integrity artefacts. We do not retroactively edit issued Stamps. If something must change, we use status lifecycle governance rather than rewriting history:
VALIDthe stamp is current and acceptable within scope
NEEDS_REFRESHthe stamp is still visible but no longer current due to expiry or scope refresh requirements
WITHDRAWNthe stamp has been withdrawn due to verified issues or programme action
NOT_VERIFIEDthe claim did not meet verification requirements or cannot be validated
Buyers and automated systems should treat anything other than VALID as fail-closed unless an explicit exception lane has been approved.
Need a custom export or portability mapping?
Every Stamp Sprint includes export configuration scoped to your system of record.