Learn

Kina Readiness Assessment for a Creative-Writing LLM

Non-normative companion document. Assessed on 2026-07-15 against commit a1d1772. If this document and the numbered specifications disagree, the specifications win.

Executive assessment

Kina is ready to serve as an LLM architecture research language, but it is not yet an end-to-end platform for training or serving a useful creative-writing LLM.

The current compiler can express and lower much of the mathematical core of a small transformer. It is therefore sufficient for designing typed tensor graphs, experimenting with automatic differentiation, and investigating language-level controls around inference. It does not yet provide the data, optimization, serialization, sampling, numerical validation, or distributed training infrastructure required for a complete LLM workflow.

A useful way to frame the present boundary is:

Kina can be the compiled tensor and AD core of an experimental LLM stack. It is not yet the whole ML platform around that core.

What works today

The reviewed implementation includes:

Tensor shape and dtype checking with symbolic-shape support.
Elementwise arithmetic, batched matrix multiplication, reductions, transpose, reshape, broadcast, gather, and softmax.
Unary operations used by transformer blocks, including exp, sigmoid, silu, gelu, sqrt, and rsqrt.
Functions, conditionals, loops, effect rows, effect handlers, and loop-checkpoint annotations.
A compiler-level reverse-mode AD transformation for a restricted set of statically structured programs.
Standard-library sketches for RMSNorm, SwiGLU, attention, and a transformer block in src/compiler/lib/stdlib/stdlib.kina.
A differentiable transformer example in tests/compiler/examples/transformer_ad.kina.
An early autoregressive loop sketch carrying token, KV-cache, and position state in tests/compiler/examples/llm_generate.kina.
Textual MLIR output accepted by the MLIR parser for the transformer AD example.

During this assessment, the following checks passed:

cd src/compiler && dune build && dune runtest
./scripts/mlir-golden-check.sh
dune exec bin/main.exe -- \
  ../../tests/compiler/examples/transformer_ad.kina \
  /tmp/kina-transformer-ad.mlir
/opt/homebrew/opt/llvm@18/bin/mlir-opt \
  /tmp/kina-transformer-ad.mlir -o /dev/null

These results establish that the compiler covers a meaningful transformer prototype. They do not yet establish that a trained model would be numerically correct or useful for creative writing.

Current readiness by subsystem

Subsystem	Current state	Readiness
Transformer tensor math	Matmul, reductions, softmax, gather, RMSNorm, SwiGLU, and attention prototypes	Good for research prototypes
Reverse-mode AD	Static compiler transform over a restricted let-bound graph and operation set	Partial
Token embeddings	`gather` exists with index-bound checking	Partial
Decoder execution	Loop-carried token and KV-cache sketch exists	Early prototype
Causal multi-head attention	No complete causal mask and head-splitting decoder path	Missing
Language-model loss	No indexed negative-log-likelihood or cross-entropy training path	Missing
Optimizer	No AdamW, gradient accumulation, or parameter update system	Missing
Stochastic operations	No model-facing seeded RNG, dropout, or sampling effects	Missing
Text pipeline	No tokenizer, corpus loader, batching, or vocabulary tooling	Missing
Model persistence	No production weight import/export or checkpoint format	Missing
Numerical validation	Compiler and snapshot coverage exists; comprehensive value and gradient parity does not	Major gap
Distributed training	Phase 3 sharding is still at the design stage in the assessed worktree	Not ready

Important evidence limitation

scripts/benchmark_ad.py constructs a comparable PyTorch program and times both systems, but it does not retrieve Kina results and assert value or gradient equivalence. It is therefore a performance harness, not a numerical correctness test.

Before using Kina to train model weights, the project should compare forward values and each parameter gradient against a trusted implementation using non-uniform inputs. Constant all-ones inputs are useful smoke tests but can hide transpose, broadcasting, indexing, and accumulation errors.

The minimum validation gate should cover:

Forward equality within an explicit dtype-dependent tolerance.
Per-operator vector-Jacobian products.
End-to-end transformer gradients for inputs and every parameter.
Finite-difference checks on a very small model.
Causal-mask tests proving that future tokens cannot affect earlier logits.
Deterministic seeded generation tests.

