Skip to main content
Encypher Logo

Content provenance glossary

The words behind content labels, in plain English. Each term has a one-line answer, a fuller definition, and links to the pages that go deeper.

Written by the authors of the C2PA standard for textC2PA text-provenance standard: The part of the C2PA standard that puts a signed label inside plain text, using invisible Unicode characters..

A to Z

The basics

What a content label is, and the words people use for it.

  • Content provenance

    The record of where a piece of content came from and how it changed, carried with the content itself.

    Content provenance is a signed record of a piece of content's origin and edit history. It travels inside the file or the text, so a checker can read it without asking a separate database. The C2PA standard defines how the record is built and checked. A check either passes or fails: it shows who signed, what they declared, and whether the content changed since. It does not judge whether the content is true.

    A file holds a signed label in four layers: who signed it, what they declared including AI use, a fingerprint of the content, and a signature that seals them together.
    The label sits inside the file. It names the signer, carries what they declared, fingerprints the content, and is sealed by a signature.
  • Content Credentials

    The public name for a C2PA label, often shown as a small CR icon that opens who signed the content and what they declared.

    Content Credentials is the consumer-facing name for C2PA provenance. Apps that support it show an icon on an image or video; opening it shows the signer, the tools used, any AI declaration, and whether the file changed since signing. Under the icon is a standard C2PA manifest.

  • Content authenticity

    Being able to check who published content and that it has not changed since. It says nothing about whether the content is true.

    Content authenticity is the property that a piece of content can be checked against a signed record: who signed it, when, what they declared, and whether any bit changed since. A digital signature fails if the signed bytes change. Authenticity is about origin and integrity, not accuracy: a signed false claim is still false.

  • Metadata

    Data stored beside the content in a file, such as author, camera or date. Many tools strip it when they copy or upload a file.

    Metadata is descriptive data a file carries alongside its content: author, caption, camera settings, copyright notice. Formats such as EXIF, IPTC and XMP hold it. Plain metadata is not signed, so anyone can change it, and many upload and resize pipelines drop it. A C2PA manifest is signed metadata: a change to it, or to the content, shows up when it is checked.

  • Watermark

    A mark placed in the content itself, visible or hidden, so it can be found again after the file is copied.

    A watermark is a signal embedded in the content rather than stored beside it. Visible watermarks are logos or text on the image. Invisible watermarks hide a signal in pixels, audio samples or characters. Some are statistical and are read by a detector that returns a likelihood; cryptographic watermarks carry or point to a signed record that either checks or fails. In C2PA, a watermark can act as a soft binding that finds a label again.

The C2PA standard

The open standard behind content labels, and the groups that run it.

  • C2PA

    The Coalition for Content Provenance and Authenticity: the group that publishes the open standard for content labels.

    C2PA, the Coalition for Content Provenance and Authenticity, publishes the open technical specification for content provenance. It was founded in 2021 and operates under the Joint Development Foundation. The specification defines how a manifest is built (JUMBF boxes, CBOR data, COSE signatures), how it binds to a file, and how a checker validates it. C2PA publishes a standard and runs a conformance program; it does not sell a product.

  • C2PA 2.3

    The version of the C2PA specification, published January 8, 2026, that added the standard for unstructured text.

    C2PA 2.3, published on January 8, 2026, added Section A.7, the standard for embedding a manifest in unstructured text. Encypher authored that section. C2PA 2.4 carries it forward as Section A.8. The specification is free to read at spec.c2pa.org.

  • C2PA text-provenance standard

    The part of the C2PA standard that puts a signed label inside plain text, using invisible Unicode characters.

    The C2PA standard for unstructured text defines how a manifest is embedded in text that has no file container: articles, posts, chat replies. The manifest is encoded as invisible Unicode characters placed in the text, so it travels with the words when they are copied, unless an app strips the characters. It was published as Section A.7 in C2PA 2.3 on January 8, 2026 and carried forward as Section A.8 in C2PA 2.4. Encypher authored it.

    Readers see the sentence The pool opens Monday. After it, invisible Unicode characters (variation selectors, starting U+FEFF U+E0133 U+E0122 U+E0140) carry the signed label.
    The label rides in characters that draw nothing on screen, so the words look the same.
  • Unstructured text

    Text with no file around it, such as an article body, a post or a chat reply, so there is no container to hold a label.

    Unstructured text is text that moves as characters rather than as a file: copied from a web page, pasted into a post, returned by a chatbot. Images and PDFs have containers where a manifest can sit; plain text does not. The C2PA text-provenance standard solves this by encoding the manifest in invisible characters within the text itself.

  • CAWG

    The Creator Assertions Working Group, which defines how a label names the person or company behind content, beyond the signing tool.

    The Creator Assertions Working Group (CAWG), now part of the Decentralized Identity Foundation, publishes assertions that extend C2PA. Its identity assertion binds a named actor, such as a person or an organization with a verified credential, to the content, separately from the certificate of the tool that signed the manifest. CAWG also defines metadata and training-and-mining assertions.

  • Content Authenticity Initiative

    An Adobe-led group that promotes the C2PA standard and ships open tools for reading and showing Content Credentials.

    The Content Authenticity Initiative (CAI) is an industry community led by Adobe that promotes adoption of C2PA provenance. It provides open-source SDKs, a public inspection tool and education. C2PA writes the technical standard; CAI promotes its use. Membership in one does not require membership in the other.

  • C2PA Conformance Program

    The C2PA's test that checks a product builds and reads labels the way the standard says before it is listed as conforming.

    The C2PA Conformance Program tests generator products (which create manifests) and validator products (which check them) against the specification. A product that passes is listed on the Conforming Products List at an assurance level, and its signing certificates can be issued under the C2PA Trust List.

  • Conforming Products List

    The C2PA's public record of products that passed its conformance program.

    The Conforming Products List (CPL) is the C2PA's public record of products that passed the Conformance Program. Each record names the product, its role (generator or validator), its assurance level, the specification version tested and the media types covered. Anyone can check it in the C2PA Conformance Explorer.

  • IPTC

    The news-industry body that sets photo metadata fields and vocabularies, including the digital source type values C2PA uses.

    The International Press Telecommunications Council (IPTC) publishes the Photo Metadata Standard, the Video Metadata Hub and the NewsCodes vocabularies. Its digital source type vocabulary (for example trainedAlgorithmicMedia) is what C2PA uses to declare AI involvement. Plain IPTC fields are not signed; inside a C2PA manifest they are.

  • MIME type

    The standard name for a file format, such as image/jpeg or audio/wav, that software uses to decide how to read a file.

    A MIME type, or media type, is a registered label for a file format, written type/subtype: image/jpeg, video/mp4, application/pdf. C2PA lists the media types it supports and how a manifest is embedded in each. One format can have more than one accepted spelling, so a count of spellings is not a count of formats.

