Feature Request: PDF Provenance Compiler with Signed Revision Lineage and Copy-Aware Markers

Summary

I propose a new Adobe Acrobat and PDF-platform capability called the PDF Provenance Compiler.

Its purpose would be to create a cryptographically verifiable genealogy of PDF documents. Instead of treating every exported or edited PDF as an isolated file, the compiler could bind each new revision to an anonymized commitment representing its predecessor.

The result would be a chain of evidence that can connect drafts, approved versions, edited derivatives, screenshots, copied text passages, and exported graphics without publicly exposing every earlier document.

The central idea is simple:

Every new PDF revision can carry a signed and privacy-preserving reference to the document state from which it originated.

This would extend digital provenance beyond conventional metadata. It could be useful for professional authors, publishers, designers, research and development departments, healthcare organizations, government agencies, law-enforcement environments, archives, legal workflows, and other institutions that need to distinguish authentic document evolution from unexplained modification.

The Current Problem

PDF already supports digital signatures, certificates, embedded metadata, document restrictions, layers, and provenance information. These mechanisms are valuable, but they do not automatically create a comprehensible relationship between successive files.

When a document is edited, exported under a new name, converted, partially reused, or passed through several applications, its history often becomes a loose collection of files:

• Draft.pdf

• Draft-final.pdf

• Draft-final-corrected.pdf

• Draft-final-corrected-2.pdf

Names are not evidence. Timestamps can be changed. Metadata can be stripped. A conventional hash identifies one exact file but does not explain how a later revision relates to an earlier one.

A digital signature can confirm that one specific revision has not changed since signing. It does not necessarily describe the document’s ancestry.

The missing feature is therefore not another editable history list. It is a signed relationship between document states.

Proposed Feature: PDF Provenance Compiler

The PDF Provenance Compiler would process:

1. The current PDF document.

2. An optional predecessor PDF or predecessor proof.

3. The intended transformation or revision class.

4. The selected trust and privacy profile.

5. Optional text, graphic, hardware-key, or platform-attestation settings.

It would then generate a signed provenance record for the new revision.

A simplified record could contain:

PDF_Provenance_Record {
    scheme_version,
    chain_id,
    current_document_digest,
    predecessor_commitment,
    revision_class,
    page_binding,
    issuer_key_reference,
    creation_time,
    trust_profile,
    optional_copy_marker_profile,
    optional_graphic_marker_profile,
    nonce,
    signature
}

The compiler would not simply copy the raw hash of the predecessor into the new PDF. That could permit unwanted comparison, guessing, or tracking.

Instead, it would create a salted and domain-separated predecessor commitment:

predecessor_commitment =
    HASH(
        predecessor_digest
        || private_salt
        || chain_id
        || branch_information
        || scheme_domain
    )

A party possessing the predecessor file and the corresponding disclosure material could later prove the relationship. Anyone without that material would see only an opaque commitment.

This creates an anonymized document genealogy rather than a publicly searchable trail.

Why the Revision Chain Is the Main Strength

The strongest part of the proposal is not the watermark itself. It is the aging of the document through successive digital states.

Every legitimate revision becomes a new cryptographically signed link.

The system could distinguish between:

• A verified predecessor relationship.

• A predecessor that has not been disclosed.

• A missing link.

• A legitimate branch.

• An unexplained fork.

• A rollback to an earlier state.

• A document with no known predecessor.

• A document whose current contents no longer match its signed state.

This would make the document history selectively provable without requiring the entire working archive to be published.

A professional author could prove that a published manuscript descended from an earlier draft without revealing every private draft.

A research department could establish that a released report came from a specific internal review chain.

A healthcare organization could verify the relationship between an approved document and a later redacted version without embedding confidential predecessor content.

A government or law-enforcement workflow could distinguish an authorized derivative from an unexplained reconstruction while keeping sensitive earlier files compartmentalized.

The system would not prove that the content is true. It would prove that a particular document state was cryptographically linked to another document state by an authorized key.

That distinction is essential.

Integration with Adobe Acrobat

Adobe Acrobat Pro could provide a new Provenance panel containing:

• Current document digest.

• Current chain identifier.

• Verified or undisclosed predecessor state.

• Revision and branch information.

• Issuer and signing-key status.

• Timestamp status.

• Page completeness.

• Optional hardware-backed key status.

• Optional copy-marker status.

• Detected gaps, forks, rollbacks, or invalid transitions.

• A function for selectively proving a predecessor.

• A function for compiling the current document as a new signed revision.

The basic workflow could be:

1. Open the current document.

2. Choose Compile as New Provenance Revision.

3. Select a predecessor file or predecessor proof.

4. Choose the transformation class, such as edit, redaction, translation, approval, publication, or archival conversion.

5. Select a trust profile.

6. Review the information that will be included.

7. Sign and save the new revision.

Adobe Reader could provide read-only verification.

Adobe InDesign and Illustrator could offer the compiler during PDF export. Adobe PDF Services API could support server-side compilation and verification for organizational workflows.

