RFC 0001 — Version 1.0
Status: DraftCreated: 2025-12-12
Updated: 2026-01-17
Authors: MRS Working Group
License: CC BY 4.0
Abstract
This document specifies MRS (Music Representation), a model and protocol suite for encoding and safely editing musical scores in AI-assisted composition and orchestration workflows at professional scale. MRS is built on three core architectural principles:- Separation of storage and mutation formats: MRS-S is the canonical storage format; MRS-Ops is the typed operation protocol for agent mutations
- Player-Instrument-Staff model: Professional orchestration semantics with instrument doubling and switching
- Task-adaptive context: Dynamic context views tailored to specific editing tasks, not fixed reduction rings
Table of Contents
- Introduction
- Design Principles
- Architecture Overview
- MRS-S: The Canonical Storage Format
- MRS-Ops: The Mutation Protocol
- Players, Instruments, and Staves
- Working Set Envelope
- Task-Adaptive Context Views
- Structural Index
- Analytical Overlays
- Data Model
- Orchestrator Contract
- Progressive Validation
- Query Resolution
- Extension Mechanisms
- MIME Types and File Extensions
- Security Considerations
- Appendix A: Complete Grammar
- Appendix B: Quick Reference
- Appendix C: Glossary
1. Introduction
1.1 Motivation
AI cannot currently compose or edit full orchestral scores reliably. Three fundamental challenges block progress: Scale: A full orchestral score (~1.5M tokens) exceeds any context window. Editing measure 847 should not require loading measures 1-846. Context: Musical decisions require understanding surrounding material. An agent writing a countermelody needs phrase boundaries, harmonic rhythm, and thematic relationships—not just the target measures. Reliability: Existing approaches ask AI to emit complete, structurally-valid score fragments. This creates high failure rates from:- Accidental omissions (agent returns less than given)
- Calculation errors (duration sums, absolute positions)
- Hallucinated references (IDs that don’t exist)
- Format violations (malformed syntax)
- MRS-S (storage): Complete, archival-quality encoding with stable UUIDs
- MRS-Ops (mutation): Typed operation protocol with orchestrator-derived fields
- Task-adaptive context: Dynamic views tailored to specific editing tasks
- Progressive validation: Operations validated before application
- Orchestrator authority: Single source of truth for UUIDs, derived fields, and state
1.2 Goals
- Semantic completeness: Encode everything a professional engraver needs (Dorico-level granularity)
- Reliable agent output: Typed operations with progressive validation minimize repair loops
- Structural stability: UUIDs survive insertions, deletions, and reorderings
- Professional orchestration: Player/instrument model supports doubling, switching, condensing
- Task-appropriate context: Agents receive information relevant to their specific task
- Deterministic reconciliation: Operations produce predictable, auditable results
- Human-auditable: Operations are semantic diffs; humans review intent, not syntax
1.3 Non-Goals
- Encoding visual layout (page breaks, staff spacing, collision avoidance)
- Providing a programming language (no loops, conditionals, macros)
- Defining audio synthesis or playback behavior
- Replacing domain-specific formats (MIDI, audio, engraving source)
1.4 Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.| Term | Definition |
|---|---|
| Score | A complete musical work in MRS-S format |
| Player | A performer who may play multiple instruments |
| Instrument | A specific sound source with fixed transposition and range |
| Staff | A visual grouping of five lines; instruments may have multiple staves |
| Voice | An independent melodic/rhythmic stream within a staff |
| Measure | A metrical unit bounded by barlines, identified by UUID |
| Event | An atomic musical occurrence (note, rest, chord), identified by UUID |
| Span | A relation connecting multiple events (slur, beam, hairpin) |
| MRS-S | The canonical storage format (S-expression based) |
| MRS-Ops | The typed operation protocol for agent mutations |
| Working Set | A bounded MRS-S fragment with task-adaptive context |
| Orchestrator | System that owns canonical state and applies validated operations |
2. Design Principles
2.1 Separation of Concerns: Storage vs Mutation
MRS uses different representations optimized for different purposes:| Concern | Format | Optimized For |
|---|---|---|
| Storage, interchange, archival | MRS-S | Completeness, human readability, validation |
| Agent output, mutations | MRS-Ops | Reliability, minimal surface, explicit intent |
2.2 Orchestrator Authority
The orchestrator is the sole authority for:- UUID minting (agents use temporary IDs)
- Derived field computation (
:at,:beat-start,:sec-start) - Canonical state management
- Validation and application of changes
2.3 Stable Identity Over Positional Reference
Every measure, event, and span carries a stable UUIDv7 identifier. Measure numbers are display properties for human navigation, not structural identity. Rationale: Positional references break when content is inserted or deleted. UUID references survive structural changes.2.4 Progressive Validation
Operations are validated in stages before application:- Syntax: Operation is well-formed
- References: All referenced IDs exist (or are valid tmp-ids)
- Permissions: Operation is within granted lanes/scope
- Musical rules: Content satisfies constraints
- Application: State mutation (guaranteed to succeed after validation)
2.5 Task-Adaptive Context
Agents receive context views tailored to their specific task, not fixed “near/far” rings. Context is information needed to make correct decisions, not just nearby measures. Rationale: Fixed rings may include irrelevant content and omit critical content. Task-adaptive views provide what’s actually needed.2.6 Professional Orchestration Semantics
The Player → Instrument → Staff model supports:- Instrument doubling (Flute 2 / Piccolo)
- Mid-score instrument changes
- Transposition handling across changes
- Percussion kits
- Condensing and divisi
3. Architecture Overview
3.1 System Architecture
3.2 Data Flow
3.3 The Scale Problem
| Score Type | Parts | Measures | Events | MRS-S Size | Tokens |
|---|---|---|---|---|---|
| Lead sheet | 1 | 32 | ~200 | ~8 KB | ~2K |
| Piano sonata | 2 | 300 | ~5,000 | ~150 KB | ~40K |
| String quartet | 4 | 400 | ~8,000 | ~250 KB | ~65K |
| Chamber orchestra | 25 | 500 | ~50,000 | ~1.5 MB | ~400K |
| Full orchestra | 90 | 1000 | ~200,000 | ~6 MB | ~1.5M |
4. MRS-S: The Canonical Storage Format
MRS-S is an S-expression format optimized for complete semantic fidelity, human readability, and archival quality.4.1 Document Structure
overlays, alternatives, and layout are REQUIRED. Sections MUST appear in the order shown.
4.2 Version Declaration
4.3 Metadata Section
Required Metadata Fields
| Field | Type | Description |
|---|---|---|
:title | string | Primary title of the work |
Optional Metadata Fields
| Field | Type | Description |
|---|---|---|
:subtitle | string | Secondary title |
:composers | [string] | List of composer names |
:arrangers | [string] | List of arranger names |
:copyright | string | Copyright notice |
:key | pitch-class | Default key (A-G with optional #/b) |
:mode | keyword | major, minor, dorian, etc. |
:time | fraction | Default time signature |
:tempo | integer | Default tempo in BPM |
:tempo-text | string | Tempo marking text |
4.4 Measures Section
Measure Attributes
| Attribute | Required | Type | Description |
|---|---|---|---|
:id | YES | UUIDv7 | Stable identifier |
:number | YES | integer | Display number (can have gaps) |
:beat-start | YES | rational | Absolute beat position (orchestrator-computed) |
:time | NO | fraction | Time signature (inherits if omitted) |
:key | NO | pitch-class | Key signature (inherits if omitted) |
:tempo | NO | integer | Tempo in BPM (inherits if omitted) |
4.5 Event Syntax
| Component | Description |
|---|---|
: | Event marker |
<beat> | Beat position within measure (0-indexed, exact rational) |
<pitch-expr> | Pitch with duration, chord, or rest |
:id | Stable UUIDv7 identifier (REQUIRED) |
<properties> | Optional :keyword value pairs |
:at field (absolute position) is NOT required in storage. It is computed by the orchestrator when needed:
Pitch Expression
Duration Codes
| Code | Name | Beats |
|---|---|---|
w | Whole | 4 |
h | Half | 2 |
q | Quarter | 1 |
e | Eighth | 1/2 |
s | Sixteenth | 1/4 |
t | Thirty-second | 1/8 |
. (e.g., q. = 3/2 beats)
Double-dotted: append .. (e.g., q.. = 7/4 beats)
Rational Beat Positions
Beat positions MUST be exact rationals. The canonical form is:2.5) are NOT permitted.
Event Properties
| Property | Type | Description |
|---|---|---|
:dyn | keyword | Dynamic marking |
:art | keyword | Articulation |
:orn | keyword | Ornament |
:tech | keyword | Playing technique |
:lyrics | list | Lyric syllables |
:grace | boolean | Grace note flag |
:cue | boolean | Cue note flag |
:cue-source | instrument-id | Source instrument for cue |
4.6 Spans Section
Spans define relationships between events across time.Span Types
| Type | Endpoint Style | Description |
|---|---|---|
slur | from/to | Phrasing slur |
tie | from/to | Tie between same pitches |
hairpin | from/to | Crescendo/diminuendo |
beam | events list | Beam grouping |
ottava | from/to | Octave transposition |
pedal | from/to | Piano pedal |
trill-span | from/to | Extended trill |
gliss | from/to | Glissando line |
volta | from/to | Ending bracket |
4.7 Tuplet Syntax
4.8 Grace Notes
4.9 Directions
4.10 Movements
4.11 Alternatives (Ossia, Variants)
4.12 Layout Hints (Optional)
Layout hints are NON-NORMATIVE suggestions for rendering engines.5. MRS-Ops: The Mutation Protocol
MRS-Ops is the typed operation protocol for agent mutations. Agents read MRS-S but write MRS-Ops.5.1 Design Rationale
Asking agents to emit complete MRS-S fragments creates failure modes:- Accidental omission: Agent returns less content than given → content deleted
- Calculation errors: Miscomputed
:atvalues, duration sums - Hallucinated references: IDs that don’t exist
- UUID management: Agent must generate valid, non-colliding UUIDs
- Explicit operations: Create, update, delete are distinct (no omission risk)
- Orchestrator-derived fields: Agent provides beat; orchestrator computes
:at - Temporary IDs: Agent uses tmp-ids; orchestrator assigns UUIDs
- Minimal surface: Only changed content in output
5.2 Operation Envelope
| Field | Required | Description |
|---|---|---|
:version | YES | Protocol version |
:scope-hash | YES | Hash of source Working Set (conflict detection) |
:base-revision | NO | Revision ID of source state |
:ops | YES | List of operations |
5.3 Operation Types
5.3.1 Create Event
| Field | Required | Description |
|---|---|---|
:tmp-id | YES | Temporary ID (orchestrator maps to UUID) |
:measure | YES | Target measure UUID |
:instrument | YES | Target instrument ID |
:voice | YES | Target voice |
:beat | YES | Beat position (rational) |
:pitch | YES | Pitch or chord or r for rest |
:duration | YES | Duration code |
| Other properties | NO | :dyn, :art, :orn, etc. |
5.3.2 Update Event
| Field | Required | Description |
|---|---|---|
:id | YES | Existing event UUID |
:set | YES | List of (field value) pairs to update |
5.3.3 Delete Event
5.3.4 Create Span
- Existing UUIDs:
#uuid "018c3f2a-..." - Temporary IDs from same operation set:
"e1"
5.3.5 Update Span
:from, :to, :events) are immutable after creation. To change endpoints, delete and recreate the span.
5.3.6 Delete Span
5.3.7 Create Measure
- Assigns UUID and
:number - Computes
:beat-startbased on position - Updates subsequent measures if needed
5.3.8 Delete Measure
5.3.9 Instrument Change
5.4 Temporary ID Rules
- Temporary IDs MUST be strings starting with a letter:
"e1","span-a","m1" - Temporary IDs are scoped to a single MRS-Ops envelope
- Operations within the same envelope MAY reference each other’s tmp-ids
- The orchestrator maps all tmp-ids to UUIDs before application
- Responses include the tmp-id → UUID mapping
5.5 Operation Ordering
Operations are applied in order. Dependencies must be respected:- Create measure before creating events in it
- Create events before creating spans that reference them
5.6 Example: Add Countermelody
Agent receives Working Set with clarinet part (empty) and violin melody (in context). Agent returns:6. Players, Instruments, and Staves
MRS uses a three-level model for professional orchestration semantics.6.1 The Model
6.2 Players Section
| Attribute | Required | Description |
|---|---|---|
:name | YES | Display name |
:instruments | YES | List of instrument IDs this player uses |
:default | YES | Default/starting instrument |
6.3 Instruments Section
| Attribute | Required | Description |
|---|---|---|
:name | YES | Full display name |
:abbr | YES | Abbreviated name |
:family | YES | Instrument family |
:staves | YES | List of staff clefs |
:transposition | YES | Transposition interval or none |
:range | NO | Playable range [low high] |
:staff-connect | NO | brace, bracket, line |
6.4 Transposition Specification
6.5 Instrument Changes
When a player switches instruments mid-score:- Validates the player owns the target instrument
- Handles transposition changes automatically
- Updates display (instrument name in score)
6.6 Percussion Kits
6.7 Referencing in Measures
In measure content, use instrument ID (not player ID):7. Working Set Envelope
The Working Set Envelope provides agents with bounded MRS-S content plus task-appropriate context.7.1 Envelope Structure
7.2 Envelope Fields
Required Fields
| Field | Type | Description |
|---|---|---|
:version | decimal | Envelope version (1.0) |
:source-hash | string | SHA-256 hash of source state |
:scope | scope-spec | What the agent may modify |
:content | MRS-S | The score fragment (readable, target of ops) |
Scope Specification
Permission Fields
| Field | Description |
|---|---|
:bundle | Lane bundle granting permissions |
:allowed-ops | Explicit list of permitted operation types |
Optional Fields
| Field | Type | Description |
|---|---|---|
:task | string | Natural language task description |
:constraints | list | Validation rules agent must satisfy |
:context-views | list | Task-adaptive context (see §8) |
:structural-index-ref | string | Hash reference to structural index |
:available-queries | list | Queries agent may request |
7.3 Content Self-Containment
The:content of a Working Set Envelope MUST be parseable as standalone MRS-S:
- Instrument definitions MUST be included
- Time/key/tempo state at extraction start MUST be declared
- Spans MUST have both endpoints within scope OR be marked with boundary markers
7.4 Boundary-Crossing Spans
When a span crosses the envelope boundary::from, :to, or :events of boundary-marked spans.
8. Task-Adaptive Context Views
Context views provide task-relevant information beyond the edit scope. Unlike fixed “near/far” rings, views are selected and shaped for the specific task.8.1 Design Rationale
Different tasks need different context:- Countermelody: The melody being responded to, harmonic rhythm
- Orchestration: What other instruments are playing, texture density
- Dynamics: Phrase structure, existing dynamics, climax points
- Slur shaping: Articulation context, phrase groupings
8.2 Context View Types
8.2.1 Melodic Reference
Provides the melody line(s) the agent should respond to:8.2.2 Harmonic Context
Provides harmonic information (chord symbols, key areas):8.2.3 Orchestration Map
Shows what instruments are active and their texture:8.2.4 Phrase Structure
Provides phrase boundaries and form:8.2.5 Dynamics Profile
Provides dynamics trajectory:8.2.6 Thematic References
Provides motif/theme information:8.3 View Selection by Task Type
The orchestrator selects context views based on task type:| Task Type | Typical Context Views |
|---|---|
compose | phrase-structure, harmonic-context, thematic-references |
countermelody | melodic-reference, harmonic-context, phrase-structure |
orchestrate | orchestration-map, dynamics-profile, melodic-reference |
harmonize | melodic-reference, phrase-structure |
dynamics | phrase-structure, dynamics-profile, orchestration-map |
articulate | phrase-structure, melodic-reference |
8.4 Available Queries
Agents may request additional context via queries:9. Structural Index
The Structural Index provides global awareness without loading the full score.9.1 Index Structure
9.2 Index Fields
| Field | Description |
|---|---|
:form | Structural sections (exposition, development, etc.) |
:key-areas | Key signature regions |
:tempo-map | Tempo changes |
:players-summary | Players and their activity |
:rehearsal-marks | Rehearsal mark locations |
:total-measures | Total measure count |
:total-duration | Approximate duration |
9.3 Index Derivation
The structural index can be:- Derived automatically from the score (partial)
- Enhanced by overlays (harmonic analysis, thematic analysis)
- Manually annotated (form labels, section names)
10. Analytical Overlays
Overlays attach analytical metadata to score regions without modifying the score itself.10.1 Overlay Structure
10.2 Overlay Types
| Type | Purpose |
|---|---|
harmonic | Chord symbols, Roman numerals, functions |
thematic | Motifs, themes, their occurrences |
form | Structural analysis (phrase, period, section) |
voice-leading | Part writing analysis |
performance | Performance annotations |
10.3 Overlay Lifecycle
Overlays may be:- Persistent: Stored with the score
- Session: Valid only for current editing session
- Derived: Recomputed after score changes
11. Data Model
11.1 Core Types
11.2 Identifier Rules
- UUIDs: All measures, events, and spans carry UUIDv7 identifiers under
:id - Instrument IDs: Match regex
[a-z][a-z0-9-]*(e.g.,flute-1,clarinet-bb) - Player IDs: Match regex
[a-z][a-z0-9-]*(e.g.,woodwind-2,percussion-1) - Voice IDs:
v1throughv4, or:rh/:lhfor keyboard - Temporary IDs: Strings starting with letter, scoped to operation envelope
11.3 Immutability Rules
Once assigned::idis immutable for the lifetime of the object- Span endpoints (
:from,:to,:events) are immutable - Measure
:beat-startis orchestrator-managed (not directly editable)
11.4 Rational Number Representation
All temporal positions use exact rationals:12. Orchestrator Contract
The orchestrator is the central coordinator that makes AI-assisted composition and orchestration safe and reliable.12.1 Orchestrator Responsibilities
| Responsibility | Description |
|---|---|
| UUID minting | Maps tmp-ids to UUIDs; sole authority for ID creation |
| Derived fields | Computes :beat-start, reconciles inherited state |
| Validation | Progressive validation of all operations |
| State management | Maintains canonical score state; applies validated changes |
| Context generation | Creates task-adaptive context views |
| Conflict detection | Uses source-hash to detect concurrent modifications |
| Audit trail | Records all changes with attribution |
12.2 Edit Lanes
Lanes are permission boundaries that determine what an agent may modify.| Lane | Owns |
|---|---|
structure | Measure list, sections, movements |
temporal | Tempo map, time signatures |
harmonyPlan | Chord symbols, harmonic analysis |
notes | Pitches, durations, rests |
expression | Dynamics, hairpins, slurs |
technique | Articulations, playing techniques |
lyrics | Lyrics, syllables |
12.3 Lane Bundles
Common workflows grant multiple related lanes:12.4 Conflict Detection
The orchestrator uses source-hash to detect conflicts:12.5 Transaction Model
12.6 Checkpoints and Locks
Lock approved decisions to prevent regression:13. Progressive Validation
Operations are validated in stages before application.13.1 Validation Pipeline
13.2 Validation Stages
Stage 1: Syntax Validation
- Operation is well-formed
- Required fields present
- Types correct
Stage 2: Reference Validation
- All referenced UUIDs exist in source
- All tmp-ids are unique within envelope
- Cross-references between ops are valid
Stage 3: Permission Validation
- Operation within granted lanes
- Operation within granted scope
- Operation type is allowed
Stage 4: Musical Rule Validation
- Constraints satisfied (range, avoid parallel fifths, etc.)
- Duration sums correct
- Ties connect same pitches
13.3 Validation Results
13.4 Partial Application
When some operations fail validation:13.5 Validation Rules
Structural Rules
| Rule | Severity | Description |
|---|---|---|
| STRUCT-001 | ERROR | Duplicate UUIDs |
| STRUCT-002 | ERROR | Invalid measure numbers |
| STRUCT-003 | ERROR | Beat position out of bounds |
| STRUCT-004 | ERROR | Reference to non-existent UUID |
| STRUCT-005 | WARNING | Gap in measure numbering |
Musical Rules
| Rule | Severity | Description |
|---|---|---|
| MUSIC-001 | ERROR | Tie connects different pitches |
| MUSIC-002 | ERROR | Duration overflow (exceeds measure) |
| MUSIC-003 | WARNING | Pitch out of instrument range |
| MUSIC-004 | WARNING | Parallel fifths/octaves |
| MUSIC-005 | WARNING | Voice crossing |
Permission Rules
| Rule | Severity | Description |
|---|---|---|
| PERM-001 | ERROR | Operation outside granted lanes |
| PERM-002 | ERROR | Operation outside granted scope |
| PERM-003 | ERROR | Operation type not allowed |
| PERM-004 | ERROR | Modifying locked lane |
14. Query Resolution
The orchestrator translates human-friendly references to UUIDs.14.1 Query Types
Measure number resolution:14.2 Reverse Resolution
UUID to display information:15. Extension Mechanisms
15.1 Custom Properties
Events, spans, and directions support custom properties withx- prefix:
15.2 Namespace Extensions
| Namespace | Purpose |
|---|---|
x-* | Unregistered extensions |
analysis:* | Music theory analysis |
mei:* | MEI compatibility |
midi:* | MIDI-specific data |
render:* | Rendering hints |
edit:* | Editorial metadata |
16. MIME Types and File Extensions
16.1 MIME Types
| Format | MIME Type |
|---|---|
| MRS-S | application/vnd.mrs+sexpr |
| MRS-Ops | application/vnd.mrs-ops+sexpr |
| Working Set Envelope | application/vnd.mrs-workset+sexpr |
16.2 File Extensions
| Format | Extension |
|---|---|
| MRS-S | .mrs or .mrs-s |
| MRS-Ops | .mrs-ops (typically ephemeral) |
| Working Set | .mrs-workset (typically ephemeral) |
16.3 Encoding
MRS documents MUST be encoded in UTF-8. BOM SHOULD NOT be used.17. Security Considerations
17.1 Input Validation
Parsers MUST validate:- Maximum document size
- Maximum nesting depth
- Maximum event count per measure
- Valid Unicode in strings
17.2 Denial of Service Protection
Implementations SHOULD protect against:- Deeply nested structures
- Very large measure numbers
- Excessive span counts
- Malformed UTF-8
17.3 Information Disclosure
Working Set Envelopes may expose:- Source document structure
- Source document hash
- Creator/modifier identity
Appendix A: Complete Grammar
A.1 MRS-S Key Productions
A.2 MRS-Ops Key Productions
Appendix B: Quick Reference
B.1 Duration Codes
| Code | Name | Beats |
|---|---|---|
w | Whole | 4 |
h | Half | 2 |
q | Quarter | 1 |
e | Eighth | 1/2 |
s | Sixteenth | 1/4 |
t | 32nd | 1/8 |
x | 64th | 1/16 |
B.2 Dynamics
B.3 Articulations
B.4 Ornaments
B.5 Lane Bundles
| Bundle | Lanes |
|---|---|
orchestrate | notes, expression, technique |
dynamics-pass | expression |
notation-cleanup | notes, technique |
full-compose | structure, temporal, harmonyPlan, notes, expression, technique |
B.6 Context View Types
| View | Purpose |
|---|---|
melodic-reference | Melody to respond to |
harmonic-context | Chord progression |
orchestration-map | Active instruments, texture |
phrase-structure | Phrase boundaries |
dynamics-profile | Dynamics trajectory |
thematic-references | Themes and motifs |
Appendix C: Glossary
| Term | Definition |
|---|---|
| Agent | An AI system that operates on MRS documents |
| Context View | Task-adaptive information beyond the edit scope |
| Event | An atomic musical occurrence with UUID identity |
| Instrument | A specific sound source with fixed transposition/range |
| Lane | A permission boundary for a category of content |
| Lane Bundle | A predefined set of lanes for common workflows |
| Measure | A metrical unit with UUID identity |
| MRS-Ops | Typed operation protocol for agent mutations |
| MRS-S | Canonical storage format (S-expression based) |
| Orchestrator | System that owns canonical state and applies changes |
| Overlay | Analytical metadata attached to score regions |
| Player | A performer who may play multiple instruments |
| Progressive Validation | Multi-stage validation before state mutation |
| Scope | UUID-based boundaries of a Working Set |
| Span | A relation connecting multiple events |
| Structural Index | Compressed global view of the score |
| Temporary ID | Agent-assigned ID mapped to UUID by orchestrator |
| Working Set | Bounded MRS-S fragment with task-adaptive context |
End of Specification