Inside a C2PA manifest

The parts of a label and how it ties to the file it describes.

  • C2PA manifest

    The signed label itself: a small package inside a file that records who signed it, what they declared and how to check it.

    A C2PA manifest is the signed record attached to a piece of content. It holds a set of assertions (statements about the content, such as actions taken, AI involvement and a hash of the content), one claim that lists those assertions by hash, and a claim signature made with the signer's X.509 certificate. In media files it sits in a JUMBF box; in text it is encoded as invisible characters. A checker needs no outside database to validate it.

    Inside a file, a JUMBF manifest store holds a manifest made of assertions, a claim that lists a hash of each assertion, and a signature with its certificate and timestamp; one assertion hashes the content bytes, which is the hard binding.
    One manifest per signing: assertions say what happened, the claim lists them, the signature seals the claim, and a hash ties it all to the content.
  • Manifest store

    The set of all manifests a file carries, one per signed version; the newest one is the active manifest.

    A manifest store is the collection of manifests in one asset. Each edit-and-sign step can add a manifest, and the last one added is the active manifest, the one a checker reads first. Earlier manifests stay in the store as ingredients, so the history can be followed back.

  • Claim

    The part of a C2PA manifest that lists every assertion by hash and is then signed, so no assertion can change unnoticed.

    In C2PA, the claim is the data structure that the signer actually signs. It lists each assertion in the manifest by a hashed reference, names the signing tool, and through that list includes the hard binding that ties the manifest to the content. The claim signature, a COSE signature over the claim, is what makes the whole manifest tamper-evident.

  • Assertion

    One statement inside a C2PA label, such as what was done to the content, whether AI was used, or the content's hash.

    An assertion is a single statement in a C2PA manifest. Standard assertions record actions (created, edited, AI-generated), hashes that bind the manifest to the content, ingredients, thumbnails and metadata. The claim lists every assertion by hash, so changing one breaks the signature check.

  • Actions assertion

    The part of a label that records what was done to the content, such as created, edited or redacted, and by what.

    The actions assertion (c2pa.actions) lists the actions taken on the content, such as c2pa.created, c2pa.edited or c2pa.redacted, with the tool used and, where declared, the digital source type. Each signed version adds its own actions, so the record grows with the content.

  • Digital source type

    A field in the label that says how content was made: captured by a camera, made by AI, or a mix.

    Digital source type is a value in a C2PA actions assertion, taken from the IPTC vocabulary, that declares how the content was produced. Examples: digitalCapture (a camera), trainedAlgorithmicMedia (made by an AI model), compositeWithTrainedAlgorithmicMedia (a mix). It is how a C2PA manifest declares AI involvement in a form software can read, which is what EU AI Act Article 50 marking asks for.

  • Ingredient

    A source file used to make new content, recorded in the new content's label with a link to its own label.

    In C2PA, an ingredient is an asset used to create another asset: the photo inside a layout, the clip inside an edit. The new manifest records each ingredient and, where the ingredient was signed, points to its manifest, so a checker can follow the history.

  • Ingredient chain

    The links from a finished piece of content back through every signed source file used to make it.

    An ingredient chain is formed when each manifest references the manifests of its ingredients. Following the references leads from the final output back to its signed sources. Unsigned sources appear as gaps: the chain shows only what was signed.

    Three versions of a paper, preprint, accepted manuscript and version of record, each with its own seal, linked back to the version it was made from.
    Each new version carries its own label and points back to the one it came from, so anyone can trace it to the first.
  • Provenance chain

    The full signed history of a piece of content, from first creation through each signed edit.

    A provenance chain is the history built from manifests and their ingredient references. It can start at a camera or a model, pass through edits, and end at the published version. It is complete only where every step was signed; an unsigned step is a visible gap.

  • Hard binding

    A hash of the content's signed bytes stored in the label, so a change to those bytes makes the check fail.

    A hard binding ties a manifest to one exact version of the content. The manifest stores a cryptographic hash of the content bytes (a data hash, or a BMFF hash for video and other box-based files). The checker hashes the file again; if one hashed byte changed, the hashes differ and the binding fails. Ranges listed as exclusions, such as the manifest itself, are not hashed. Every standard C2PA manifest needs one.

    Hard binding is a fingerprint of the exact file, so a re-encode breaks it. Soft binding is a watermark in the picture that still leads back to the label after a re-encode.
    The fingerprint proves the file is unchanged. The watermark finds the label again when the file has changed or lost it.
  • Soft binding

    A watermark or fingerprint that can find a content label again after the file was copied or its metadata stripped.

    A soft binding links content to its manifest in a way that survives changes a hard binding does not, such as re-encoding or metadata removal. It is a watermark embedded in the content or a fingerprint computed from it. A checker reads the watermark or computes the fingerprint, then looks up the matching manifest. It finds a label; the hard binding and signature still decide whether the label checks.

    Hard binding is a fingerprint of the exact file, so a re-encode breaks it. Soft binding is a watermark in the picture that still leads back to the label after a re-encode.
    The fingerprint proves the file is unchanged. The watermark finds the label again when the file has changed or lost it.
  • JUMBF

    JPEG Universal Metadata Box Format: the container that holds a C2PA label inside a media file.

    JUMBF (JPEG Universal Metadata Box Format, ISO/IEC 19566-5) is a box-based container for metadata. C2PA stores the manifest store in JUMBF boxes inside images, audio, video and documents. Apps that do not read C2PA skip the boxes, so the file still opens normally.

  • CBOR

    Concise Binary Object Representation: a compact binary form of JSON that C2PA uses to store a label's data.

    CBOR (Concise Binary Object Representation, RFC 8949) encodes the same kinds of data as JSON in a smaller binary form. C2PA writes claims and most assertions as CBOR, and COSE signatures are CBOR structures.

  • BMFF

    ISO Base Media File Format: the box structure behind MP4, MOV, HEIF and similar files.

    BMFF (ISO Base Media File Format, ISO/IEC 14496-12) organizes a file as nested boxes, each with a type and a length. MP4, MOV, M4A, HEIF and AVIF use it. C2PA puts its manifest in a dedicated uuid box, which other tools skip, and hashes the file box by box (a BMFF hash), so large media can be checked in parts.

  • XMP

    Extensible Metadata Platform: a common way to store metadata in files. Like EXIF, it is not signed and is often stripped.

    XMP (Extensible Metadata Platform, ISO 16684) stores metadata in images, PDFs and video. EXIF is the older camera metadata format. Neither is signed. C2PA can point to a manifest from XMP and can carry the same fields inside a signed assertion.

  • EXIF

    Photo details stored in an image file, such as date, camera and settings.

    EXIF fields sit in the image header and record capture details: date, camera, lens, exposure, sometimes location. Many social sites and image services delete them on upload. EXIF is not signed, so anyone can change it; a C2PA manifest is signed, so a change to it shows.

  • File container

    The outer structure of a file that holds the picture, sound or text plus extra data.

    Every media format has a container with places for extra data: boxes in BMFF, chunks in RIFF and PNG, frames in ID3, entries in ZIP-based documents. C2PA defines where the manifest goes in each one, so the label sits in the file without changing the picture or sound.

    In an MP4, MOV, HEIC or AVIF file, the label sits in its own box beside the boxes that hold the picture and sound.
    ISO BMFF files keep the label in its own box.
  • RIFF

    The chunk-based file layout behind WAV, AVI and WebP.

    A RIFF (Resource Interchange File Format) file is a list of tagged chunks. C2PA stores its manifest in a chunk of its own, beside the sound or picture chunks, so players that do not read C2PA ignore it.

  • ID3

    The tag block in an MP3 file that holds its title, artist and other details.

    ID3v2 is a block of frames at the start of an MP3 file. C2PA stores the manifest in a GEOB (general encapsulated object) frame marked with the C2PA media type.

  • Sidecar manifest

    A label stored in a separate file or at a web address instead of inside the content, linked by a reference.

    A sidecar manifest is stored next to the asset (a .c2pa file) rather than embedded in it. A remote manifest is fetched from a URL the asset points to. Both keep the file unchanged, at the cost of the label not traveling with the bytes on its own.

