The Human-Origin Certification Spec

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 (e.g. a high-resolution scan).

• 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.

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.

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.

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 — e.g. TH-2026-001002
• assetHash — SHA-256 of the original (pre-watermark) file, lowercase hex
• level — e.g. 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.

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.

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.

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.

A certificate may be revoked (e.g. 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.

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; contact hello@guidedintelligence.com.au.

• 0.1 — 26 June 2026 — Initial public draft: levels, certificate format, file binding, registry, verification, revocation.