THE PLATFORM

Kernels

A kernel is a named computational problem: one well-defined capability that can be specified, implemented several ways, and measured. Polynomial Multiplication is a kernel. So is Number Theoretic Transform, so is CKKS Bootstrapping, so is Private Set Intersection.

A kernel fixes what must stay the same in every variant of the problem:

kernel polymult<type T: Numeric, N: u32>(
    %a: tensor<N x T>,
    %b: tensor<N x T>,
) -> %c: tensor<N x T>

The arity, the visibility of each argument (secret or public), and the logical shape of the data. Everything else is deliberately absent — parameter values, memory representation, mechanism, scheme, library, code, the correctness rule. That absence is what lets one problem have an FHE answer, an MPC answer and a plain answer, all reading as answers to the same question.

What a kernel is not

Not source code. A kernel has implementations; it is not one of them.

Not a repository. A repository holds one implementation, at one version, in one language.

Not tied to a language, a library, a hardware platform or an optimisation strategy. All four are properties of an implementation, and two implementations of one kernel routinely differ in all four at once.

A kernel may exist before any implementation does. Naming the capability is useful on its own: it gives specifications somewhere to attach, and it makes a gap in the ecosystem a thing that can be pointed at.

Levels

Every kernel sits at one layer of abstraction:

		examples
`L1`	MATH	modular reduction, NTT, polynomial multiplication, matrix multiplication
`L2`	CRYPTOGRAPHIC COMPONENTS	CKKS key switching, bootstrapping, polynomial commitment
`L3`	ADVANCED CRYPTOGRAPHY	FHE, ZK, MPC, PIR, PSI, PQC
`L4`	APPLICATION COMPONENTS	ReLU, sign, max, lookup over encrypted values
`L5`	PRIVACY-PRESERVING APPLICATIONS	confidential payments, private inference, private analytics

Layers order the catalogue and make the dependency graph readable: an L4 kernel is usually stated in terms of L1 kernels.

The graph

Kernels declare what they build on — depends_on, composes, alternative_to. This is a statement of dependence between problems, not a call graph: CKKS Bootstrapping composes Key Switching and NTT whether or not a particular implementation calls either.

The graph runs both ways on a kernel's page: what this kernel builds on, and what is used by it — the kernels above it, which are wrong or slow whenever it is.

Lifecycle

A kernel is proposed as a draft, visible only to its author. Handing it to a reviewer freezes it — nobody edits under review, including the author — and a published kernel is expected to change rarely, if ever. Specifications are where the problem evolves; the kernel is the name that holds them together.