Signing and trust

How a signature shows who signed and that nothing changed.

  • Digital signature

    Math that shows which key signed something and that it has not changed since. Any edit to the signed bytes breaks it.

    A digital signature is made with a private key and checked with the matching public key, usually found in an X.509 certificate. If the signed bytes change, the check fails. A valid signature shows which key signed and that the data is unchanged; a certificate chain shows who holds the key.

  • Hash

    A short fingerprint of exact bytes. Any change, even one character, gives a completely different hash.

    A cryptographic hash function, such as SHA-256, turns any data into a fixed-length value. The same input always gives the same hash; a one-bit change gives an unrelated one; and nobody can find two inputs with the same hash in practice. C2PA uses hashes to tie a manifest to content and to tie the claim to each assertion.

  • Public key cryptography

    Signing with a secret private key that only the signer holds, checked by anyone with the matching public key.

    Public key cryptography uses a key pair. The private key, kept secret, makes signatures; the public key, shared freely, checks them. C2PA signatures commonly use ECDSA or EdDSA keys. Whoever controls the private key controls the signature, so keys live in protected hardware or services.

  • COSE

    CBOR Object Signing and Encryption: the signature format C2PA uses to sign the claim inside a label.

    COSE (CBOR Object Signing and Encryption, RFC 9052) is the binary counterpart of JOSE for JSON. A C2PA claim signature is a COSE_Sign1 structure: it names the algorithm, carries the signer's certificate chain and, optionally, a timestamp, and signs the claim. Altering the claim makes the signature fail.

  • X.509 certificate

    A digital ID card for a signing key: it names the holder and is itself signed by a certificate authority.

    An X.509 certificate binds a public key to a named holder and is signed by a certificate authority. The same format secures HTTPS. In C2PA, the signer's certificate travels in the claim signature, so a checker can see who holds the key and follow the chain to a trusted root.

  • Certificate chain

    The links from a signer's certificate up to a root authority a checker already trusts.

    A certificate chain runs from the signer's certificate through any intermediate certificates to a root certificate authority. A checker trusts the signer only if the chain ends at a root it trusts, such as one on the C2PA Trust List, and no certificate in it is expired at signing time or revoked.

    A checker trusts a signature when the signer's certificate was issued by a certificate authority on the C2PA Trust List, and trusts the timestamp when it comes from an authority on the C2PA TSA Trust List. The Conforming Products List shows the signing tool was tested.
    Trust is about who signed and when. It does not make the content true.
  • Certificate authority

    An organization that checks who someone is and then issues a certificate saying so.

    A certificate authority (CA) verifies an applicant's identity and signs an X.509 certificate for their key. Checkers trust signatures that chain to CAs they already trust. The C2PA Trust List names the CAs that conforming C2PA checkers trust by default.

  • C2PA Trust List

    The list of signing authorities that conforming C2PA checkers trust by default.

    The C2PA Trust List, published through the C2PA conformance program, names the certificate authorities whose signing certificates conforming checkers trust by default. A separate TSA Trust List names trusted timestamp authorities. A signature that chains to a listed certificate shows as trusted; one that does not can still be valid but shows as untrusted.

  • Timestamp authority

    An outside service that signs the time a record existed, so a signature stays checkable after its certificate expires.

    A timestamp authority (TSA) issues RFC 3161 timestamps: a signed statement that some data existed at a given time, independent of the signer's own clock. In C2PA, a timestamp on the claim signature shows the certificate was valid when the content was signed, so the label stays checkable after the certificate expires.

  • Revocation

    Cancelling a certificate before it expires, for example after a key leak. Checkers then reject its signatures unless a trusted timestamp shows they came first.

    A certificate authority can revoke a certificate, for example when its key leaks. Checkers learn of it through OCSP responses or revocation lists. C2PA validators report a revoked signer as a failure.

  • Validation status code

    A short standard string a C2PA checker reports for each check, such as claimSignature.validated or assertion.dataHash.mismatch.

    When a C2PA validator checks a manifest, it reports one status code per check: whether the signature verifies, whether each hash matches, whether the signer is trusted. Most success codes end in validated, match or trusted, and most failures in mismatch, untrusted, revoked or missing. C2PA also defines other success codes, such as signingCredential.ocsp.notRevoked, and informational codes that are not failures.

  • Merkle tree

    A tree of hashes that lets one small piece, such as a single sentence, be checked against a signed whole.

    A Merkle tree hashes each piece of data, then hashes pairs of hashes up to a single root. Signing the root signs every piece. To check one piece, a verifier needs only that piece and the few hashes on its path to the root. It is a general technique, used in certificate transparency logs and version control.

  • Document-level signing

    Signing a file or text as one whole, so the check shows whether anything in it changed.

    Document-level signing authenticates content as a whole: who signed it, when, and that it is unchanged since. It is the core of the C2PA standard. Sentence-level attribution goes further and lets a single passage be checked on its own.

  • Sentence-level attribution

    Checking that one sentence came from a specific signed source unchanged, even when it is quoted on its own.

    Sentence-level attribution is Encypher's patent-pending extension to document signing. Each sentence can be checked on its own, so a verified sentence can be matched to its signed source, for example "sentence 47 of this article". Legal use depends on the facts and counsel.

  • Quote integrity verification

    Checking that a quoted passage, for example in an AI answer, matches the signed original word for word.

    Quote integrity verification compares a passage that appears elsewhere, such as in an AI response, with the signed original. The check shows whether the passage was quoted exactly, altered, or not from that source at all.

