BitShovel.One real problem at a time
Open the current workflowCurrent Workflow中文

One real problem at a time

中文

HISTORICAL DIG · JUL—AUG 2026

What must I check before publishing an AI image?

An image that opens, looks complete, and even carries verifiable provenance still does not align people consent, input licenses, client policy, destination rules, and commercial use. The fragile part before release is that these decisions sit across prompts, chats, agreements, platform forms, and the final export.

First recorded · Last public revision · Revision 2
Input provenancePeople & brandsCommission & toolUse & destinationDisclosure & freeze

HOW IT RELATES TO WORKFLOW 001

Relation to the current subject

It follows the data route: knowing how a file arrived does not tell you whether it can be released.

The previous historical record mapped the key, prompt, input, result, and workflow JSON. This one begins after the candidate is frozen and draws a release stop line. Technical provenance, permission and consent, commission terms, and destination rules need separate receipts.

Record state at the time

  • AI images
  • Local-first visual workflows
  • Deep record
  • Developing
  • Historical E2 · publisher cases and a pinned specification cross-read · no image rights clearance completed

THE GUIDANCE AT THE TIME

Judgment at the time

Keep technical provenance and publication permission in separate rows. Any unknown stops release.

Open full rationale and return rules
Keep technical provenance and publication permission in separate rows. Freeze the final candidate and hash first, then give every input, person or brand, tool and version, human edit, commission term, destination, territory, term, and use, credit, and AI disclosure its own row. Each row says continue checking, replace, or unknown. “Continue” means only that this internal preflight found no gap in that row—not legal clearance, platform approval, or a rights warranty. Any unknown stops release.
Who it was for
People with a final candidate ready for delivery, submission, advertising, listing, or public release but no single reviewable release record
Why it mattered then
Open note

Discovering a mismatch in input scope, identity, brand use, commission policy, or platform labeling after release can require more than replacing an image: delivered files, campaigns, credits, and version tracking may all move with it.

Where the judgment stops
Open note

BitShovel rechecked C2PA 2.4, D&D's specific recommissioning record, current Adobe Stock submission rules, Coca-Cola's controlled brand-asset activation, and a jurisdiction-specific U.S. Copyright Office report. They address technical provenance, publisher policy, destination rules, a controlled brand route, and U.S. copyright analysis respectively; they do not combine into universal rights clearance. BitShovel reviewed no agreement, real candidate, release, platform account, or publication outcome and provides no legal advice.

CHECK BEFORE READING ON

Fit check

The sheet is useful only after the candidate, intended use, and read-only receipts are fixed.

This record may help

  • The candidate is frozen and read-only copies of input sources, tool version, edit record, commission note, and intended use are available.
  • You are willing to let any unknown stop release rather than substituting “AI-generated,” “has C2PA,” or “the platform accepted the upload” for an answer.

Do not use it yet when

  • You need a formal finding from counsel, a union, client legal team, insurer, platform review, or regulator.
  • Inputs, people, brands, agreements, or intended use can only be checked by uploading unauthorized originals to a third-party service.
  • The candidate is still changing quickly, or the destination, territory, term, and commercial/editorial use are not fixed.

HISTORICAL TRIAL · READ-ONLY PRE-PUBLICATION PREFLIGHT

Historical trial

Freeze one candidate version and place receipts, unknowns, and the next confirmer into seven row groups.

Time needed
30–45 minutes for one pre-publication preflight; stop at the cap
Likely cost
Do not generate, advertise, or buy a review tool; inspect existing files and receipts only
Permission boundary
Read-only copies and a redacted ledger only; do not upload client sources, agreements, unauthorized people, or brands to BitShovel or a new third-party service
  1. 01

    First step

    Open this step

    Copy the final candidate as read-only and record its SHA-256. Create seven row groups: input provenance; people/property/brands; tool version and human edits; commission/client policy; destination, territory, term, and commercial/editorial use; credit and AI disclosure; final export and linked files. Attach one openable receipt or write unknown for every row. Record any C2PA/Content Credentials and validation state separately—never in the permission column.

  2. 02

    What should exist

    Open this step

    A one-page pre-publication record, one frozen candidate hash, and a continue-checking / replace / unknown state plus the next confirmer for every row.

  3. 03

    How to tell it worked

    Open this step

    Another authorized reviewer can open every receipt, distinguish technical provenance, permission/consent, and destination rules, and recompute the candidate hash. Passing means the preflight record is complete—not that the image is cleared for release.

  4. 04

    Stop when

    Open this step

    Stop when any person, brand, input, commission policy, intended use, platform disclosure, or allowed scope is unknown; a receipt does not open; permission does not cover the destination, territory, term, or commercial use; or the decision exceeds your authority.

  5. 05

    How to back out

    Open this step

    Freeze the export, replace the disputed input or return to the prior version, and keep before-and-after hashes, the reason, and unresolved rows. Do not continue to submit, advertise, or publish.