The file should remain an ordinary readable PDF. Proprietary verification must not become a requirement for opening or displaying the document.

Latent Visual Marker for Digital Derivatives

As an optional component, the compiled PDF could include a Latent Visual Signature Layer.

This would be a visually unobtrusive, machine-readable pattern bound to the current chain tip and distributed across the rendered page.

Its primary digital purposes would be:

• Identifying screenshots derived from a protected page.

• Recognizing rasterized page exports.

• Connecting flattened derivatives to the originating revision.

• Detecting some forms of page substitution or recomposition.

• Preserving a short signed provenance reference when metadata is removed.

The marker should not be implemented merely as a switchable PDF layer. A removable named layer would be convenient for authoring and debugging but too fragile as the actual carrier.

During final export, the marker would need to become a subtle part of the ordinary rendered page representation.

The system should adapt its strength to local content. Fine typography, faces, QR codes, barcodes, medical imagery, formulas, and safety-critical diagrams should be protected by exclusion masks.

The marker must remain subordinate to readability and visual quality. If a page cannot safely carry it, Acrobat should report that limitation rather than silently increasing its strength.

Provenance-Aware Copy Export

A second optional component could protect the provenance of extracted text.

When Provenance-Aware Copy Export is enabled, supported copy and export operations could generate a marked text derivative.

The original text stored in the PDF would remain canonical. Visible glyphs, accessibility text, search text, ToUnicode mappings, tags, and ActualText would not be altered.

Only the explicitly controlled clipboard or export result would receive a sparse codeword.

Possible marker families could include carefully selected variants of:

• Ordinary spaces and selected Unicode spacing characters.

• Uppercase I, lowercase l, and the digit 1.

• Uppercase O, the digit 0, Greek Omicron, or Cyrillic O.

• Other font-tested confusable characters.

This mechanism requires severe restrictions.

It must never alter:

• URLs.

• Email addresses.

• Passwords.

• Source code.

• Hashes.

• Account numbers.

• Legal citations.

• Medical dosages.

• Measurements.

• Mathematical formulas.

• Product identifiers.

• Serial numbers.

• Accessibility content.

One unusual character must never be treated as evidence.

A valid detection would require:

• Multiple marker positions.

• A valid positional codeword.

• Error-correction consistency.

• A document or edition reference.

• A nonce.

• A cryptographically valid signature or message-authentication value.

Possible detection states should include:

• No marker.

• Candidate pattern.

• Verified provenance marker.

• Damaged or ambiguous marker.

• Verified policy event.

A verified marker could indicate that a text passage probably originated from a protected Adobe copy or export operation.

It could not, by itself, prove that the copying was illegal or unauthorized.

Private installations should retain a visible opt-out. Managed organizations could configure transparent policies and local auditing, provided that the users, purpose, and scope are clearly disclosed.

Signature and Graphic Copy Markers

The same principle could be applied to copied signatures, seals, stamps, logos, and other high-value graphics.

The graphic stored in the PDF would remain unchanged.

When a supporting Adobe application copies or exports the graphic, it could produce a subtly marked derivative containing a Signature Graphic Provenance Marker.

Possible carrier regions include:

• The interior of sufficiently wide strokes.

• Antialiasing edges.

• Near-neutral color-channel modulation.

• Redundant cells immediately surrounding the graphic.

• Texture already present in the image.

The marker could be bound to:

Graphic_Provenance_Record {
    chain_tip_reference,
    graphic_asset_digest,
    page_region,
    export_route,
    copy_nonce,
    signed_reference
}

A successful verification could indicate that an image was probably derived from a particular protected graphic in a particular document revision.

It must not claim that:

• The person shown or named created the graphic.

• A handwritten signature is genuine.

• The signer consented to the later use.

• The graphic constitutes a qualified electronic signature.

• The surrounding document is authentic merely because the graphic was copied from an authentic source.

The feature would establish probable graphic provenance, not legal intent.

Optional Hardware-Protected Signing

For explicitly protected PDFs, Adobe could optionally use hardware-backed signing keys.

On private systems this should be:

• Disabled by default.

• Activated only through an explicit document or template setting.

• Clearly shown before signing.

• Removable from future workflows through an opt-out.

• Free of raw, globally correlatable hardware identifiers.

The provenance record should contain only a scoped attestation reference or pseudonymous organizational key reference.

In managed high-security environments, an organization could require TPM- or HSM-protected signing as part of a documented policy.

Possible environments include:

• Government agencies.

• Law-enforcement organizations.

• Healthcare institutions.

• Critical research.

• Security-sensitive development departments.

• Regulated publishing or documentation systems.

Hardware attestation would support the statement that a protected key and an expected platform state participated in creating the signature.

It would not prove the truth of the document, the identity of the human author, or the absence of compromised software.

Optional Future Platform Attestation

A later interoperability extension could allow Microsoft, Apple, and Linux environments to provide a voluntary platform-level participation attestation.

Such a system might use short-term patterns derived from:

• Typing cadence.

• Key dwell and flight time.

• Pauses.

• Correction rhythm.