Marks in text

How a label rides inside plain text, and what can remove it.

  • Unicode

    The standard that gives every character in every writing system a number, so text looks the same on every device.

    Unicode assigns a code point to every character, including letters, emoji and invisible control characters. Because text is stored as code points, characters that render as nothing can still travel inside text. That is what lets a label ride inside plain text.

  • Variation selector

    An invisible Unicode character that normally picks a glyph style. Strung together, they can carry data inside text.

    Unicode defines 256 variation selectors (U+FE00 to U+FE0F and U+E0100 to U+E01EF). They normally choose between glyph styles, for example text or emoji presentation, and display as nothing on their own. The C2PA text-provenance standard encodes manifest bytes as a run of variation selectors, so the label is invisible to readers.

  • Zero-width character

    A Unicode character that takes no space on screen, such as a zero-width joiner.

    Zero-width characters, such as the zero-width space and zero-width joiner, are Unicode characters with no visible width. Some text marks encode data with them. Some editors and cleanup tools remove them, which is why mark designs differ in which characters they use.

  • Default text mark

    Encypher's default invisible mark for text on the web, in email and in most apps.

    The default text mark carries Encypher's signed label in characters readers do not see. It is compact and repairs small damage. It stays hidden in browsers, Google Docs and most PDFs. Microsoft Word shows it as boxes, so text bound for Word uses the Word-safe text mark. The checker reads both.

  • Word-safe text mark

    Encypher's alternative invisible text mark, for text that will be edited in Microsoft Word.

    The Word-safe text mark carries the same signed label as the default text mark and stays hidden when text is copied and pasted in Microsoft Word. It is longer than the default mark. It is chosen through the Encypher API, and the checker reads both.

  • Provenance markers

    Encypher's general name for invisible characters that carry a signed label inside text.

    Provenance markers are the invisible characters that carry a signed provenance payload in text. Encypher offers a default text mark and a Word-safe text mark for documents edited in Microsoft Word. The term separates them from visible watermarks and from statistical watermarking.

  • Invisible embedding

    Placing a label in content without changing how it looks or sounds.

    Invisible embedding hides data in content with no visible effect. In text, it uses invisible characters. In images and audio, the C2PA manifest sits in the file container rather than in the pixels or samples. A watermark goes further and alters the content signal itself, imperceptibly.

  • Unicode normalization

    Text cleanup that rewrites characters into a standard form. Some forms remove invisible marks.

    Unicode normalization converts text to a canonical form (NFC, NFD, NFKC, NFKD) so equal-looking text compares equal. Some platforms normalize text or strip characters they treat as noise. A text mark has to choose characters that survive the normalization its content will meet.

  • Text provenance

    A signed label for text: who signed it, when, and whether the words changed.

    Text provenance applies content provenance to articles, posts and AI replies. Because text has no container, the manifest is encoded in invisible characters under the C2PA text-provenance standard. A checker can then show who signed the text and whether it changed, including for an excerpt.

  • OCR

    Optical character recognition: software that turns a picture of text back into characters.

    OCR (optical character recognition) reads text from an image or a scan. The output is new characters, so any invisible marks in the original text are gone; the text must be checked by other means, such as matching against the signed source.

  • Reed-Solomon code

    An error-correcting code that lets a damaged mark be read back, as on CDs and QR codes.

    Reed-Solomon codes add redundant symbols to data so it can be recovered when some symbols are lost or wrong. CDs, QR codes and deep-space links use them. A mark that uses them can still be read after part of it is damaged.

