Before you publish, make the original record harder to lose.
Publication creates visibility, but visibility is not proof. This checklist helps you preserve the source, timing, version, claim boundary, and public record before release.
Evidence readiness10 minEssential15 checks
Primary question
Can you show what existed before publication, what was published, and how the published version connects to the original?
Use this checklist before making a work, file, article, dataset, media item, report, design, model output, or public claim available online or externally.
Publication changes the evidence position. Once something is public, copied, scraped, embedded, quoted, modified, or indexed, it becomes harder to separate the original record from later circulation. This checklist helps preserve the evidence trail before public exposure.
Evidence goal
Create a stronger record before public release, platform upload, external distribution, or public claim.
This checklist helps prepare evidence before publication. It does not prove legal ownership, originality, permission, regulatory compliance, infringement, or the truth of published claims by itself.
Working principles
What this checklist is trying to protect.
Publication is not preservation.
A live web page, public post, uploaded file, or platform listing may show that something is visible now. It does not automatically preserve the original evidence trail.
Preserve before exposure.
Evidence is stronger when the original file, timing record, receipt, and context are preserved before public release.
Match the source to the public version.
The retained source material should be clearly connected to the version that was actually published.
Claim less than the evidence cannot support.
A publication record may show release timing and content, but it does not automatically prove rights, originality, permission, authorship, or truth.
Section 1
Pre-publication source
Confirm that the original source material is preserved before the public version is released.
0%complete
Keep the native file, manuscript, project folder, repository, design file, dataset, or working record.
Why this matters and what to do
Why this matters
The public version is often a flattened, compressed, reformatted, exported, or platform-modified copy. The source file may preserve stronger evidence of creation, sequence, structure, and control.
What good looks like
The original editable file or project folder is stored separately.
The public export has not replaced the source version.
The source material can be matched to the published output.
Common mistake
Publishing the only copy, exporting over the source, or relying on the public platform as the archive.
Next action
Store the source material in a stable project evidence folder before publishing.
Keep drafts, notes, edits, research, asset lists, logs, repository history, or production material.
Why this matters and what to do
Why this matters
A finished public item can be challenged, copied, or stripped of context. Development material helps show how the work came into being and how the final version relates to earlier work.
What good looks like
Earlier drafts or working notes are retained.
Project assets, sketches, logs, or research notes are retained where relevant.
The development trail is not deleted during cleanup.
Common mistake
Tidying the project folder before publication and deleting the material that would have explained the work's development.
Next action
Preserve the supporting material before publishing, even if it looks messy.
Keep the published file distinct from the working source.
Why this matters and what to do
Why this matters
Separating the public copy from the source copy makes it easier to show what was published and what remained as the original working material.
What good looks like
The export or upload file is stored separately from the source.
The public version has a clear file name or version label.
The retained public copy matches the release version.
Common mistake
Publishing from a live working file without preserving a fixed release copy.
Next action
Export or save a release copy before uploading or posting.
Section 2
Timing and receipt
Create timing evidence before publication and preserve the public release record.
0%complete
Record existence before the work becomes public.
Why this matters and what to do
Why this matters
After publication, the work may be copied, indexed, scraped, embedded, or reposted. A pre-publication timing record helps distinguish the original release from later circulation.
What good looks like
A receipt, hash, timestamp, or independent record exists before publication.
The record identifies the version being published.
The record is exportable or independently checkable where possible.
Common mistake
Waiting until a dispute or copying concern arises before creating a record.
Next action
Create the timing record before you upload, post, submit, release, or announce.
Preserve the public address, platform ID, repository commit, DOI, page URL, listing, or release reference.
Why this matters and what to do
Why this matters
Evidence is stronger when the pre-publication record can be connected to the actual public release. Public URLs and platform IDs can change or disappear, so capture them early.
What good looks like
The public URL, post ID, repository commit, release tag, DOI, listing ID, or publication reference is recorded.
The identifier is stored with the evidence record.
The public version can be compared with the retained release copy.
Common mistake
Assuming the platform will keep the same URL, page, post, or file forever.
Next action
Save the public identifier immediately after publication.
Record when and how the work became public.
Why this matters and what to do
Why this matters
Platform display dates can be ambiguous, time-zone dependent, edited, hidden, or lost. A clearer publication record helps reconstruct the sequence later.
What good looks like
The publication date and approximate time are recorded.
The platform, channel, or release method is identified.
A publication confirmation, release log, email, or platform receipt is retained where available.
Common mistake
Relying only on what the platform date happens to show later.
Next action
Record the publication time, channel, and method in the project evidence folder.
Section 3
Rights and claim boundary
Check what you are claiming when publishing and what the evidence can actually support.
Evidence that a publication existed does not prove that every element inside it was yours to use. Third-party material creates a separate rights and permission question.
What good looks like
Third-party materials are identified.
Licences, permissions, citations, or source notes are retained where relevant.
Original contribution and external material are not confused.
Common mistake
Treating a receipt for the whole publication as proof of ownership over every included component.
Next action
Create a short rights note listing relevant third-party material before publication.
Avoid saying more than the evidence can support.
Why this matters and what to do
Why this matters
Evidence claims can become risky when they overstate what has been proven. A record may support timing, existence, custody, provenance, or release context. It may not prove ownership, originality, compliance, truth, or exclusivity.
What good looks like
The public wording is precise.
Evidence-backed claims are separated from legal, factual, or marketing claims.
No badge, mark, receipt, or timestamp is described as proof of more than it can show.
Common mistake
Saying "verified original", "legally protected", "copyright proven", or "tamper-proof truth" when the evidence does not support that claim.
Next action
Rewrite the claim so it describes the evidence boundary accurately.
Where relevant, preserve prompts, tool outputs, review steps, model/version notes, and human edits.
Why this matters and what to do
Why this matters
AI-assisted work can create authorship, provenance, permission, review, and accountability questions. Even where disclosure is not required, evidence of human review and production sequence may matter later.
What good looks like
AI or automation involvement is recorded where relevant.
Human review or editing steps are documented.
Prompt, output, model, dataset, or tool notes are retained where appropriate.
Common mistake
Publishing AI-assisted or automated material with no record of what was generated, reviewed, edited, or approved.
Next action
Add a short AI or automation production note where relevant.
Section 4
Public record capture
Preserve evidence of what was actually published, not just what you intended to publish.
0%complete
Keep a record of the public version after release.
Why this matters and what to do
Why this matters
Platforms can re-render, compress, moderate, hide, edit, delete, or restructure content. The public version should be captured while it is live and accessible.
What good looks like
A copy, export, web capture, platform receipt, or archive record exists.
The capture includes the URL or public identifier.
The capture can be matched to the retained source and release copy.
Common mistake
Assuming the public page will remain unchanged and accessible.
Next action
Capture or save the public version immediately after publication.
Platforms may compress, rename, transcode, crop, reformat, strip metadata, or generate previews.
Why this matters and what to do
Why this matters
The file you upload may not be the same object the public sees. Platform transformations can affect metadata, appearance, hash comparison, quality, and interpretation.
What good looks like
The uploaded file and public-rendered version are both retained where possible.
Known platform transformations are noted.
The evidence record does not confuse the upload object with the rendered public object.
Common mistake
Assuming the platform-displayed version is identical to the uploaded original.
Next action
Save both the uploaded release copy and the public-rendered version where practical.
Record the channels that first carried the publication.
Why this matters and what to do
Why this matters
Publication rarely happens in only one place. Announcements, reposts, embeds, newsletters, repositories, marketplaces, and social posts may all form part of the release sequence.
What good looks like
Primary publication channel is recorded.
Announcement channels are recorded.
The sequence of release and promotion can be reconstructed.
Common mistake
Publishing across several channels and later being unable to show where the release first appeared.
Next action
Add the publication and announcement channels to the project evidence folder.
Section 5
Retention and recovery
Make sure the publication evidence can be found, checked, and understood later.
0%complete
Keep source, release copy, receipt, public capture, and notes together.
Why this matters and what to do
Why this matters
Evidence fails when the pieces exist but cannot be found or connected. A publication evidence folder reduces later reconstruction failure.
What good looks like
Source material is retained.
Release copy is retained.
Receipt or timing record is retained.
Public URL or identifier is retained.
Rights and claim notes are retained.
Common mistake
Leaving evidence scattered across downloads, email, cloud folders, platform dashboards, screenshots, and memory.
Next action
Create a single publication evidence folder and place the key records in it.
Publication evidence should not depend on one device, account, or platform.
Why this matters and what to do
Why this matters
Devices fail, accounts close, platforms change, links expire, and dashboards disappear. Backup protects the evidence from ordinary loss.
What good looks like
The source file is backed up.
The receipt or timing record is backed up.
The public release record is backed up.
The backup is not only the public platform itself.
Common mistake
Treating the published web page as the backup.
Next action
Back up the publication evidence folder before moving on.
Future reviewers should not have to guess how the records connect.
Why this matters and what to do
Why this matters
Evidence is stronger when the connection between source, receipt, public version, and claim is understandable. A short note can reduce confusion later.
What good looks like
The note identifies the source file.
The note identifies the published version.
The note identifies the timing record or receipt.
The note states the claim boundary.
Common mistake
Saving files without explaining what each one proves or how they connect.
Next action
Add a simple verification note to the evidence folder.
Completion
What stronger publication readiness looks like
You are in a stronger position when the source material, release copy, pre-publication timing record, public release record, rights notes, claim boundary, and recovery path are preserved before or immediately after publication.
Stronger position
The original source file or project is retained.
The publication copy is separated from the working source.
A timing record or receipt exists before publication.
The public URL, platform ID, release tag, DOI, or publication identifier is recorded.
The published version is captured as it appeared.
Third-party material and AI or automation involvement are noted where relevant.
The evidence claim does not exceed what the records can prove.
The evidence can be recovered and checked later.
Weak position
Only the public page or platform upload exists.
No record was created until after a dispute or copying concern.
The source file was overwritten or lost.
The publication version cannot be matched to the source.
Third-party material is mixed into the work without notes.
The claim wording overstates what a timestamp, receipt, or public page proves.
The evidence is scattered across platforms, screenshots, downloads, and memory.
Next steps
What to do from here.
If you have not published yet
Preserve the source, create the timing record, export the release copy, review the claim boundary, then publish. Do not rely on the future public page as your proof.
If you have just published
Capture the public version, save the URL or identifier, record the publication time and channel, and store everything with the source and receipt.
If the publication is already being challenged
Stop casual edits to the relevant files. Preserve source material, release copies, receipts, platform records, URLs, communications, rights notes, and public captures. Consider legal or forensic support before making strong claims.
This checklist prepares evidence. It does not decide legal outcomes, certify ownership, prove infringement, prove compliance, or replace professional advice.
