{
  "case_id": "DIG-DIS-2024",
  "canonical": "https://factualist.org/records/dig-dis-2024/faq.json",
  "case_page": "https://factualist.org/records/dig-dis-2024/",
  "last_reviewed": "2026/06/10",
  "record_posture": "public-redacted evidence record; no legal conclusion",
  "faq": [
    {
      "question": "What is the Dig Dis! record?",
      "answer": "It is a public-redacted evidence record concerning unresolved distribution-control, takedown-response, metadata-authority, platform-wide removal authority, and royalty-accounting questions involving Dig Dis!. It does not make legal conclusions."
    },
    {
      "question": "What is the core Dig Dis! issue?",
      "answer": "The core issue is an unresolved distribution-control, takedown-response, metadata-authority, and royalty-accounting gap: whether releases remained visible or distributed after a reported termination / disengagement request, whether takedown and accounting questions were handled with verifiable logs, and whether the release workflow created metadata-control burdens."
    },
    {
      "question": "Why is platform-wide removal authority relevant?",
      "answer": "A distributor with catalogue control may be able to request or trigger broad removal across a DSP network. The public-safe issue is whether authority boundaries, takedown logs, catalogue-return confirmations, and written explanations are verifiable."
    },
    {
      "question": "Why do Dig Dis!'s public transparency claims matter?",
      "answer": "Dig Dis!'s public materials emphasize full control, transparent monthly invoices, immediate invoicing, personal service, label-management tools, and release metadata workflows. The reviewed record raises the operational question of whether catalogue control, metadata authority, takedown response, platform-wide removal authority, and royalty accounting matched those public claims after disengagement."
    },
    {
      "question": "Why is Spotify-derived metadata dependency important?",
      "answer": "Because distribution metadata should remain verifiable at the delivery-record level. If downstream DSP metadata becomes the practical source for upstream delivery, capitalization, remix-version names, title formatting, and correction timing may become difficult to control before wider propagation."
    },
    {
      "question": "Does this record claim Dig Dis!'s app was technically defective?",
      "answer": "No. The record preserves a reported metadata-control and workflow-verification issue, including Spotify-derived metadata dependency and limited pre-delivery editing control. It does not make a technical-defect finding."
    },
    {
      "question": "What does this record not determine?",
      "answer": "It does not determine legal liability, intent, copyright infringement, deceptive conduct, discrimination, abuse, personal wrongdoing, technical defect, final payment liability, or an exact unpaid amount."
    },
    {
      "question": "What documents would resolve the issue?",
      "answer": "Relevant documents would include dated takedown confirmations, catalogue-return logs, DSP removal records, royalty statements, payment records, app metadata edit logs, DSP delivery logs, payout-threshold records, and written responses from Dig Dis! explaining post-termination distribution, metadata, and accounting status."
    }
  ]
}