Images, audio and video

Labels in media files, and what happens when files are copied.

  • Image provenance

    A signed label in an image file: who signed it, what they declared about how it was made and about AI, and whether it changed.

    Image provenance embeds a C2PA manifest in an image file's JUMBF container. JPEG, PNG, WebP, HEIF, AVIF, TIFF and other formats are covered. Camera makers, editing tools and AI image generators use it to record capture, edits and AI involvement.

  • Audio provenance

    A signed label in an audio file that records how it was made, including AI voice, and whether it changed.

    Audio provenance embeds a C2PA manifest in audio containers such as WAV, MP3, FLAC and M4A. It records whether audio was recorded, synthesized or edited, and with the right digital source type it serves as machine-readable AI marking.

  • Video provenance

    A signed label in a video file that records its source, edits and any AI involvement.

    Video provenance embeds a C2PA manifest in containers such as MP4 and MOV, hashed box by box (a BMFF hash) so large files can be checked in parts. With the right digital source type it marks AI-generated video.

  • Live stream provenance

    Signing a live broadcast piece by piece as it streams, so viewers can check it in near real time.

    Live stream provenance signs streamed media in segments as it is produced, so each segment can be checked before the broadcast ends. Transcoding and CDN delivery are the hard parts. This area of C2PA is still developing.

    A live stream is cut into short pieces, each with its own label tied to the label before it; one swapped piece breaks the thread, so the check shows exactly where.
    Each piece of a live stream carries a label linked to the one before. A swapped piece breaks the chain where it happens.
  • CMAF

    A way to cut video into short MP4 pieces so it can stream live.

    CMAF (Common Media Application Format) sends video as one initialization segment plus many short media segments. C2PA live video either puts a manifest with a session key in the initialization segment, and each segment carries a signature made with that key, or signs each segment with a manifest that links to the one before.

  • Transcoding

    Converting media to a new format or quality, which changes its bytes and so breaks a hard binding.

    Transcoding decodes and re-encodes media, for example to shrink a video for streaming. The output has new bytes, so a hard binding from the original no longer matches. A new manifest can record the transcode with the original as an ingredient, or a soft binding can find the original label.

  • Metadata stripping

    Removing the data stored beside the content, which many upload and resize tools do by default.

    Many social platforms, CMSs and image pipelines remove metadata when a file is uploaded or resized, often taking an embedded manifest with it. The content is unchanged but the label is gone. A soft binding, such as a watermark, can find the label again in a repository.

    A file signed with a label and a watermark loses its label when a site strips metadata; a checker finds the watermark, which points back to the signed record, shown as recovered.
    If a site strips the label, a supported watermark can lead back to the signed record. The result says it was recovered.

Watermarks and detection