BITSHOVEL R2 EXPLAINER · RELEASE STOP LINE

Method and interfaces

Provenance, permission, and destination compliance are three different things.

Open method boundary

The first image separates the candidate pack, inputs and identities, commission and tool, use and destination, and disclosure and freeze. The second is a pinned C2PA specification image explaining technical validation only—not rights clearance.

Release stop line for one imageBITSHOVEL R2 EXPLAINER · NOT RIGHTS CLEARANCE
AI-image pre-publication route freezing the candidate, checking inputs and identities, commission and tool, use and destination, disclosure and hash, while keeping C2PA provenance separate from permission

Four gates separate technical provenance, permission/consent, and destination rules. Any unknown returns to STOP; continue checking is not permission to publish.

About this image and its source

BitShovel explainer created August 16, 2026 from C2PA 2.4, a D&D publisher record, current Adobe Stock submission rules, and the historical Dig. It contains no real candidate, agreement, person, brand, or publication outcome.

Open source page ↗
C2PA 2.4 Claim ValidationPINNED SPECIFICATION · NOT PUBLICATION PERMISSION
C2PA 2.4 Claim Validation diagram connecting image pixels, the manifest store, claim signatures, the assertion store, and ingredient validation

The diagram shows how the specification validates claims, signatures, assertions, and ingredients. It does not establish copyright, people consent, factual truth, platform approval, or commercial permission.

About this image and its source

Complete specification image from C2PA 2.4 pinned commit b1703dc, CC BY 4.0; converted uncropped to WebP by BitShovel. C2PA does not participate in or endorse BitShovel.

Open source page ↗Read use and attribution guidelines ↗

SOURCES AND EVIDENCE

Sources and evidence

As of August 16, 2026, C2PA, publisher cases, a destination rule, and a jurisdiction-specific report describe different review layers. They do not combine into a universal permission slip.

Open evidence boundary

Historical E2 came from cross-reading publisher outcomes and a pinned C2PA specification. Revision 2 adds current destination rules and a jurisdiction-specific official boundary, separating provenance, permission, and destination compliance. There is still no BitShovel publication, agreement review, or rights-clearance outcome.

  1. 01
    Current technical specification · Rechecked

    C2PA 2.4 validates provenance association, structure, signatures, and tamper state without making value judgments about the content

    Open source boundary

    The specification treats verifiable provenance as a trust signal. It does not decide whether assertions are good or bad and does not replace rights, consent, factual truth, or publication permission.

    Open original source ↗
  2. 02
    Publisher historical record · Rechecked

    D&D: an AI-tool change was not surfaced in the commission process, and affected art was removed and recommissioned

    Open source boundary

    The publisher records one project and one policy change. It supports checking commission terms and process disclosure before release—not a claim that all AI images are prohibited.

    Open original source ↗
  3. 03
    Current destination rule · Rechecked

    Adobe Stock requires contributors to check submission rights, tool terms, people/property releases, and generative-AI labeling

    Open source boundary

    This is the current rule for one destination, Adobe Stock—not a universal rule for every platform, country, publication, or client. Reopen the actual destination rule on the release date.

    Open original source ↗
  4. 04
    Brand-owner historical case · Rechecked

    Coca-Cola Create Real Magic put specified brand assets, submission, selection, and display scope into one activation route

    Open source boundary

    This controlled brand activation shows that allowed assets, selection, and display scope are workflow fields. It does not authorize anyone to generate with or publish other brand assets.

    Open original source ↗
  5. 05
    Jurisdiction-specific official report · Rechecked

    U.S. Copyright Office: assistive AI use does not automatically bar copyright, while prompts alone do not establish human authorship control

    Open source boundary

    This report addresses U.S. copyright law, not a worldwide conclusion, and does not resolve inputs, people, brands, agreements, destinations, or intended use. It supports recording human edits rather than treating a prompt as an ownership receipt.

    Open original source ↗

REVISION RECORD

Revision record

Revision 2 downgrades continue to an internal-preflight state rather than permission to publish.

Open 2 revisions
  1. Revision 1

    Opened a pre-publication check with real publishing, brand display, removal and rework, and a pinned C2PA specification.

  2. Revision 2

    Split technical provenance, permission/consent, and destination rules into separate evidence lanes. Downgraded continue to an internal-preflight state, stopped on any unknown, and added a current platform rule plus a jurisdiction-specific boundary.

    What the record said before
    Before publication, make a one-page sheet and mark each item continue, replace, or unknown.
    What changed
    Freeze the candidate and hash, then record technical provenance, permission/consent, and destination rules separately. Continue checking is not permission to publish; any unknown, missing receipt, or decision beyond your authority stops release and moves to the appropriate confirmer.

WHAT THIS RECORD LEAVES

What this record leaves

If an unknown still needs a guess, do not release yet.

The useful outcome is not a compliance badge. It is one frozen version, openable receipts, and a clear owner for every unresolved row.

Back to the Dig index