Publish bounded matched-PCM native Slovenian diagnosis

coreml/NATIVE-SLOVENIAN-DIAGNOSTIC-20260924.md

@@ -0,0 +1,74 @@
+# Slovenian native/CoreML diagnostic — September 24, 2026
+
+**A known Slovenian script failure also occurs in the released native BF16 gateway. A second known case varies across inference paths. These three diagnostic cases do not establish a complete cause or an accuracy repair; Orukeet remains experimental.**
+
+This addendum preserves the original [full qualification](QUALIFICATION-20260924.md) and [consumer parity report](CONSUMER-PARITY-20260924.md). Their scores and original Float32 observations are unchanged. Full-split Slovenian results remain 23/834 INT8 versus 20/834 LUT6 outputs containing Cyrillic, including 16 versus 14 majority-Cyrillic outputs.
+
+## Matched cases and results
+
+Before running the native comparison, we selected the two previously exposed script cases and the first Slovenian recording in the frozen 400-clip panel as a control. All are public FLEURS `sl_si` test recordings. Three serial native requests and nine CoreML calls completed successfully. No language hint, prompt, reference text or text cleanup was supplied to the recognizer.
+
+Each cell below gives the observed script and fixed-reference word errors/reference words. “Latin” means no Cyrillic code point was detected; it does not establish correct Slovenian recognition.
+
+| Original FLEURS filename | Released native BF16 | CoreML INT8 | CoreML LUT6 | CoreML FP16 |
+|---|---|---|---|---|
+| `10566187729969396496.wav` | Cyrillic; 15/15 | Cyrillic; 15/15 | Cyrillic; 15/15 | Cyrillic; 15/15 |
+| `10749956690098540209.wav` | Latin; 9/14 | Cyrillic; 14/14 | Latin; 10/14 | Cyrillic; 14/14 |
+| `10451373259200168008.wav` — control | Latin; 1/17 | Latin; 1/17 | Latin; 1/17 | Latin; 1/17 |
+
+For the first case, native, INT8 and FP16 raw transcripts are identical. LUT6 wording differs but also uses Cyrillic. For the second, native and LUT6 both avoid Cyrillic but still have substantial word errors and differ from each other. INT8 and FP16 remain Cyrillic and also differ in wording. All four control transcripts are identical. Character errors follow the same ordering: first case 73/84 for native/INT8/FP16 and 75/84 for LUT6; second case 16/98 native, 19/98 LUT6 and 91/98 INT8/FP16; control 1/98 for all four.
+
+The first case rules out an explanation exclusive to CoreML or INT8 for that observed failure. The second demonstrates path sensitivity at the same checkpoint identity and matched PCM. This is not enough to attribute the difference to quantization, conversion, frontend numerics, padding, decoder behavior or the checkpoint alone. The native path uses BF16 and production optimizations; it is not an independent full-precision reference decoder.
+
+## Exact audio contract
+
+The gateway accepts signed PCM16. Original FLEURS Float32 samples were therefore converted once into a common, sealed representation before comparing paths:
+
+1. Decode each original WAV to Float32 at its original 16 kHz mono rate.
+2. Promote to Float64, multiply by 32,768, and apply `numpy.rint` (round halves to even).
+3. Clip to [−32,768, 32,767] and serialize as little-endian Int16.
+4. Reconstruct Float32 as `Int16 × (1/32768)` for the sample-level identity check.
+
+There was no resampling, manual padding or truncation. No samples clipped in any case. The maximum absolute change from original Float32 was `0.0000152587890625` for each recording. The native client and both CoreML audio converters independently reproduced the same reconstructed Float32 PCM hashes and exact sample counts. Native requests sent 100 ms PCM frames, unpaced, followed by commit; each case used a fresh account-bound WebSocket. This was an accuracy diagnostic, not a latency benchmark.
+
+| Filename stem | Samples | Values changed by PCM16 conversion |
+|---|---:|---:|
+| `10566187729969396496` | 110,400 | 110,175 |
+| `10749956690098540209` | 116,160 | 115,939 |
+| `10451373259200168008` | 107,520 | 107,288 |
+
+The first case's three CoreML transcripts match its original Float32 observations. In the second case, PCM16 changes INT8/FP16 wording but not the Cyrillic outcome; LUT6 wording is unchanged. The control matches the earlier INT8/LUT6 observations; there was no earlier FP16 control observation. None of these PCM16 observations replaces an original full-corpus row.
+
+## Source and runtime identity
+
+The released native service's on-disk checkpoint was freshly hashed in place: **SHA-256 `031c8ddab4845aeced904a7cde8e8aa57993b2e344716cf83a545b079c473b56`**, 2,509,342,720 bytes. It matches the CoreML export's recorded source checkpoint identity. This verifies the source file relationship, not bit-identical operations or intermediate activations across runtimes. No checkpoint was downloaded or copied.
+
+The native loader uses NeMo evaluation mode, BF16 encoder/decoder/joint, original FP32 FFT window/mel filters, BF16 frontend output, zero dither and `pad_to=0`. Its unconditioned `greedy_batch` decoder uses CUDA graphs and `max_symbols=10`. The released worker applies its existing native runtime optimizations. We used the already-running released EU gateway through its guarded acceptance path; no model, service or configuration changed. Language-identification events were recorded but never fed back to the recognizer. No cleanup route was used.
+
+CoreML reused the existing INT8, LUT6 and FP16 compiled artifacts with FluidAudio `ddc95f4d03d5be12bf84eeb6e4bde5b724356d88` and the report harness reproducing the consumer file-URL path. The same 300 ms silent Orukeet preparation warmup ran before each artifact's three real recordings, with fresh real-recording decoder state. The [consumer parity report](CONSUMER-PARITY-20260924.md) separately documents the warmup/state comparison.
+
+Runtime source SHA-256 receipts:
+
+| Component | SHA-256 |
+|---|---|
+| Native loader | `a8d25edbc75a14f6128dd4cec5c2930b229da15f33e78ff1e577a32c98f31ae4` |
+| Optimized native core | `39054f9c659d74970729666614538b12f16bf8d3e59ec3de447bcea25b82d560` |
+| Embedded native runtime | `961a5e1ba8416e5e9bc5f442471537f2d825cfbd62d125566e12c112c93945bb` |
+| Native PCM worker | `735459f17b4313fea07cadcbe89d2405dbdae57ee24e66cb96c03986776e117f` |
+| Local comparison executable | `f4d5025b281be3d0b60c850f13b531fd0378fa2c04cfe4894326fe3d6940036a` |
+
+## Audio identity receipts
+
+All hashes are SHA-256. PCM hashes cover raw sample bytes, without a WAV header.
+
+| Filename stem | Original WAV | Common little-endian PCM16 | Reconstructed little-endian Float32 |
+|---|---|---|---|
+| `10566187729969396496` | `d71724ae4879a82f809c7fa6dc1ccab0297adc3321a9c9b95e2f531a75f8cc41` | `c0bcdd20d139d6613e9cf35eed7f27d62fa5bfdfae8241ee79270adc8d85a262` | `28bdbb69e68008a0c1ab4030e9c3c70601575f2f0394061308c7f75ced350f47` |
+| `10749956690098540209` | `53a1a39da17728d688516a92865db961b6b601eb96d0a871f284d445236795ee` | `ff60b78a2a761804bd86baf2d40ee41426541f909e23414a41b24f59fde0cf5f` | `cb63cf4cf97ed5383f8ad827ce7014ae3db401a483f2acfdfb143ef10d9b610f` |
+| `10451373259200168008` | `748efeb11409163d03786eb64e75e335139cae8b168c2292aa0a3877ad8a261f` | `63b55344e433843d3bea1124f9b8a845b18dd7e45b3ae1f5023e3cdee91e885f` | `3bbf41d9d22006870c089a49cebd27c430964f62864233d2e5dab4ab54084619` |
+
+The sealed three-case manifest hash is `191d5720256f9c405c71f8503d3c25ab4be1ad9589179e67b8e137307ab69eb0`. Native result receipt: `0d1233e69139414683bfcf1119a4a0c0e0ac9fb604da72633ecc5dfc58251cd6`. CoreML result receipts: INT8 `6b6cc983bf0a822adebde0d29b12ae54ff2e4e7965491f466b6cebdaef59e8ec`, LUT6 `6cd853ee839bde5f1d4496744afaed2e0e828ce120e4052c90f26196be73e37e`, FP16 `a4335d6ffb66bdad07a0c42b850be69fa44792227daa52c217eb62953593bf84`.
+
+## Remaining gate
+
+Keep the release experimental and the original corpus evidence frozen. The next focused diagnosis should compare intermediate frontend, encoder and decoder outputs for the two failures, holding checkpoint, tokenizer, PCM and decoder settings fixed while isolating precision and runtime differences. A repair requires a separate development set and frozen, native-reviewed acceptance set, followed by regression checks. Generic transliteration cannot restore missing or wrong words. These three cases support neither a population-level native/CoreML accuracy comparison nor a physical-iPhone performance claim.

