File size: 3,312 Bytes
fd0c04f | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 | # ADR-0001: Build a Verified Checkpoint from BF16 and Publish Fail-Closed
Status: Accepted
Date: 2026-07-20
## Context
The project currently references `sahilchachra/unlimited-ocr-mxfp8-mlx` as its
weight source. That checkpoint is already MXFP8. Re-uploading it with different
configuration or pipeline files improves runtime behavior but is not a new
weight optimization.
The existing repository also contains sensitivity and mixed-precision scripts,
but measured overrides have not been generated and the legacy upload workflow
does not require proof that candidate weights differ from the source.
## Decision
We will:
1. Use the upstream Baidu BF16 checkpoint as the only valid source for
sensitivity analysis and final conversion.
2. Use the Sahil MXFP8 checkpoint only as a comparative reference.
3. Generate the precision map from measured group-level OCR deltas.
4. Preserve high-risk optical and routing components in BF16 by default.
5. Quantize eligible language-tower linear modules to block-float MXFP8 with
group size 32.
6. Select the native `unlimited-ocr` MLX backend so R-SWA uses its bounded
ring/sliding cache rather than a legacy DeepSeek-OCR fallback.
7. Generate a signed-by-content release manifest containing hashes, versions,
metrics, and explicit pass/fail gates.
8. Make publication fail-closed: no approved manifest means no upload.
9. Publish under a new, provenance-clear repository:
`AutomatosX/AX-Unlimited-OCR-3B-MoE-MLX-MXFP8`.
## Sensitivity policy
A module group is retained in BF16 when any of these conditions is true:
- CER delta is greater than 0.02 absolute.
- Digit-CER delta is greater than 0.02 absolute.
- Table-score degradation is greater than 0.01 absolute.
- The group could not be measured reliably.
- It belongs to the protected optical/routing set.
Concrete exact-path overrides take precedence over wildcard MXFP8 rules.
## Alternatives considered
### Repackage the Sahil checkpoint
Rejected as the primary release path. It is useful for runtime tooling, but its
weights are not an AutomatosX optimization.
### Re-quantize the Sahil checkpoint
Rejected. Quantizing already quantized weights compounds error and prevents a
clean BF16 comparison.
### Uniform MXFP8 from BF16
Rejected as the final product because it does not use OCR sensitivity evidence.
It remains a useful control candidate.
### Per-layer exhaustive search
Deferred. It provides finer control but multiplies evaluation cost. Group-level
analysis is the first release; the data contract keeps concrete module paths so
a later release can promote individual layers.
### Publish first and benchmark later
Rejected. It would recreate the current ambiguity and allow unsupported claims.
## Consequences
Positive:
- The published checkpoint is demonstrably distinct and reproducible.
- Quality claims are tied to recorded evidence.
- Runtime improvements and weight improvements are clearly separated.
- A broken or incomplete benchmark cannot accidentally publish a model.
Negative:
- Release requires a representative evaluation dataset and Metal-capable Mac.
- Sensitivity analysis is compute intensive.
- Conservative BF16 retention may produce a larger model than uniform MXFP8.
- A failed R-SWA or accuracy gate intentionally delays publication.
|