Whitepaper
The whitepaper is where BitCal states the redesign thesis clearly enough to be challenged. It is organized around one architectural spine instead of around feature lists.
System architecture spine
The whitepaper therefore answers three questions in sequence: what the public model is, how algorithms are organized, and where the contract stops so dispatch and kernels may evolve.
Public model
Start with the public model page. It explains why BitCal treats owner, view, and algorithm as distinct public roles instead of as methods hanging from a single object.
Algorithm organization
Continue with algorithm design. That page explains why free algorithms are the behavioral center, how algorithm families are grouped, and why observable semantics come before backend discussion.
Dispatch and support boundary
Finish the thesis layer with dispatch and kernels. That page defines what belongs above the contract line, what remains implementation freedom, and how the x86-64-first support posture constrains documentation.
Owner, view, algorithm, and the stable include seam.
Read this first if you need to know what the public vocabulary actually is.
How free algorithms organize the contract surface.
This page explains family structure, semantics-first wording, and why borrowing is first-class.
Where implementation freedom begins and support claims narrow.
Readers should understand this boundary before reading performance numbers.
Leave the thesis layer and inspect the retained baseline and methodology.
The whitepaper intentionally hands off to performance rather than embedding benchmark claims inside architecture prose, and ARM rows stay blank until retained benchmark evidence exists.