coreml/README.md

@@ -37,6 +37,11 @@ preparation warmup preserved every observed transcript, token timestamp and dura
 [Consumer call-path and warmup report](CONSUMER-PARITY-20260924.md). This bounded Mac
 check does not replace physical-iPhone or complete-app lifecycle acceptance.
 
+A separate matched-PCM three-case [native/CoreML diagnostic](NATIVE-SLOVENIAN-DIAGNOSTIC-20260924.md)
+reproduces one known Slovenian script failure in the native BF16 service and all CoreML
+profiles; a second varies across paths. Neither a complete cause nor an accuracy repair
+is established. Original corpus and consumer-parity scores are unchanged.
+
 Physical iPhone performance, thermal and microphone acceptance remains required. The archive
 itself is immutable; qualification updates are separate metadata, with no weight or decoder changes.
 

coreml/manifest.json

@@ -74,6 +74,15 @@
           "disk_backed_recordings_over_30_seconds": 64,
           "warmup_preserves_text_token_timings_duration": true,
           "scope": "bounded_mac_native_inference_reproduction_not_physical_iphone_acceptance"
+        },
+        "native_slovenian_diagnostic": {
+          "report": "NATIVE-SLOVENIAN-DIAGNOSTIC-20260924.md",
+          "cases": 3,
+          "observations": 12,
+          "audio": "common_sealed_pcm16",
+          "result": "one_known_failure_shared_across_native_and_coreml_another_path_sensitive",
+          "accuracy_repair_established": false,
+          "scope": "bounded_diagnostic_not_population_accuracy_comparison"
         }
       },
       "source_code_revision": "6c37c587fabcef8b0e932584fbf22a79fcb9d89e",