What KGL is
KGL is a substrate — not a single application but a layer. It exposes the same matrix-state math the lab uses for research as primitives that work at the kernel boundary. A knowledge-graph ledger holds typed state, a scheduler routes work, and a BPF-based networking layer carries packets.
The point is to eliminate the seam between research math and systems plumbing: a Kuramoto-style scheduler, a Genesis-style state update, or a Sadalsuud-style router can be attached to a network path without leaving the kernel.
KGL Overlay — Tailscale-class data-plane
The first concrete artifact built on KGL is an overlay-network data-plane in the spirit of Tailscale / WireGuard. The data-plane has been validated end-to-end in a controlled environment: TLS handshake, packet flow, and route propagation between two network namespaces all succeed losslessly.
Open items are environmental, not algorithmic: a public NAT-traversal field test on commodity cloud hosts, and an admin-side ACL CLI (currently a stub). Both are bounded engineering tasks.
Why kernel-level
Most modern stacks push the math up to userspace and pay for it in syscalls and context switches. KGL goes the other way: lower the math to where the packets and pages already are. The result is a substrate where a research idea can be deployed as a kernel feature, not just modelled in a notebook.
What is not public
The KGL engineering surface — the ledger schema, scheduler hooks, BPF entry points, overlay wire format — is documented for partners. The math powering the routing and state-update kernels is patent-pending and stays inside the lab.