# TinyRustLM Architecture

> The architecture divides the system into a static browser UI, Rust/WASM runtime, .slm model format, offline packer, local server, browser harness, and model-breeding evidence path.

- Site: TinyRustLM
- Canonical: https://TinyRustLM.mirust.com/architecture/
- Version: 1.3.0
- Updated UTC: 2026-06-29T22:59:10Z

## Runtime boundary

Rust owns model parsing, tensor validation, tokenizer behavior, quantization math, KV cache state, sampling, generation, diagnostics, error codes, adapter validation, and adapter application. JavaScript owns the page shell, local fetches, byte transfer into WASM memory, controls, diagnostics rendering, and transcript display.

- Rust owns inference
- JavaScript does not parse .slm tensors
- Local fetches only
- Diagnostics are exposed intentionally

## Static browser app

The app is deliberately static: HTML, custom CSS, and handwritten JavaScript. Its job is to select local artifacts, verify manifests and receipts, copy verified bytes into WASM, and render state through text-safe DOM operations.

- No client framework
- No CDN dependency
- No remote model call
- DOM text nodes for generated content

## Offline toolchain

The packer and validation tools convert source weights into .slm artifacts, write manifests, create adapter packages, generate receipts, produce selector registries, stage browser bundles, and gate claims through runtime-smoke or evaluation sidecars.

- slm_pack utility
- Provenance manifests
- Candidate manifests
- Runtime-smoke sidecars
- Eval sidecars

## Claim discipline

The architecture separates execution proof from assistant-quality proof. Running a deterministic fixture proves runtime behavior; it does not prove that a trained assistant model is broadly useful. Public copy should keep that difference visible.

- Execution claim requires runtime evidence
- Assistant-quality claim requires eval evidence
- Operator receipts must remain replayable