Source: https://guthlabs.ai/docs/instruments/transposition-calculator/mechanism/

instrument mechanism / verified-clean

# Transposition Calculator mechanism

The inspectable method record for Transposition Calculator, kept separate from implementation and qualification.

Status: **VERIFIED_CLEAN**Lifecycle: **verified-clean**

## Model scope

The core chromatic pitch-class calculation is correct. The instrument should not claim fully correct note/chord transposition until it documents accepted note and chord syntax, key-mode handling, enharmonic spelling rules, octave behavior, and the exact meaning of preserving letter names. Honest labeling should distinguish pitch-class transposition from complete notation-aware chord transposition.

- The pitch-class formula newNote=(oldNote+semitoneShift) mod 12 is standard for chromatic transposition, but the phrase "preserving letter-naming rules" does not specify an exact note-spelling algorithm.

- Key-to-key transposition does not define how source and target key names, modes, and enharmonic spellings are converted to pitch classes; for example, C-sharp versus D-flat and B-sharp versus C can produce different output spellings.

- Chord handling is underspecified for chord qualities, extensions, slash chords, omitted tones, and whether spelling should follow strict interval-letter preservation or conventional chord spelling.

## Units and conventions

- Note pitch classes use C=0, C-sharp/D-flat=1, D=2, D-sharp/E-flat=3, E=4, F=5, F-sharp/G-flat=6, G=7, G-sharp/A-flat=8, A=9, A-sharp/B-flat=10, B=11.

- semitoneShift is an integer number of equal-tempered semitones; negative values transpose downward and values outside -11 through 11 are reduced modulo 12.

- Key-to-key shifts are calculated as target-tonic pitch class minus source-tonic pitch class, modulo 12.

- Outputs below assume conventional diatonic spelling where practical, with chord spelling chosen for the target key; the specification must document this policy.

## Inspectable vector

One of 4 source-bound review vectors:

````
{
  "inputs": {
    "notes": [
      "C",
      "E",
      "G"
    ],
    "source_key": "C major",
    "target_key": "D major"
  },
  "expected_outputs": {
    "semitone_shift": 2,
    "transposed_notes": [
      "D",
      "F-sharp",
      "A"
    ]
  },
  "working": "C=0, E=4, G=7. Target D=2 and source C=0, so shift=2-0=2 semitones. C: (0+2) mod 12=2=D. E: (4+2) mod 12=6=F-sharp. G: (7+2) mod 12=9=A. Result: D-F-sharp-A."
}
````

## Failure boundary

- A missing or non-integer semitone shift can make the modulo operation invalid or ambiguous.

- If note names are parsed without a defined accidental and enharmonic policy, outputs such as G-sharp versus A-flat cannot be verified uniquely.

- Key names without an explicitly supported mode and tonic spelling are ambiguous for output note naming.

- Pitch-class modulo 12 discards octave/register information; the specification should state whether octave numbers are preserved, shifted, or ignored.

- Chord symbols may contain quality, extensions, alterations, inversions, and slash bass notes that a simple note lookup table may not transpose correctly unless each component is parsed.

- A zero or full-octave shift is valid but must not be treated as missing input; division-by-zero is not applicable to this algorithm.

## Other records

[01**Overview**](<https://guthlabs.ai/docs/instruments/transposition-calculator/>)[03**Implementation**](<https://guthlabs.ai/docs/instruments/transposition-calculator/implementation/>)[04**Qualification**](<https://guthlabs.ai/docs/instruments/transposition-calculator/qualification/>)

## Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

- `VERIFIED_LEDGER.json`

- `evidence-tranche6/tranche6-results.json`