Browser boot and model selection

Follows the exact JavaScript initialization sequence, default q8 model choice, stale-load protection, recovery behavior, and provenance-sidecar rendering.

Boot sequence #

1. Cache required DOM nodes.
2. Fetch and instantiate runtime/tinyrustlm.wasm.
3. Capture exported memory and functions.
4. Call init_runtime.
5. Load the default tinylm16q8 route.
6. Enable generation only after Rust accepts the artifact.

Model routes #

The selector exposes TinyLM-16M q8_0, q4_0, and f32 plus tiny f32, q8, q4, BPE, and tied-output fixtures. Route keys map to fixed same-origin paths and matching .slm.manifest sidecars.

Race control #

The loader tracks a sequence token so a slower previous fetch cannot overwrite a newer user selection. UI actions remain disabled during a pending load.

Provenance timing #

Rust model admission happens before JavaScript fetches the sidecar. The manifest informs the operator but is not itself an input to parser admission. A future security design should verify manifest identity and artifact hash before activating the model.

Scope #

This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.

Engineering considerations #

• Identify the source, version, target environment, and owner.
• Separate observed values from estimates and externally reported values.
• Record trade-offs, unsupported cases, and fallback behavior.
• Link performance statements to a compatible benchmark methodology.

Verification questions #

• What exact artifact, revision, backend, and environment were reviewed?
• Which assumptions could change the result?
• Which data should be retained so another engineer can reproduce the conclusion?