Why creative-writing quality is a separate problem

Unnatural “AI prose,” repetition, excessive caution, and flattened voice are not primarily compiler problems. They are affected by:

Training-corpus composition and quality.
Supervised fine-tuning examples.
Preference or reward optimization.
Serving-time system instructions and policies.
Sampling strategy and repetition controls.
The model's context representation and narrative memory.

Kina cannot change the policies of a separately hosted model. It can provide greater architectural and inference control for a model whose weights and serving stack are under the developer's control.

For creative writing, adding more hard rules can make prose even more rigid. Voice, rhythm, novelty, and imagery are usually better represented as soft preferences or critic scores. Hard constraints remain appropriate for facts such as point of view, character identity, timeline, forbidden disclosure, and world continuity.

Recommended vertical slice: StoryLM-0

The next useful target is not a foundation model trained entirely inside Kina. It is a small, falsifiable causal-decoder vertical slice.

Boundary

Keep tokenization, dataset loading, checkpoint storage, and orchestration in Python or Rust initially. Use DLPack or the existing C ABI to move tensors across the boundary. Kina owns the typed decoder graph, loss, and eventually its gradients.

Model path

Implement the following sequence:

I64 token IDs [B, T]
  -> embedding gather [B, T, D]
  -> causal multi-head self-attention
  -> RMSNorm and SwiGLU blocks
  -> vocabulary projection [B, T, V]
  -> cross-entropy loss

The first acceptance model should be deliberately small. Its purpose is to prove compiler and runtime correctness, not to produce publishable prose.

Required additions, in order

Causal masking through a typed select/where primitive or an equivalent mask-add operation.
General head reshape, transpose, and batched matmul patterns.
Stable log_softmax plus indexed negative-log-likelihood or a fused cross-entropy primitive.
Numerical AD rules and parity tests for every decoder operation.
Functional parameter updates, followed by AdamW and gradient accumulation.
Seeded RNG and temperature, top-k, and top-p sampling.
Checkpoint import/export and exact-model weight layout rules.
KV-cache indexing and update semantics suitable for autoregressive decode.
Mixed precision and, after correctness is established, Phase 3 sharding.

First generation acceptance test

StoryLM-0 should pass a small but concrete inference test:

Load a fixed vocabulary and fixed tiny-model checkpoint.
Accept a prompt represented as token IDs.
Generate at least 32 tokens using greedy decoding.
Produce identical tokens across repeated runs.
Produce seeded, reproducible results under stochastic sampling.
Demonstrate with a causal-leak test that changing a future token does not alter an earlier logit.

Only after this test passes should the project add creative-writing tuning.

Creative-writing research opportunities specific to Kina

Kina's effect system offers a distinctive research direction beyond merely reimplementing a transformer. Inference controls could be represented as typed effects and handlers, for example:

Sampling: temperature, top-k, top-p, and deterministic seeds.
NarrativeState: active characters, location, time, and unresolved goals.
Continuity: checks against established story facts.
Voice: soft stylistic scoring or adapter selection.
Revision: generator/critic passes with an explicit retry budget.

These effects would control decoding and orchestration; they would not by themselves teach the neural model how to write. Their value is making control flow, state, and policy explicit and composable while the tensor type system continues to guarantee shape, placement, and eventually sharding properties.

Recommendation

Use Kina now if the goal is to research typed model construction, compiler AD, or effect-controlled decoding. Use an established ML framework alongside Kina if the immediate goal is to improve creative-writing output through fine-tuning or adapters.

The strongest near-term architecture is:

Python or Rust
  tokenizer | corpus | checkpoints | experiment orchestration
                         |
                         v
Kina
  typed transformer graph | compiled loss/AD | decoding effects
                         |
                         v
MLIR + Rust runtime
  execution | device interop | future sharding

Under that division of responsibility, Kina is already sufficient to begin the research program while avoiding the need to build an entire ML ecosystem before the core language ideas can be tested.