Dispatch and Kernels
BitCal documents dispatch as a support boundary, not as a personality trait. Readers need to know where implementation freedom begins, because that line defines which changes are architectural and which are merely backend work.
Dispatch boundary
Public contract versus implementation freedom
Kernel families
| Kernel family | Current documentation stance | Why it is separated |
|---|---|---|
| Scalar floor | Retained portability baseline | Gives the project a correctness floor even when no wide path is active. |
| AVX2 path | Primary evidence and optimization target | Current benchmark posture is concentrated here. |
| Future x86 variants | Mention only as design direction | They should not be overclaimed before retained evidence exists. |
Support boundary
Dispatch and kernels must respect the documented support posture:
- Linux / Windows x86-64 are the primary optimization and validation targets.
- Secondary targets may remain buildable, but must not inherit stronger claims than the retained evidence supports.
- Public documentation should mention backend detail only when it changes user-visible semantics, benchmark scope, or support boundaries.
What readers should carry forward
The dispatch layer is allowed to change aggressively as long as the public role model, algorithm semantics, and include seam remain coherent. That is why the next stop after this page is the Performance section: benchmark claims belong below this boundary, not above it.