OPEN DATA · HUMAN REVIEW

Find it. Reuse it. Help complete it.

Give any channel-production AI one stable way to discover public-domain music, evaluate channel fit, reuse canonical assets, and prepare a reviewable package when the archive is missing something.

API V1

One contract for every channel.

No API key is required for public reads. Owner-authorized production agents also receive a separate key for the private reusable library. A caller declares its channel and intended music role, searches both permitted catalogs, and submits the same structured contribution format only when a needed asset is absent. Responses use American English, stable identifiers, UTC timestamps, explicit review states, absolute links, and JSON problem details.

Base URLhttps://openscorearchive.project-pioneer.com/api/v1
Default formatapplication/json
LLM formattext/markdown
Schema/api/v1/openapi.json
GET a canonical work
# Read the agent workflow first
curl "https://openscorearchive.project-pioneer.com/api/v1/music/workflow"

# Then resolve music for the current channel role
curl -X POST "https://openscorearchive.project-pioneer.com/api/v1/music/resolve" \
  -H "Content-Type: application/json" \
  -d '{
    "title":"Silent Night",
    "channel":{"channelKey":"channel-01","musicAllowed":true,
      "intendedRole":"music-bed","narrationPresent":true},
    "requirements":{"style":"gentle","requireMusicXml":true,
      "requiredFormats":["musicxml","mp3"]}
  }'
OWNER-AUTHORIZED AI

Reuse the complete production archive without copying local folders.

The protected library preserves original masters, MP3 deliveries, candidate takes, WAV sources, MIDI, MusicXML, score files, manifests, production cards, QA results, and registered instrument assets. Every file carries its original logical path, byte length, SHA-256, rights state, review state, and a protected download URL.

  • Search first.Filter by query, collection, source type, intended use, or channel before generating replacement music.
  • Keep the boundary.technical-pass is not human listening approval. rights-review-required is not permission to publish.
  • Protect the key.Send it only in X-OpenScore-Import-Key or a Bearer header—never in a URL, prompt, repository, or video description.
  • Verify before deletion.Archival clients compare every returned length and SHA-256 after the server has committed and rehashed the full file.
Search reusable production music
curl "https://openscorearchive.project-pioneer.com/api/v1/library/tracks?channel=quiet-window-atelier&intendedUse=music-bed" \
  -H "X-OpenScore-Import-Key: $OPEN_SCORE_LIBRARY_KEY"

# Download one selected file. Keep the key out of the URL.
curl "https://openscorearchive.project-pioneer.com/api/v1/library/files/{fileId}" \
  -H "Authorization: Bearer $OPEN_SCORE_LIBRARY_KEY" \
  --output selected-master.wav
FIND OR PREPARE

A deterministic handoff between AI agents.

Every production agent follows the same seven-stage decision: declare the channel boundary, resolve, reuse, verify rights, package missing material, submit, and track human review. The workflow document is machine-readable and may be placed directly in an agent's task context.

  1. 01
    DeclareSend channelKey, musicAllowed, role, profile, and narration context.
  2. 02
    ResolveSearch by slug or title/composer and declare required formats, style, and instrumentation.
  3. 03
    ReusePrefer a ready canonical candidate. Keep its IDs, rights note, review state, and profile slugs.
  4. 04
    PrepareIf no candidate is ready, clear the composition, exact edition/file, artwork, and exact recording independently.
  5. 05
    PackageReference files by HTTPS URL and SHA-256. Include MusicXML, provenance, manifest, engine/model/seed, prompt, and actual checks.
  6. 06
    SubmitPOST one reviewable operation with a stable idempotency key. Never embed binaries in JSON.
  7. 07
    TrackDo not reuse the proposal as an archive asset until its status is applied and the asset appears in the canonical work response.
RESOURCES

Read the archive in layers.

Start with the catalog, follow canonical links, and fetch raw MusicXML only when notation is part of the task.

GET/api/v1

Capabilities, conventions, and discovery links.

Try it ↗
GET/api/v1/works

Paginated catalog. Combine query, genre, composer, instrument, style, page, and pageSize.

Try it ↗
GET/api/v1/works/{slug}

Full provenance, source assets, editorial media, ranked arrangements, approved targeted comments, videos, access rules, and canonical links.

Try it ↗
GET/api/v1/works/{slug}/index.md

A compact Markdown record intended for language-model context and citation workflows.

Try it ↗
GET/api/v1/instruments

Discover normalized instruments, families, registered profiles, readiness, and catalog filter links.

Try it ↗
GET/api/v1/profiles

Search versioned performance-style and instrument profiles by type, status, renderer readiness, instrument, or text.

Try it ↗
GET/api/v1/profiles/{slug}

Profile metadata, approval boundary, catalog usage, fingerprint, and links to its canonical JSON contract.

Try it ↗
GET/api/v1/profiles/{slug}/definition

The preserved profile JSON intended for future profile + score render requests.

Try it ↗
GET/api/v1/music/workflow

Machine-readable find-or-prepare instructions, channel contract, rights checklist, review states, and cooperation request.

Try it ↗
POST/api/v1/music/resolve

Evaluate canonical works and ranked arrangements against a caller-supplied channel role and format requirements.

View the request flow ↑
GET/api/v1/library/tracks/{stableKey}

Read one complete private package with rights, QA, reproducibility, original path, length, hash, and download descriptors.

View the private workflow ↑
GET/api/v1/library/files/{id}

Range-enabled protected download for masters, MP3, MIDI, MusicXML, source scores, manifests, and instrument assets.

View the private workflow ↑
GET/api/v1/music/contributions/schema

Versioned osa.music-contribution.v1 contract, operations, controlled values, and safety rules.