Other ways to mark or judge content, and how they differ.

  • Cryptographic watermarking

    A hidden mark that carries or points to a signed record, so a check gives a yes or no rather than a likelihood.

    Cryptographic watermarking embeds a mark tied to a signed record of origin. Verification is deterministic: the signature checks or it does not, so there is no false-positive rate of the kind a statistical detector has. For text, Encypher carries the mark in invisible characters; for media, C2PA manifests plus soft-binding watermarks where needed.

  • Statistical watermarking

    A hidden pattern a model adds while generating content, found later by a detector that returns a likelihood.

    Statistical watermarking shifts patterns in generated text, images or audio, then detects them with an algorithm that returns a probability. It can suggest that content came from a given model but cannot say who published it or what rights apply. Paraphrasing or recompression can weaken the signal, and human work can be flagged in error.

  • SynthID

    Google DeepMind's statistical watermark, added while a model generates content and read by Google's detector.

    SynthID is Google DeepMind's watermarking system for text, images, audio and video generated by Google models. It is statistical: a detector reports how likely the watermark is present. Encypher can check SynthID marks that Encypher applied itself; it cannot read SynthID marks applied by Google or anyone else. It complements, and differs from, a signed C2PA manifest.

  • Fingerprinting

    Computing a compact summary of content and matching it against a database to find copies.

    Fingerprinting computes a signature of content's features, such as a perceptual hash of an image or an acoustic fingerprint of audio, and looks for matches in a database. It finds copies even after small edits, but needs a populated database and says nothing on its own about who made the content. In C2PA it can serve as a soft binding.

  • Perceptual hash

    A fingerprint based on how an image looks or audio sounds, so similar copies give similar values.

    A perceptual hash summarizes what content looks or sounds like rather than its exact bytes, so resized or recompressed copies hash close together. Matching systems use it to find reused media. Unlike a cryptographic hash, small changes give small differences.

  • AI detector

    A model that guesses whether content was made by AI and returns a probability, not proof.

    An AI detector classifies content as likely human-made or AI-made from its statistical features. It returns a score, can be wrong in both directions, and can be fooled by editing. Provenance takes the other approach: it reads what the publisher signed and declared.

    Provenance reads back a signed record: signed by Town Daily, made with AI: no, unchanged since signing. Detection runs unsigned text through an AI detector and returns a guess, such as 72 percent likely AI.
    Provenance is a record anyone can check. Detection is a guess with a score.
  • False positive

    A wrong yes, such as human work flagged as AI-made.

    A false positive is a detector saying yes when the answer is no: a human essay flagged as AI, an unmarked image read as watermarked. Every probabilistic detector has a false-positive rate. A signature check has no such rate: a valid signature from a key holder either verifies or it does not.

  • Deepfake

    Image, audio or video made or changed by AI so it looks real and could fool people.

    A deepfake is AI-generated or AI-manipulated media that resembles real people, places or events and could be taken as authentic (EU AI Act Article 3(60)). Article 50(4) requires deployers to disclose deepfakes, with lighter rules for clearly artistic or satirical work. Provenance helps from the other side: genuine media can carry a signed label.

  • Blockchain timestamping

    Writing a file's hash to a public ledger to show it existed at a given time.

    A blockchain is a ledger copied across many parties, where entries cannot be changed once added. Timestamping writes a content hash and a time to it. The file itself carries nothing that points to the ledger, so a reader needs the original file and the transaction to check it. A C2PA manifest is checked from the content itself.

    A file with its label inside reaches a reader who checks it on the spot; a file whose record stays on a ledger reaches the reader with nothing pointing to that record.
    A label inside the file travels with it. A ledger record stays behind.
  • Resolver

    A lookup service that takes an ID found in a watermark or fingerprint and returns the matching provenance record.

    A C2PA soft binding points to a record outside the file. A resolver is the service that answers that pointer and returns the manifest. Recovering a stripped label needs both a supported mark and a reachable resolver.

Rights and licensing

Machine-readable termsMachine-readable rights: Usage terms written so software can read them, such as whether content may be used for AI training. for crawlers, AI systems and ad buyers.

  • Machine-readable rights

    Usage terms written so software can read them, such as whether content may be used for AI training.

    Machine-readable rights are usage terms in a structured format software can act on: who holds the rights, which uses are allowed (indexing, retrieval, training) and how to license. They can sit in robots.txt, in an RSL file, or in an assertion inside a C2PA manifest, where they travel with copies that keep the label.

  • TDM reservation

    A machine-readable statement that a rights holder does not allow text and data mining, including AI training.

    Under the EU Copyright Directive (2019), rights holders can reserve text and data mining (TDM) rights by machine-readable means. The W3C community TDM Reservation Protocol (TDMRep), robots.txt rules and signed rights assertions are ways to state the reservation. The EU AI Act asks general-purpose AI providers to respect such reservations.

  • robots.txt

    The file on a website that tells crawlers which pages they may fetch.

    robots.txt is a plain-text file at a site's root that tells crawlers which paths they may fetch, by crawler name. Some AI crawlers have their own names, so a site can block them separately. It applies at crawl time on the publisher's server; a label inside the content travels with copies that have already left.

  • ODRL

    Open Digital Rights Language: a W3C format for writing usage terms that software can read.

    ODRL (Open Digital Rights Language, W3C Recommendation 2.2) expresses permissions, prohibitions and duties about content in a structured policy. It is a common way to encode licensing terms inside other formats, including provenance assertions.

  • RSL

    Really Simple Licensing: a standard for publishing AI licensing terms that robots.txt can point to.

    RSL (Really Simple Licensing) is an open standard for publishing machine-readable licensing terms for AI crawlers and systems. A site lists its terms in an RSL document and points to it, for example from robots.txt.

  • Content licensing

    An agreement that lets someone use content on set terms, such as for AI training or AI answers.

    Content licensing is permission from a rights holder to use content on defined terms. For AI it covers training, retrieval-augmented generation (RAG), indexing and attribution in answers. Machine-readable terms let AI systems read those terms automatically.

  • Coalition licensing

    Many rights holders licensing together, so a buyer signs one agreement instead of one per publisher.

    Coalition or collective licensing pools many rights holders' content under shared terms managed by an intermediary. A buyer, such as an AI company, signs once and gains access to every member's content on those terms, and revenue is shared by use.

  • Self-service licensing

    Getting a license by accepting published terms, with no one-off negotiation.

    Self-service licensing lets a user obtain a license on published, machine-readable terms without negotiating with the rights holder, with use tracked and paid for automatically.

  • RAG

    Retrieval-augmented generation: an AI system that fetches documents first, then writes its answer from them.

    RAG (retrieval-augmented generation) fetches relevant documents at question time and gives them to a language model to ground its answer. It uses content after training, so it is licensed and tracked separately from training use.

  • Content Telemetry Standard

    An open format for AI companies to report what they did with content: fetched, used, cited, shown or clicked.

    The Content Telemetry Standard, maintained by the SPUR Coalition of news publishers, names five usage events (retrieved, grounded, cited, presented, engaged). A report can carry a C2PA manifest hash as the content ID, so usage ties back to signed content.

  • OpenRTB

    The IAB Tech Lab protocol that ad exchanges and buyers use to bid on each ad slot in real time.

    OpenRTB, from IAB Tech Lab, defines the bid request and response that pass between sell-side and buy-side platforms in the milliseconds before an ad loads. A field in the bid request can say the page or creative carries a signed label, so buyers can choose labeled inventory.

  • Prebid

    Widely used open-source code that runs the ad auction before the page loads its ads.

    Prebid is widely used open-source header-bidding software. It collects bids from many exchanges before the ad server picks a winner, and it can pass extra signals, such as a provenance label, into the bid requests.

