Focus model card on published keyboard models and direct correction pilot

README.md

@@ -24,11 +24,9 @@ Chime is a small English model that predicts the next word and completes the wor
 
 **2.03M parameters · 2.22 MB int8 · 161.6M training words · 2h 2m on one A100 · 3.09–3.24 ms warm p95 on two Pixels**
 
-Chime offers **41.4% potential keystroke savings on SMS** and **59.5% on typed requests**, versus 31.6% and 45.5% for LocalType’s previous word-pair predictor with corpus counts. That is about 31% more potential savings on both development sets. These are simulated ceilings on data used for checkpoint selection, not observed savings in everyday typing.
+Chime uses the CIFG recurrent architecture described for Gboard in 2018. Its 2.03M parameters sit alongside the published 1.4M model (2018) and 2.4–4.4M next-word models (2023). This compares published model sizes, not current installed models or prediction accuracy. [Keyboard comparisons and shareable cards](https://dr.eamer.dev/chime/writeup.html) report the separate physical correction pilot.
 
-On two physical Pixels, switching Chime on changed every recorded prediction list in the **59 comparable ordinary-field pairs**. All **48 clean controls** remained unchanged; **672/672 characters** arrived correctly in protected delivery controls, where Chime is excluded. [The write-up](https://dr.eamer.dev/chime/writeup.html#phone-comparison) separates these observations from prediction accuracy and automatic correction.
-
-![Comparison card: 2.03M parameters, 2.22 MB, 161.6M training words, 2h 2m on one A100. Bar chart of potential keystrokes saved on checkpoint-selection development text. Text messages: word frequency only 28.0%, n-gram ranker 28.8%, n-gram ranker with corpus prior 31.6%, Chime-SMS-2M 41.4%. Task requests: 37.6%, 39.1%, 45.5% and 59.5%.](comparison.png)
+![Published next-word models: Chime 2.03M parameters, 2.22 MB; Gboard 2018 1.4M, 1.4 MB; Gboard 2023 2.4–4.4M for 10K–20K next-word vocabularies, file size not reported. No matched next-word accuracy comparison has been run.](comparison.png)
 
 ## Model details
 
@@ -57,39 +55,24 @@ A trailing space asks for the next word; without one, the last word is completed
 
 `cifg_int8.bin` is the int8 model with its vocabulary, the file LocalType ships, and `read_bin` in `inference.py` reads both. `model.safetensors` holds the float32 weights; `config.json` lists their shapes.
 
-## Development prediction comparison
-
-Each ranker was scored by the same code on development text Chime was not trained on: 463 lines of the NUS SMS corpus and 567 written requests from Taskmaster-1, with nothing learned about the person typing. *Keystrokes saved* counts the characters skipped by tapping the right word as soon as it appears among three suggestions. *Top 3* is how often the next word is one of the first three suggestions.
-
-| Ranker | Keystrokes saved, SMS | Keystrokes saved, Taskmaster-1 | Top 3, SMS | Top 3, Taskmaster-1 |
-| --- | ---: | ---: | ---: | ---: |
-| Word frequency only | 28.0% | 37.6% | 6.1% | 9.0% |
-| N-gram ranker | 28.8% | 39.1% | 7.3% | 11.1% |
-| N-gram ranker with corpus prior | 31.6% | 45.5% | 12.8% | 23.9% |
-| **Chime-SMS-2M** | **41.4%** | **59.5%** | **19.3%** | **42.3%** |
-
-Against the strongest baseline, Chime offers about 31% more potential keystroke savings on both sets. The same lines were used to choose the checkpoint, so these are development results, not a held-out test.
+## Comparison with other keyboards
 
-On a Pixel 9a and a Pixel 10, one next-word prediction takes 3.1 to 3.2 ms at the 95th percentile while the sentence's state is kept, and 6.7 to 7.6 ms from a fresh sentence, in plain Kotlin with no inference runtime.
+The architecture comparison comes from [Hard et al. (2018)](https://arxiv.org/abs/1811.03604) and [Xu et al. (2023)](https://arxiv.org/abs/2305.18465). These papers describe generations of Gboard models, not necessarily the model in a current installation. Chime and Gboard have not been scored on a matched next-word evaluation. Different papers’ data and metrics cannot establish an accuracy ranking.
 
-## Physical keyboard comparison — October 8, 2026
+A separate automated touch pilot compared installed LocalType 0.5.9 (29) with Gboard 18.4.1.985164140-beta-arm64-v8a on 42 invented inputs per keyboard per phone. No-learning fields excluded Chime; existing personal state was retained.
 
-The same 42 invented inputs were typed with Chime on and off on a Pixel 9a and a Pixel 10: **168 observations**. LocalType 0.5.9 (29) ran in an isolated test installation; personal learning started empty before each case. The only preference difference between arms was Chime. Ordinary web fields enabled correction and learning, while protected delivery fields excluded inference and learning. Both phones ran Android API 37.
-
-| Phone | Isolated repairs, Chime off | Isolated repairs, Chime on | Clean controls, both arms | Protected delivery, both arms |
-| --- | ---: | ---: | ---: | ---: |
-| Pixel 9a | 12/12 | 12/12 | 24/24 unchanged | 24/24 exact |
-| Pixel 10 | 11/12 | 12/12 | 24/24 unchanged | 24/24 exact |
-
-No wrong isolated replacements occurred. Live neural suggestions were verified in all 60 eligible on-arm observations. Among the 59 ordinary pairs with identical final editor text, every post-typing prediction list differed. For example, after `please right `, Chime offered `away / now / ahead`; the non-neural arm offered `to / now / away`, on both phones.
+| Phone | LocalType isolated repairs | Gboard isolated repairs |
+| --- | ---: | ---: |
+| Pixel 9a | 11/12 | 12/12 |
+| Pixel 10 | 9/12 | 11/12 |
 
-**What this establishes:** inference is active and changes the displayed predictions while the shared keyboard preserves the tested clean text and character delivery. **What it does not establish:** prediction accuracy, realized typing savings, a causal autocorrection improvement, physical input latency or everyday acceptance. Neither arm tapped predictions or scored a next-word target. Both use the same immediate autocorrect code; the single repair difference (`adn` on Pixel 10) is not an effect estimate. Contextual repairs remain manual offers.
+Neither keyboard made a wrong replacement in the isolated typo cases. Both preserved all 48 ordinary clean controls and 672 characters in 48 protected delivery cases. In the separate identifier probe, LocalType changed `xkcd` to `did` on both phones; Gboard preserved it. Gboard added the apostrophe in `lukes keyboard`; LocalType left it unchanged. This is a small correction and delivery pilot, not a test of Chime’s next-word quality. [Methods and remaining phrase outputs](https://dr.eamer.dev/chime/methods.html#phone-comparison).
 
-All four arm/phone combinations changed `thjs is rifhr` to `this is right` and `dont` to `don't`, but left `lukes keyboard` unchanged and only repaired the second word of `woed xorrextion`. The identifier `xkcd` became `did`; brand knowledge is not assumed before personal learning. These gaps are reported separately from ordinary clean controls.
+## Development prediction measurements
 
-An earlier LocalType/Gboard pilot used no-learning fields, which disable Chime, and retained existing personal state. It found 11/12 and 9/12 isolated repairs for LocalType versus 12/12 and 11/12 for Gboard on the 9a and 10. Its different protocol prevents combining those numbers with the Chime run into a model ranking.
+On 463 NUS SMS development lines, Chime scored 41.44% potential keystroke savings and 19.32% next-word top-three accuracy. On 567 Taskmaster-1 requests it scored 59.50% and 42.34%. The same Kotlin scorer started with no personal learning. Potential savings assumes the correct word is tapped as soon as it appears among three suggestions, so it is a simulated ceiling. These lines were not training text but were used to select the checkpoint; no held-out or everyday savings result is claimed. These measurements cannot be compared with correction counts or another keyboard’s prediction scores on different data.
 
-The frozen Chime input manifest is SHA-256 `1fafed180442028ad2a094f72add1d92105ac47baf95e23467e7c560f4161224`, with test source `f76cef3`. The model hash below pins the checkpoint used. All 367 preserved evidence files passed checksum verification. The [write-up](https://dr.eamer.dev/chime/writeup.html#phone-comparison) gives the method, phrase results and limits.
+A separate ordinary-field integration pilot verified live Chime predictions in all 60 eligible observations, with empty isolated learning before each case. It preserved the tested clean text and protected delivery controls. No next-word target was scored or prediction tapped. Different field and learning policies prevent combining that run with the Gboard pilot into a model ranking.
 
 ## Runtime comparison
 
@@ -140,8 +123,6 @@ I trained it from scratch for three passes (102,195 updates) on one A100 in abou
 
 ×8 means repeating NUS SMS, Taskmaster-1 and OpenAssistant lines eight times per pass, while Taskmaster-3 and SODA appear once. It changes exposure, not parameter count or context size. Human-written lines form 12.868% of the weighted pass; SODA remains the majority. Repeated tokens are not additional unique data. The earlier ×4 checkpoint has the same architecture and is retained for comparison and rollback.
 
-On the same Kotlin development scorer, ×4/×8 potential savings were 40.70/41.44% on SMS and 58.61/59.50% on Taskmaster-1. Paired differences were +0.73 percentage points [95% interval +0.40, +1.07] and +0.89 [+0.62, +1.17]. The mostly synthetic 5,000-line sample fell from 65.04% to 64.93% (−0.12 points [−0.17, −0.06], using unrounded scores). These checkpoints differ in training backend and update count, so the comparison does not isolate oversampling. Intervals use 2,000 line-bootstrap resamples; dialogue clustering and SMS sender overlap limit their interpretation.
-
 ## Limitations
 
 - English only. Suggestions reflect older Singapore texting, task dialogue, assistant prompts and synthetic dialogue, and the fixed vocabulary will not learn new words or names.