Certificate Policy

CertifiedData certification applies to synthetic datasets produced by a supported CertifiedData generation workflow, including pre-generated marketplace datasets produced by that workflow. For those datasets, the signed record can bind the dataset fingerprint, generation timestamp, generation metadata, schema version, and issuer identity.

A valid signature proves that the signed certification record was issued by CertifiedData and has not been altered. Matching the dataset SHA-256 fingerprint additionally proves that the relying party is checking the same dataset bytes represented by the record.

CertifiedData does not currently certify the origin, training history, quality, accuracy, safety, fairness, or legal status of external datasets, model artifacts, or AI outputs.

The AI Artifact Notary can accept an external artifact, compute its SHA-256 fingerprint, and issue an Ed25519-signed attestation record. The record proves the artifact fingerprint submitted to CertifiedData at the recorded time and protects the signed record against undetected modification.

A notary attestation does not claim that CertifiedData created the artifact, trained the model, produced the output, reviewed its contents, or verified any assertion about how it was generated. It is an integrity/existence attestation, not a certification of external-artifact provenance.

Some APIs and schemas use a certificate-shaped envelope for both record types. The envelope format does not expand the semantic claim: verification must be interpreted according to the issuance workflow and signed payload.

1. A supported CertifiedData generation workflow produces the synthetic dataset artifact.
2. SHA-256 fingerprints are computed for the certified artifact bytes.
3. The certification payload is populated with the supported generation and issuance facts.
4. The payload is canonicalized using the schema's declared canonicalization contract.
5. The canonical payload is signed with the active Ed25519 signing key.
6. The signed record is persisted and exposed through CertifiedData verification surfaces.

A CertifiedData record must not be interpreted as a differential-privacy guarantee merely because a request, schema, example, or metadata field contains an epsilon value or a DP-labelled generation mode.

CertifiedData will only claim a mathematical differential-privacy guarantee when the relevant generation workflow implements the required privacy mechanism, including gradient clipping, calibrated noise injection, and privacy accounting, and the issued record binds the applicable mechanism and parameters. This policy makes no such guarantee for workflows that do not meet those conditions.

Certification and notarization can provide evidence relevant to documentation, auditability, provenance, and integrity controls. They do not by themselves establish HIPAA de-identification, EU AI Act compliance, GDPR compliance, legal admissibility, or any other regulatory conclusion.

Whether a record supports a particular legal or governance requirement depends on the applicable rule, the system context, the signed facts, and the relying party's broader evidence set.

A cryptographic record remains verifiable when its signing key is retired but not revoked. Relying parties must check the record's current status and the status of its signing key at the time they rely on it.

Revocation changes the current reliance status; it does not rewrite the historical signed payload. Historical evidence remains immutable and should be interpreted together with the revocation record.

• Verify the signature against the trust root for the specific proof type.
• Recompute and compare the artifact fingerprint when the underlying artifact is available.
• Check current revocation/status information before relying on the record.
• Read the signed payload and issuance workflow to understand exactly what was attested.
• Do not infer quality, safety, fairness, privacy, or legal compliance from signature validity alone.

Questions about issuance scope, revocation, or this policy should be directed to [email protected].