HISTORICAL DIG · JUL—AUG 2026

The song is live. What counts as a result?

Going live, showing public activity, qualifying for royalties, appearing on a distributor statement, becoming withdrawable, and reaching a bank are records created by different parties at different times. An earlier state never proves the next one happened.

First recorded · Last public revision · Revision 3
Release-state receiptActivity and eligibilityAccrued royaltiesCash receivedRound cost and next move

HOW IT RELATES TO WORKFLOW 001

Relation to the current subject

It follows the listening and rights gates without turning “live” into “earned.”

The first AI-music history record asks only whether one sample deserves another edit. The second holds public release while voice, material, use, or permission remains unresolved. This record begins only after those gates are provisionally closed: once the same version is live, how can platform activity, monetization eligibility, distributor statements, cash received, and round cost each keep their own evidence? It shares Workflow 001's method—freeze the result and stop conditions before adding tools or spend—but it is not the same topic.

Record state at the time

  • AI audio and music
  • AI-song release result
  • In-depth record
  • Developing
  • Historical E2 · platform, chart, and distributor material rechecked · no BitShovel release or cash result

THE GUIDANCE AT THE TIME

Judgment at the time

A play count cannot testify for a royalty statement. A statement cannot testify for a bank receipt.

Open full rationale and return rules
Do not begin with “Was the song successful?” Begin with the last primary receipt you can actually open. Record release state, platform activity, monetization eligibility, distributor accrual, cash received, and round cost separately; update each field only from its own source. No statement means no accrued amount. No payment or bank receipt means no cash. A valid first-round result can be: live, no checkable royalty statement yet, so further spend stays on hold.
Who it was for
People with one rights-reviewed song ready for a limited release, or anyone who wants to define “result” before adding promotional spend
Why it mattered then
Open note

Multiplying a visible play count by an internet ‘per-stream rate’ turns platform activity into invented income. Reading only a distributor balance can still miss reporting delay, adjustments, fees, withholding, and cash that never arrived. A bad result definition can trigger the next spend.

Where the judgment stops
Open note

BitShovel has not released this song and has no matching service, distributor, rights-holder, tax, or bank account. There are no real plays, royalties, withdrawals, fees, or cash receipts. Every identifier, date, activity count, and cost in the explainer is fixed fictional data. Unknown is not zero, and green means only that a named receipt exists—not that the work succeeded, activity qualified, profit was earned, or another release should proceed.

CHECK BEFORE READING ON

Fit check

First accept that “live, still unknown, hold spend” can be a complete result.

This record may help

  • There is one candidate release, input and voice-rights questions have a recorded answer from the previous gate, and paid traffic can wait.
  • You can preserve read-only distributor, platform, statement, and payment receipts—and accept that the answer remains unknown during the reporting window.

Do not use it yet when

  • Lyrics, melody, voice, samples, or tool permissions remain unresolved; return to the pre-release rights check instead of releasing first.
  • You are considering guaranteed streams, guaranteed playlist placement, or promotion that cannot account for genuine listener intent.
  • You need accounting, tax, contract, or cross-jurisdiction legal advice; this historical record does not provide it.

UNRUN, UNFROZEN 60-MINUTE RECEIPT LEDGER

Historical trial

Follow one version, preserve five read-only receipts, and never spend to fill an unknown.

Time needed
A 60-minute ledger setup cap; platform review, reporting, and settlement waits are separate
Likely cost
No guaranteed streams or paid traffic in the first round; record existing distribution, production, and labor cost first
Permission boundary
Keep read-only copies, dates, and summaries only; do not publish accounts, tax records, contracts, credentials, or real listener data
  1. 01

    First step

    Open this step

    Freeze one release identifier and master digest, then create five rows: release state, activity with its reporting window, eligibility and adjustments, accrued and withdrawable amount, and cash received; keep round cost separately. Each row records date, responsible party, source currency, source, receipt digest, and next review date. Missing evidence stays unknown—never zero and never estimated from play counts.

  2. 02

    What should exist

    Open this step

    One read-only receipt ledger and one decision—wait, change one thing, stop spend, or enter another round—not a revenue forecast or success claim.

  3. 03

    How to tell it worked

    Open this step

    You can answer whether the release is live, which window the activity covers, what has been confirmed eligible, what the distributor accrued, what cash actually arrived, what the round cost, and why the next review exists. Anything unanswered remains unknown.

  4. 04

    Stop when

    Open this step

    Stop when rights status regresses, receipts cannot be opened or conflict, activity legitimacy is questioned, adjustments or charges remain pending, cost is incomplete, or the next move breaks the spending cap.

  5. 05

    How to back out

    Open this step

    Pause promotion and the next release, preserve source receipts and changes, and add only one new item of evidence at the review date. If the decision still cannot be completed, close the round explicitly instead of spending to fill an unknown.

BITSHOVEL R3 RELEASE RECEIPT LEDGER · FIXED FICTIONAL RECORD

Method and interfaces

Each state updates from its own primary receipt; an earlier state never derives the next one.

