Kina.ai

Specification

Forward Tracks

Design commitments and research directions that extend Phase 0's foundation. These are not changes to the strict spec in phase-0/. They are architectural commitments — decisions about how the runtime is built, what the public ABI looks like, and what research directions the project's scope opens.

Each track has implications for Phase 0/1 (constraints to respect now) and deliverables further out (Phase 5+ for most). They are documented here so the constraints don't get lost in the gap between design and implementation.

Documents

cuda-native-walkthrough.md

CUDA as a first-class design concern, not a backend bolted on later. Adds device placement as a fifth refinement axis on the tensor type. Forward-declares a multi-tier compilation pipeline (algebraic IR → tile IR → target IR via MLIR NVVM). Shows what tile-level kernel authoring looks like in the language, with a tensor-core GEMM example compared to CUDA C++ and Triton. Establishes capability-typed kernels as the deliverable for Phase 5.

Adjusts Phase 1's scope: forward passes should run on GPUs via existing library kernels (cuBLAS / cuDNN dispatch) before Phase 5's full tile-IR work lands.

ecosystem-architecture.md

Three architectural patterns drawn from RAPIDS, committed to as Phase 0/1 engineering decisions:

  1. A shared GPU memory manager (RMM-style) with a pluggable allocator interface.
  2. A canonical tensor ABI compatible with DLPack for cross-framework tensor exchange.
  3. A library-of-libraries architecture, with the compiler and runtime as infrastructure that domain libraries (cuDF, cuML, cuGraph analogs) sit on top of.

Reframes the project's scope from "an ML language" to "typed-GPU-computation infrastructure." Adds a public-ABI stewardship discipline as a new Phase 1+ concern.

future-track-arrow-dataframes.md

Apache Arrow + refinement-typed schemas as the design for typed dataframes — the first non-ML domain library worth building. Schema-refinement-types-on-Arrow is genuinely novel research; no production dataframe library has compile-time schema-refinement-typed operations.

The concrete validation target: the observability stack. OpenTelemetry's OTel-Arrow protocol is moving observability data toward Arrow-native end-to-end (OTel → ClickHouse / Tempo / VictoriaMetrics). A typed-dataframes library on GPU would plausibly serve infrastructure already in development on the project's surrounding work.

Identifies what Phase 0/1 must do to keep this track open (memory manager designed for raw bytes, tensor ABI separated from a future Dataframe type, IR polymorphic over value kinds, one ADR).

bootstrap-and-self-modeling.md

Three senses of bootstrapping mapped to the project: standard library in the language (Phase 1), compiler transformations as in-language handlers (Phase 2 onward), compiler self-hosting (Phase 8+, possibly never). The load-bearing case is AD-as-handler: Phase 2's reverse-mode AD is a handler written in the language, not a compiler pass written in OCaml.

Identifies the earliest possible falsification of the self-modeling thesis — a small AD PoC at the start of Phase 2 — and the Phase 1 commitments needed to keep the path open: proto-stdlib in test fixtures, an ADR on bootstrap stance, runtime FFI design discipline (small, orthogonal, stateless entry points).

Unifies the other forward tracks: the library author's guide (ecosystem-architecture) is the public face of the same extension mechanism that makes self-modeling work; the tile IR (CUDA-native) is self-modeling at the kernel-author tier; typed dataframes (Arrow track) is the first major test of the extension surface.

surface-and-personas.md

How the language presents itself to different audiences — practitioners, researchers, library authors, systems engineers, production engineers, verification engineers, newcomers — without fragmenting into multiple languages. The reframing: the same person occupies different audiences at different times, so the design problem is mode-switching within one workflow, not multi-language design.

Five composing strategies: progressive disclosure within one surface, bidirectional inference making types optional, persona-aware defaults via pragmas, migration tooling from PyTorch/JAX, multi-tier documentation organized by persona. Three Phase 7 hard commitments (one surface language; progressive disclosure as the design discipline; pragma-driven mode switching). Four cheap Phase 1 commitments that keep the path open without timeline impact.

The bet: the project's type-system foundation gives us more capacity to serve multiple audiences than a typeless language has, because the types are doing work even when invisible. Same machinery, different views.

How these relate to the strict spec

The forward tracks are read after the Phase 0 spec (phase-0/) is understood. They build on it without modifying it; the formal type system, operations, and semantics in phase-0/ are unchanged. What changes:

If a forward track conflicts with the strict spec, the spec wins. The spec is what's committed; the tracks are commitments about how to build on top of it.

Possible new tracks

The pattern is extensible. Plausible candidates for future forward-track documents, none committed yet:

Adding new forward-track documents is a deliberate decision, not a default. The current set captures the architecturally load-bearing commitments; adding more should require the same level of engagement.