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. For what the tree wires today, prefer docs/00-foundation/03-current-status.md.

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

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:

1. Forward equality within an explicit dtype-dependent tolerance.
2. Per-operator vector-Jacobian products.
3. End-to-end transformer gradients for inputs and every parameter.
4. Finite-difference checks on a very small model.
5. Causal-mask tests proving that future tokens cannot affect earlier logits.
6. 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

1. Causal masking through a typed select/where primitive or an equivalent mask-add operation.
2. General head reshape, transpose, and batched matmul patterns.
3. Stable log_softmax plus indexed negative-log-likelihood or a fused cross-entropy primitive.
4. Numerical AD rules and parity tests for every decoder operation.
5. Functional parameter updates, followed by AdamW and gradient accumulation. (Host functional SGD and AdamW, plus host argmax, are specified in Phase 1 Sections 11, 16, and 17 as of 2026-08-23. A 40-epoch host train loop over a toy corpus is Section 24 as of 2026-08-24. Decoder-wide AdamW is Section 25 as of 2026-08-24. Mean NLL is Section 26 as of 2026-08-24 (keepdims reduce_sum times host 1/(B·T); Sections 24 / 25 stay sum-NLL).)
6. Seeded RNG and temperature, top-k, and top-p sampling. (Host Uniform + Gumbel-max + temperature is Section 18 as of 2026-08-23. Top-k / top-p and an in-graph PRNG are still open.)
7. Checkpoint import/export and exact-model weight layout rules. (A host-owned storylm0-checkpoint-v0 NPZ / JSON fixture is Section 23 as of 2026-08-24. The taught storylm0-checkpoint-v1 from Section 24 SGD is Section 27 as of 2026-09-05 (just validate-trained-rollout). Neither is a production checkpoint ABI.)
8. KV-cache indexing and update semantics suitable for autoregressive decode. (One-step concat is Section 19, a three-step host greedy loop is Section 20, prefill → decode handoff is Section 21, and T_max pad-with-zeros is Section 22, as of 2026-08-23. The 32-token checkpoint test is Section 23 as of 2026-08-24 (static T=36 re-forward from a patterned NPZ fixture). A toy host train loop that teaches once upon a time the end is Section 24. Growing S inside while and an in-place write remain open.)
9. Mixed precision and, after correctness is established, Phase 3 sharding. (The first workload is StoryLM-0 2-way column-parallel lm_head (Section 5), 2-way head-parallel attention (Section 6), and 2-way column-parallel QKV (Section 7) as of 2026-08-24. @mesh / @sharded and the 4-device simulator remain open.)

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.

As of 2026-09-05 the numeric instance is Section 23 / just validate-rollout (patterned fixture), Section 24 / just validate-train (toy-corpus SGD, then greedy once upon a time the end once upon a time the end), just validate-decoder-adamw (same corpus and greedy lock, Section 16 on every decoder weight), and Section 27 / just validate-trained-rollout (persisted taught weights over 32 generated tokens). Weights remain a research fixture, not a creative-writing checkpoint.

Creative-writing tuning still waits on a real corpus and larger model; the taught fixture only locks the toy cycle.

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.