The Human-Origin Certification Spec

An open, versioned specification for establishing and verifying that a creative work was made by a human. It defines what evidence is reviewed, how a certificate is cryptographically constructed, how the proof is bound to the file, and how anyone can verify it independently, without trusting TraceHumanity’s servers.

Version
0.1 (Draft)
Updated
26 June 2026
Status
Open for comment

1Purpose & scope

This specification describes a method to make an affirmative, verifiable claim of human authorship for a digital creative work. It is deliberately the inverse of AI-detection: it does not estimate the probability that content is AI-generated. It establishes, from reviewed evidence, that a specific work was created by a human, and produces a tamper-evident record of that determination.

It applies to digital media (images, illustration, photography and other creative files) and to physical works represented by a digital surrogate, for example a high-resolution scan.

2Definitions

Work
The creative artifact being certified, identified by the SHA-256 hash of its original file.
Creator
The human author claiming authorship.
Evidence
Materials supporting human authorship (see §4).
Issuer
An authority holding a registered signing key, authorized to issue certificates.
Certificate
A signed attestation binding a work, creator, level, and time.
Verifier
Any party checking a certificate; needs only the public registry and standard cryptography.

3Certification levels

Levels reflect the strength of the evidence reviewed. Level 1 is a self-declaration and is labelled as such: it is declared, not certified.

L1, Self-declared
Signed declaration of authorship; no review.
L2, Evidence reviewed
RAW files, edit histories, or progress documentation reviewed by a person.
L3, Device verified
Device-signed C2PA capture plus supporting evidence, with certificate-chain verification.
L4, Live verified
Real-time capture session with challenge codes; two reviewers.
L5, Institutional
Organization-level certification under governed workflow controls and audits.

4Evidence & review

Evidence is weighted and scored across independent pillars: identity trust, evidence completeness, consistency, provenance, forensic flags, and chain integrity. A work must meet the threshold for its requested level. Higher-trust evidence (RAW originals, layered project files, C2PA capture, live sessions) outweighs weaker signals (a screenshot, EXIF alone). Human review is mandatory at L2 and above.

5Certificate format

A certificate is signed with ECDSA P-256 over SHA-256. The signed payload is the following fields joined with the literal | character:

{certificateNumber}|{assetHash}|{level}|{ownerId}|{issuedAt}
certificateNumber
For example TH-2026-001002
assetHash
SHA-256 of the original (pre-watermark) file, lowercase hex
level
For example LEVEL_3
ownerId
The creator’s stable identifier
issuedAt
ISO-8601, canonicalized via new Date(x).toISOString() (millisecond UTC)

The signature is hex-encoded DER. Canonicalizing issuedAt on both sign and verify is required for byte-stable verification.

6File binding: watermark, C2PA, fingerprint

Three complementary bindings tie the certificate to the actual file so the proof survives real-world handling:

  • Neural watermark (soft binding). A TrustMark watermark embeds a wm_id of 16 hexadecimal characters (8 bytes, each ≤ 0x7F for the encoder’s 7-bit-per-character limit). It survives re-compression and re-sharing and maps back to the certificate even when metadata is stripped.
  • C2PA manifest (hard + soft binding). An ECDSA-signed manifest binds the file hash (hard) and the wm_id (soft).
  • Perceptual fingerprint. A pHash supports near-duplicate matching when a file has been altered.

7Trust registry

Every issuer’s public key is published in a public trust registry. Verification depends only on these keys, not on any private API. Human-readable at /trust-registry; machine-readable at /api/trust-registry.

8How to verify

Two independent paths, both usable by third parties:

  1. By certificate. Reconstruct the §5 payload, then verify the DER signature against the issuer’s public key from the registry. No TraceHumanity dependency is required.
  2. By file. Detect the watermark to recover the wm_id, resolve it to a certificate, and verify as above. A reference verifier is at /verify, and a programmatic API is documented at /api/v1/docs.

9Revocation

A certificate may be revoked (for example, on a substantiated authorship dispute). Revocation is recorded against the certificate with a reason and timestamp, and the public verification result reflects the revoked state. Historic signing keys remain published so prior signatures stay independently checkable.

10Governance & stewardship

This specification is published openly and versioned; its changelog is below. TraceHumanity is its initial steward. The certificate, registry, and verification formats are designed to support federated issuers: institutions (studios, galleries, guilds) issuing under their own registered keys within the same trust framework, so the standard is not tied to a single operator. Comments and proposed changes are welcome. Send them via our contact form.

11Changelog

0.1
26 June 2026. Initial public draft: levels, certificate format, file binding, registry, verification, revocation.
Certify under this specVerify a certificate