Law and policy

The rules that ask for AI labels, and the copyright terms around them.

  • EU AI Act

    The European Union's law on artificial intelligence, which includes rules for marking AI-made content.

    The EU AI Act (Regulation (EU) 2024/1689) regulates AI systems by risk level. For content, the key rule is Article 50: providers must mark AI-generated audio, images, video and text in a machine-readable way, and deployers must disclose deepfakes. The Act applies in stages; Article 50 applies from August 2, 2026, with systems already on the market given until December 2, 2026. It applies to anyone placing AI systems on the EU market, wherever they are based.

  • Article 50

    The EU AI Act rule that AI-made content be marked in a form software can read, and deepfakes disclosed.

    Article 50 of the EU AI Act sets transparency duties for AI systems. Providers of generative AI must mark synthetic audio, image, video and text output in a machine-readable, detectable way (Article 50(2)); deployers must disclose deepfakes and AI-written text on matters of public interest. The duties apply from August 2, 2026; providers of systems already on the market have until December 2, 2026. Fines reach EUR 15 million or 3 percent of worldwide annual turnover, whichever is higher (the lower of the two for SMEs and start-ups).

    Timeline of EU AI Act Article 50 and California AI Transparency Act dates from June 2026 to January 2028. A later California date, January 1, 2029, is not drawn.
    EU AI Act Article 50 and the California AI Transparency Act share one clock: duties started in August 2026 and widen through 2029.
  • Article 52

    The EU AI Act article on classifying general-purpose AI models with systemic risk. The marking rule is Article 50.

    Article 52 of the EU AI Act sets the procedure for classifying general-purpose AI models as having systemic risk. It is often confused with the transparency rule because earlier drafts numbered that rule 52. The obligation to mark AI-generated content is Article 50.

  • Provider

    Under the EU AI Act, the company that builds an AI system or puts it on the EU market under its own name.

    A provider (Article 3(3) of the AI Act) develops an AI system or model, or has one developed, and places it on the market under its own name. Providers carry the Article 50(1), (2) and (5) duties, including machine-readable marking of AI output.

  • Deployer

    Under the EU AI Act, a company that uses an AI system in its own work, such as a newsroom publishing AI-edited text.

    A deployer (Article 3(4) of the AI Act) uses an AI system under its authority in a professional activity. Deployers carry the Article 50(3), (4) and (5) disclosure duties, such as telling people that a deepfake is AI-made.

  • Machine-readable marking

    A label software can read that says content was made or changed by AI.

    Article 50(2) of the EU AI Act requires covered AI output to be marked in a machine-readable format and detectable as AI-generated. A visible "made with AI" note is for people; machine-readable marking is for software, such as a signed C2PA manifest with a digital source type, or a watermark.

  • Code of Practice on AI-generated content

    The EU's voluntary rulebook on marking and labeling AI content, published in final form on June 10, 2026.

    The European Commission's Code of Practice on Transparency of AI-Generated Content, published in final form on June 10, 2026, sets out how providers and deployers can meet Article 50. It is voluntary, not law; following it is one way to show compliance.

  • California AI Transparency Act

    California's law requiring generative AI providers to hide an AI disclosure in the images, video and audio they make or edit, and offer a free tool that reads it.

    The California AI Transparency Act (SB 942, amended by AB 853 and by SB 1000 and AB 2713, approved on September 30, 2026) requires covered generative AI providers to embed latent disclosures in images, video and audio their systems create or alter, and to offer a free disclosure verification tool that reads them. If a provider knows that a licensee modified the system so it 'no longer complies with this chapter', it must end the licensee's authorization or notify the licensee within 72 hours. Text is outside the provider duties. SB 1000 took effect at once as an urgency statute and removed the user threshold for covered providers. AB 2713 rewrote the large-platform duties that start on January 1, 2027.

  • Covered provider

    Under California law, anyone who makes a generative AI system that the public in California can use.

    The California AI Transparency Act defines a covered provider as 'a person that creates, codes, or otherwise produces a generative artificial intelligence system that is publicly accessible within the geographic boundaries of the state' (Bus. and Prof. Code 22757.1). SB 1000 removed the earlier user threshold on September 30, 2026. Covered providers carry the latent disclosure and free verification tool duties.

  • Latent disclosure

    Under California law, a hidden label inside a file that says which AI system made or changed it and when.

    A latent disclosure is the California AI Transparency Act's term for a hidden disclosure in content that software can read (Bus. and Prof. Code 22757.3). SB 1000 removed the Act's definition of 'latent' but kept the duty. As amended, it names the provider, the system name and version, the time and date of creation or alteration, a unique identifier and whether AI created or altered the content. A C2PA manifest is the common way to carry it.

  • Manifest disclosure

    Under California law before SB 1000, a label people could see that says content was made by AI.

    A manifest disclosure was the California AI Transparency Act's term for a visible notice that content is AI-generated. SB 1000 removed the duty to offer it and the definition of 'manifest'; the latent disclosure remains. The word manifest here means visible, not a C2PA manifest.

  • Provenance data

    Under California law, information about where content came from and how it was changed, in a standards-based format.

    California defines provenance data as information about the origin of a piece of digital content and its history of modifications 'in a format that is compliant, or interoperable with, widely adopted specifications adopted by an established standards-setting body'. System provenance data is the part that names the device or system and cannot be tied to a person. A C2PA manifest is the common example.

  • Willful infringement

    Copyright infringement done knowingly. US law allows up to $150,000 in statutory damages per work.

    Willful infringement is infringement where the infringer knew, or recklessly disregarded, that the use infringed. Under 17 U.S.C. 504(c)(2), statutory damages can reach $150,000 per work, against up to $30,000 for ordinary infringement and as little as $200 for innocent infringement. A signed rights notice that travels with copies that keep the label can be evidence of notice. Legal outcomes depend on the facts and counsel.

  • Innocent infringement

    Copyright infringement where the user had no reason to know the work was protected. Damages can drop to $200 per work.

    Under 17 U.S.C. 504(c)(2), a court may reduce statutory damages to as little as $200 per work when the infringer was not aware and had no reason to believe the use infringed. Notice carried with the content makes that defense harder to claim. Legal outcomes depend on the facts and counsel.

  • Statutory damages

    Damages set by law per infringed work, under 17 U.S.C. 504(c), with no need to prove actual loss.

    US copyright law lets a rights holder of a registered work elect statutory damages instead of proving actual loss: $750 to $30,000 per work, up to $150,000 if willful, or as little as $200 if innocent (17 U.S.C. 504(c)).

  • Formal notice

    Documentation that tells a user a work is protected and which terms apply, which matters for willfulness.

    Formal notice tells a potential infringer that a work is protected and states its terms. Willfulness turns on knowledge, so notice matters to damages. Rights terms in a signed manifest travel with copies that keep the label, so a system that processes such a copy has the terms in hand. Legal outcomes depend on the facts and counsel.

  • Copyright management information

    The author, title and terms attached to a work. Knowingly removing it can violate 17 U.S.C. 1202.

    Copyright management information (CMI) is identifying information conveyed with a work: title, author, owner and terms of use. Section 1202 of the DMCA (17 U.S.C. 1202) prohibits knowingly removing or altering CMI to hide infringement. A signed manifest that names the author and terms can be CMI.