• Cursor acceleration.

• Cursor curvature.

• Micro-pauses.

• Click or touch sequences.

Raw interaction events and behavioral templates must remain on the local device.

The PDF should receive only a revocable, one-time statement containing information such as:

• Purpose.

• Current chain tip.

• Confidence band.

• Template version.

• Consent receipt.

• Time window.

• Platform signature.

This would be a probabilistic participation signal, not proof of identity or authorship.

It should be disabled by default, explicitly voluntary, revocable, and replaceable by an equivalent non-behavioral signing method.

Because illness, stress, fatigue, injury, new hardware, or accessibility software can change interaction behavior, such an attestation must never be the sole basis for rejection.

This platform component is not required for an initial Adobe implementation. It is a possible future interoperability layer.

Privacy and Accessibility Requirements

The default provenance profile should contain no:

• Personal identifier.

• User account name.

• Recipient identifier.

• Location.

• Permanent device identifier.

• Raw hardware identity.

• Raw behavioral data.

• Cross-document tracking identifier.

The system should identify the document state, page, edition, issuer, and revision chain—not the reader.

Acrobat should openly disclose when provenance markers are present.

Accessibility and canonical document semantics must take priority over copy markers. Screen readers, search systems, assistive software, and archival extraction should receive the intended original content.

Private users should be able to disable optional markers and attestations.

Organizational profiles should state clearly:

• Which components are mandatory.

• Why they are required.

• What information is stored.

• Who can verify it.

• Whether an event is logged.

• How long records are retained.

• Which alternative procedures are available.

No single glyph, pixel anomaly, behavioral score, or weak watermark detection should automatically trigger an accusation or sanction.

An alert should begin a review. It should not deliver a verdict.

Technical Limitations

This proposal should not be presented as an unbreakable protection mechanism.

A third-party raw PDF extractor may bypass copy-aware export and recover canonical text.

Unicode normalization, retyping, translation, OCR, or manual transcription may remove text markers.

Cropping, binarization, redrawing, re-vectorization, heavy compression, or image reconstruction may destroy graphic markers.

A determined attacker may damage or remove a latent visual pattern, especially when visible quality loss is acceptable.

Behavioral signals are probabilistic and can drift or be imitated.

Hardware-backed signing strengthens key protection but cannot certify the truth of content.

The goal is therefore not absolute prevention.

The goal is to make document lineage, derivative provenance, tampering, and unexplained transformations more measurable while reporting uncertainty honestly.

Suggested First Implementation

A realistic first Adobe prototype could focus on four components:

1. Signed revision lineage
   Compile a new PDF revision with a salted commitment to a selected predecessor.

2. Selective predecessor disclosure
   Prove one predecessor relationship without publishing the entire document chain.

3. Acrobat verification panel
   Display chain status, signature status, page binding, gaps, branches, and invalid transitions separately.

4. Optional provenance-aware export
   Add cryptographically verifiable markers to supported text and graphic export operations while preserving the canonical source document.

Hardware-backed signing could follow as an enterprise extension.

The latent visual marker and platform-level participation attestation could be evaluated as separate experimental modules.

Expected Value

This feature could give Adobe a document-provenance capability that extends beyond conventional signatures and editable metadata.

Potential users include:

• Professional authors and publishers protecting drafts and released editions.

• Designers proving the lineage of exported documents and visual assets.

• Companies tracing approved technical documentation.

• Research and development departments managing sensitive revisions.

• Healthcare organizations distinguishing authorized document derivatives.

• Government and law-enforcement environments requiring auditable document evolution.

• Archives preserving relationships between originals, redactions, translations, and later editions.

• Legal and compliance teams reviewing document history without exposing every confidential predecessor.

The commercial value would depend on successful implementation, interoperability, usability, privacy safeguards, and independent security testing.

This proposal describes a target architecture. It is not a claim that the technology has already been implemented, standardized, or experimentally validated.

Core Principle

A PDF should not have to forget where it came from merely because it became a new file.

The PDF Provenance Compiler would allow each revision to carry a cryptographically verifiable but privacy-preserving trace of its ancestry.

Optional visual, textual, and graphic markers could extend that provenance into digital derivatives without altering the canonical source document.

Authorship, Contact, and Request for Fair Recognition

This feature concept originates from Heinrich Görzen and is being shared in good faith as a constructive proposal for Adobe.

If Adobe decides to evaluate, develop, or materially incorporate this concept into a commercial product—particularly for professional publishing, healthcare, law enforcement, government, enterprise, or other security-sensitive environments—I respectfully ask Adobe to contact me regarding appropriate attribution and fair recognition of the contribution.

Considering the potential commercial and institutional value of such a feature, I would regard a modest four-figure honorarium together with non-expiring access to Adobe Photoshop, or an equivalent Adobe plan, as a fair and proportionate gesture.

This is intended as a respectful request for dialogue rather than a demand or an assertion that the proposal is already an implemented or commercially validated technology.

Heinrich Görzen
Contact:

[email removed as per forum guidelines]

(Co-writer ChatGPT)