Open method boundary

DEMO RELEASE 04, 128 demonstration activities, the 2030 dates, and the ¥120 cost are all fixed fictional data. Green means only that the named receipt exists; yellow means unknown or waiting. None is a release, royalty, tax, bank, or profit result.

Let each receipt prove only its own stateBITSHOVEL R3 EXPLAINER · FIXED FICTIONAL RECORD
A fixed fictional release ledger shows a song live with an activity report while eligibility, accrued royalties, and cash remain unknown, so the next promotional spend stays on hold

DEMO RELEASE 04, 128 demonstration activities, and the ¥120 demonstration cost are all fixed fictional data. The image shows only that a live state and activity report can coexist with unknown eligibility, accrual, and cash—and that holding the next spend is a complete result.

About this image and its source

BitShovel explainer created August 16, 2026; it contains no real song, account, service, distributor, stream, royalty, tax, bank, or profit result.

Open source page

SOURCES AND EVIDENCE

Sources and evidence

As of August 16, 2026, primary sources separately describe how platforms calculate or withhold royalties, how distributor reports can lag, and how one title appeared in a chart-and-sales window. They cannot be assembled into BitShovel cash.

Open evidence boundary

Revision 3 keeps Billboard's single-title chart case and Deezer's platform policy as external context, then adds Spotify's royalty-flow and no-fixed-rate explanation, Spotify's artificial-streaming treatment, and DistroKid's reporting-delay example. Together they explain what can be seen and why cash still cannot be inferred. None is a BitShovel release or a general return rate.

  1. 01
    Platform royalty explanation · Rechecked

    Spotify says royalties flow to rightsholders and are not a fixed per-stream rate

    Open source boundary

    The maker explanation supports separating public activity, rightsholder accrual, and personal cash. It is Spotify's own system description—not an independent audit, a BitShovel statement, or a universal service rate.

    Open primary source or explainer
  2. 02
    Platform artificial-streaming rule · Rechecked

    Spotify says artificial activity can be corrected, withheld, or removed

    Open source boundary

    Public counts and private dashboards can diverge, and associated royalties may be withheld. Visible activity therefore does not establish eligible activity or cash. The rule is platform-specific and can change.

    Open primary source or explainer
  3. 03
    Platform AI-music policy · Rechecked

    Deezer says detected fraudulent AI-music streams are removed from its royalty pool

    Open source boundary

    This is one platform's account of its own detection and enforcement, supporting a separation between observed activity and royalty eligibility. The 85% figure describes Deezer's 2025 AI-music traffic and must not be generalized to one song, all AI music, or other services.

    Open primary source or explainer
  4. 04
    Distributor reporting example · Rechecked

    DistroKid separates go-live, earnings reports, and withdrawal timing

    Open source boundary

    The distributor says most service earnings typically appear around three months after go-live and may take longer. This is DistroKid's process example—not a guaranteed date, amount, or proof of payment.

    Open primary source or explainer
  5. 05
    Contemporary chart record · Rechecked

    Billboard recorded a No. 1 and 3,000 weekly sales for one AI-assisted song

    Open source boundary

    This is an external result with a named title, chart, and sales window. It does not disclose cost, rights splits, platform adjustments, statements, tax, or cash received, so it cannot answer profit.

    Open primary source or explainer
  6. 06
    BitShovel Revision 3 explainer · Rechecked

    The five-receipt ledger keeps live state, activity, eligibility, accrual, cash, and cost separate

    Open source boundary

    Every field is fixed fictional data. It establishes only that the public method has been expressed concretely—not that a release, royalty, payment, profit, or continuation decision occurred.

    Open primary source or explainer

REVISION RECORD

Revision record

Revision 3 replaces two lines with five receipts—and removes atmosphere and production diagrams from the result page.

Open 3 revisions
  1. Revision 1

    Opened a ledger for distribution submission, go-live, activity, royalties, and cash receipts.

  2. Revision 2

    Separated publication state from business outcome and replaced a technical workflow map with an openly licensed phone-and-headphones photograph.

  3. Revision 3

    Removed the atmospheric phone photograph and production map that could not explain release results, added a fixed fictional five-receipt ledger, incorporated royalty flow, artificial activity, and distributor reporting delay, and separated unknown from zero.

    What the record said before
    Track publication and business on two lines: submission, review, live state, and removal on one; valid streams, royalties, settlement, and cash on the other.
    What changed
    Two lines still collapse different owners and reporting windows. Each state now requires its own receipt: live does not prove eligible activity, activity does not prove accrual, distributor accrual does not prove withdrawability, and withdrawability does not prove cash. Every gap stays unknown and directly limits the next spend.

WHAT THIS RECORD LEAVES

What this record leaves

A number is not the next step. A sourced decision that still permits stopping is.

If only go-live and an activity report exist, keep eligibility, accrual, and cash unknown and hold the next spend. If statements and payment later appear, record source currency, fees, adjustments, and round cost. Rights regression, conflicting receipts, artificial activity, or the spending cap can close the round at any point.

Back to the Dig index