npu-lax: state the parity protocol (NPU routing adopted)

[bong-water-water-bong]

The engine said "parity against fp64" for the 35B NPU decode without saying how the reference was run.

make_decode.py (OpenFlowLM-Next, at the engine's pin 2490fa6) re-uses the NPU's expert choice wherever a previous NPU run's router disagrees with the reference's own top-8. It prints each disagreement, and --strict-routing opts out. That's the right protocol for checking the arithmetic, because a near-tie in the 8th slot can't then look like a numerical error. But it doesn't measure the routing decisions themselves.

This PR says so in the README and docs/npu-lax.md. A --strict-routing run, which measures routing agreement, is a separate number and isn't recorded yet. No code change.

🤖 Generated with Claude Code

[context7]

Docs7 for 1bit-monster/engine

Result	Status	Action
Deployment	➖ Not used	—
Content review	➖ Did not run. This site has no agent runs available this month. Wait for the monthly reset or check your Docs7 plan.	—

Commit 0143c7e

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Ambiguous Parity Claim The documentation states that the NPU's arithmetic matches an fp64 reference "given the same routed experts" and that the reference adopts the NPU's expert choice where they differ. However, it does not clearly specify how the "same routed experts" are ensured or whether this is consistently applied across all test cases. This ambiguity could lead to inconsistent interpretation of what constitutes a valid parity check, especially when the NPU and reference disagree on expert selection. It matches an fp64 reference given the same routed experts (the reference adopts the NPU's expert choice where they differ; "Parity" below), and it decodes at 16.3-16.5 tok/s. Missing Routing Agreement Measurement The documentation notes that make_decode.py --strict-routing measures routing agreement, which is a separate metric from arithmetic parity. However, it also states that this routing agreement number is "not yet recorded here." This creates a disconnect between the documented protocol and the actual tracking of performance metrics, potentially leading to confusion about the completeness of the benchmarking effort. decisions. `make_decode.py --strict-routing` keeps the reference's own top-8. A run with it measures routing agreement, which is a separate number, not yet recorded here.