Core principle
HPS does not attempt to determine whether content “looks human.” Instead, it records explicit provenance claims, machine assistance, supporting evidence, signatures and responsibility in a structured, auditable form.
Asset integrity
Every registered digital asset SHOULD be identified using a cryptographic fingerprint. The current reference implementation uses SHA-256 to verify exact file identity. A change to the file changes the fingerprint and therefore represents a different exact digital asset.
Creator signature
A creator SHOULD sign their provenance declaration using a creator-controlled Ed25519 signing key. The signature establishes that the holder of that private key approved the exact canonical declaration.
Institutional issuance
Verified organizations MAY authorize institutional issuer keys. Authorized issuers can cryptographically sign institutional records, including certificates, official letters, research outputs and other documents.
Institutional records MAY be issued individually or in bulk. Each document MUST remain independently verifiable through its own asset fingerprint, institutional signature and HPS record.
Canonicalization
Cryptographically signed HPS objects SHOULD be canonicalized before signing. The reference implementation uses JSON Canonicalization Scheme style deterministic serialization so that signing and verification operate over the same structured representation.
Registry countersignature
The HPS Registry MAY verify a valid creator or institutional signature and countersign the accepted provenance record. The registry countersignature provides tamper evidence for the registered manifest.
Identity assurance
Cryptographic signatures and identity verification MUST remain separate trust signals. A valid signature proves control of a signing key; it does not automatically prove a person's civil identity or an organization's legal status.
HPS SHOULD explicitly expose identity assurance levels such as self-declared, account verified, identity verified, institutionally attested, institution verified and authorized issuer verified.
Supporting evidence
Provenance claims MAY reference supporting evidence such as drafts, source code, research notes, datasets, notebooks, sketches, screenshots, version history and other relevant material.
Evidence MAY be represented as public, hashed or sealed. Evidence-backed provenance means that supporting material exists and is linked to the claim; it does not mean that HPS independently proves every statement in that claim to be true.
Claims and verification
HPS MUST distinguish between what a creator or institution claims and what the system has actually verified.
For example, a creator may claim that a writing contribution was human. HPS may verify the creator signature, asset fingerprint and associated evidence fingerprints. Those checks do not by themselves prove that every sentence was personally written without machine assistance.
Attestations
Independent people or institutions MAY add attestations concerning authorship, process observation, supervision, editorial review, employment role, institutional affiliation, document validity or other relevant claims.
Attestations MUST remain distinguishable from the creator's or issuer's original provenance declaration.
Duplicate provenance
HPS SHOULD detect existing institutional registrations for the same exact asset fingerprint. An exact match from the same institution SHOULD normally be handled through versioning or supersession rather than silent duplicate issuance.
Where another institution has registered the same exact asset, HPS MAY require an explicit relationship such as co-issuer, co-signatory, attestor or endorser.
Institutional batches
Bulk institutional issuance MAY produce a signed batch provenance object in addition to the individual HPS records.
A batch record can identify the institution, authorized issuer, submitted documents, issued records, duplicates, failures and the cryptographic digest of the issuance event.
Batch integrity MUST NOT replace individual record verification. Each successfully issued document remains independently verifiable.
Revocation and status
HPS records SHOULD preserve provenance history even when a record is disputed, superseded or revoked. Revocation SHOULD change the status of the provenance record rather than silently erase its history.
Key custody
The reference implementation encrypts creator and institutional secret keys locally using PBKDF2-derived AES-GCM encryption. Production institutional deployments SHOULD consider stronger key-management options such as hardware-backed signing, managed key infrastructure or hardware security modules where appropriate.
Interoperability
HPS is designed to complement, rather than replace, other provenance and identity technologies. Implementations MAY map HPS records to systems such as C2PA Content Credentials and Verifiable Credentials while preserving HPS-specific contribution and responsibility semantics.
Responsibility
Every HPS record SHOULD make clear who accepted final responsibility for the registered provenance declaration or institutional issuance.