Delivery and integration

Where signing runs: APIs, SDKsSDK: Software development kit: ready-made code that makes an API easy to use from a given language. and the edge of a CDNCDN: Content delivery network: servers around the world that keep copies of a site close to readers so pages load fast..

  • API

    Application programming interface: a way for one program to ask another to do a job, such as sign a file.

    An API (application programming interface) is a defined set of requests a program can send to a service. The Encypher API takes content and returns it signed, or takes signed content and returns the check result with its status codes.

  • API key

    A secret string that identifies your account when your software calls an API. Keep it out of public code.

    An API key authenticates requests to an API and ties usage to an account. It belongs in a server-side secret store or environment variable, never in browser code or a public repository.

  • SDK

    Software development kit: ready-made code that makes an API easy to use from a given language.

    An SDK (software development kit) wraps an API in a library for a programming language, handling requests, errors and types, so a developer can sign or verify with a few lines of code.

  • CDN

    Content delivery network: servers around the world that keep copies of a site close to readers so pages load fast.

    A CDN (content delivery network) caches and serves a site's pages and media from servers near each visitor. Cloudflare, Fastly, Akamai and CloudFront are examples. Because every page passes through it, a CDN is a natural place to sign content on the way out.

  • Edge function

    A small program that runs on a CDN's servers and can change a page as it passes through to the reader.

    An edge function runs on CDN servers close to the reader and can rewrite responses in flight. Cloudflare Workers, Fastly Compute, Akamai EdgeWorkers, Vercel and Netlify Edge Functions and Lambda@Edge are examples. An Encypher edge function signs each article as it is served, with no change to the CMS.

    A reader requests a page through a CDN edge worker; the worker fetches the page from your unchanged server, has Encypher sign the text, and serves the signed page, caching the signed copy for the next visit. If anything fails, the original page goes through.
    The edge worker adds the label on the way out. Your server stays the same, signed copies are cached, and the page always loads.
  • Lambda@Edge

    Amazon's way to run code inside its CloudFront CDN, close to the reader.

    Lambda@Edge runs AWS Lambda functions at CloudFront locations, triggered by viewer or origin requests and responses. It is the AWS form of an edge function.

  • Fail open

    If signing is down, the page is served unsigned instead of failing, so readers never see an error.

    A fail-open design lets traffic through when a dependency fails. An edge integration that fails open serves the original page if the signing service is slow or unavailable, so a signing outage never becomes a site outage.

  • Origin server

    The server where your site's pages are built and stored before a CDN delivers them.

    The origin server holds the real copy of every page. A CDN fetches pages from it, keeps copies near readers and serves them fast. An edge function runs in the CDN between the origin and the reader, so it can change a page without touching the origin.

  • Worker credential

    A secret key, tied to one verified domain, that lets an Encypher edge worker ask for signatures.

    You get a worker credential when you claim your domain in the Encypher dashboard. The edge worker sends it with every signing request. Without it the worker signs nothing and serves pages unchanged.

Create. Mark. Endure.

Sign a file and see these terms in a real label.