Navigate the portal

Quick find

System Map

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.

Execution
Browser-local Rust/WASM
Model contract
Verified .slm artifacts
Network boundary
No remote inference
Evidence
Checksums, receipts, and tests

01

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

02

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

03

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

04

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
Portal delivery details

Server rendering: Routes are handled by index.php; content lives in data/pages.php; HTML and Markdown share the same page data.

Dependency boundary: No WordPress bootstrap, database, Composer package, npm build, CDN script, Bootstrap, or jQuery dependency.

Deployment: The package targets the subdomain root with Apache or equivalent clean-route rewriting.