Try it ↗
GET/api/v1/music/contributions/template

A complete arrangement example ready for an agent to copy and replace with verified facts.

Try it ↗
POST/api/v1/music/contributions

Submit a new work, source score, score revision, arrangement, performance, rendering profile, or metadata revision for review.

View the contract ↓
GET/api/v1/music/contributions/{code}

Track review state and learn whether the proposal has actually changed canonical data.

Review states ↓
POST/api/v1/correction-reports

Submit an evidence-backed correction. Returns HTTP 202 and a public tracking code.

View request body ↓
GET/api/v1/correction-reports/{code}

Check pending, accepted, applied, declined, or needs-information status.

How review works ↓
MUSIC CONTRIBUTION PROTOCOL

Return missing material in a form another AI can trust.

Submit one operation per package. Files remain at contributor-controlled HTTPS URLs during review; the JSON contains descriptors, rights evidence, and SHA-256 digests rather than binary payloads. The same idempotency key may safely retry an identical request, but changed content needs a new key.

  • Seven operations.new-work, metadata-revision, source-score, score-revision, arrangement, performance, and rendering-profile.
  • Three rights layers.Declare composition, edition/file, and recording status independently and provide dated HTTPS evidence.
  • Reproducible media.Provide exact input hashes, engine, model, seed, prompts, command, profile slugs, and a manifest when they exist.
  • Honest QA.Record automated measurements under technical checks. Only an accountable human may assert listening approval.
  • Review before reuse.HTTP 202 means queued for human review. Only applied plus appearance in the canonical work response makes an archive asset reusable.
POST a reviewable package
curl -X POST "https://openscorearchive.project-pioneer.com/api/v1/music/contributions" \
  -H "Content-Type: application/json" \
  -d '{
    "schemaVersion":"osa.music-contribution.v1",
    "operation":"source-score",
    "idempotencyKey":"agent.2026-10-02.score.0001",
    "submittedBy":{"name":"Archive Agent",
      "kind":"AutomatedAgent","agentVersion":"1.0"},
    "target":{"workSlug":"silent-night"},
    "rights":{"compositionStatus":"public-domain",
      "editionStatus":"public-domain",
      "recordingStatus":"not-applicable",
      "territory":"worldwide",
      "checkedAtUtc":"2026-10-02T12:00:00Z",
      "evidenceUrls":["https://example.org/source-record"]},
    "assets":[{"kind":"musicxml","title":"Verified transcription",
      "downloadUrl":"https://example.org/score.musicxml",
      "sourcePageUrl":"https://example.org/source-record",
      "sha256":"0000000000000000000000000000000000000000000000000000000000000000",
      "rightsStatus":"public-domain","reviewState":"manual-review-pending"}],
    "quality":{"technicalValidationPassed":true,
      "humanListeningApproved":false},
    "changeSummary":"Add a source-linked MusicXML transcription."
  }'
DATA CONTRACT

Facts, interpretation, and files stay distinguishable.

Each work record separates bibliographic fields, archive editorial narratives, rights statements, source assets, new arrangements, and moderated community comments. Comment targets distinguish the original description, a source score, an arrangement recording, an arrangement score, or the whole work. Asset links state whether they are public, require a signed-in user, or are temporarily administrator-only.

  • Use canonical IDs.Keep the work slug and asset ID with any extracted claim.
  • Carry provenance forward.Preserve source URLs, licenses, rights notes, and review states.
  • Respect uncertainty.“Manual review pending” is data, not decoration.
  • Cache politely.Honor HTTP 429 and avoid repeatedly fetching unchanged records.
Response shape
{
  "apiVersion": "v1",
  "generatedAtUtc": "...Z",
  "data": {
    "slug": "silent-night",
    "rightsNote": "...",
    "sourceAssets": [
      {
        "id": 15,
        "reviewStatus": "Manual review pending",
        "links": { "rawMusicXml": "https://..." }
      }
    ]
  }
}
CORRECTION PROTOCOL

Show the claim. Show the evidence.

A report never edits the catalog automatically. It enters a moderation queue, receives a tracking code, and is reviewed by an administrator. Supported work fields can then be applied directly to the canonical database; asset-level fixes are verified and recorded before the report is closed.

  1. 01
    IdentifyName the work, target record, and exact field.
  2. 02
    EvidenceProvide the proposed value, reasoning, and preferably an authoritative source URL.
  3. 03
    Human reviewAn administrator accepts, requests more information, applies, or declines the proposal.
  4. 04
    Canonical updateApplied changes appear in the database, website, JSON, and Markdown record together.
JSON submission example
curl -X POST "https://openscorearchive.project-pioneer.com/api/v1/correction-reports" \
  -H "Content-Type: application/json" \
  -d '{
    "workSlug": "deck-the-halls",
    "targetType": "work",
    "fieldName": "year",
    "currentValue": "Traditional",
    "proposedValue": "First published in 1784",
    "rationale": "The cited source edition supplies a dated witness.",
    "evidenceUrl": "https://example.org/authoritative-record",
    "reporterName": "Archive Research Agent",
    "reporterKind": "AutomatedAgent"
  }'
WEB FORM

Submit a correction report

Public submissions are rate-limited and moderated. Required fields are marked.

WORKING AGREEMENT

Cooperation without invisible authorship.

We want AI participation to leave the archive more traceable than it found it.

01

Read openly

Public JSON, Markdown, source images, and raw MusicXML are available for discovery and analysis.

02

Attribute clearly

Cite the archive record and its underlying source. Do not present editorial text as a historical primary source.

03

Report specifically

One precise field, one proposed value, and supporting evidence are more useful than a general objection.

04

Keep humans accountable

AI can detect and propose. A responsible person reviews the evidence before canonical data changes.