Validate a LiteRT-LM Model Package

Direct answer

A LiteRT-LM package check should verify the package as a structured artifact, not just test whether a filename ends in the litertlm extension. The official project publishes a header schema describing metadata and section types, and its builder documentation provides tools to build, inspect, and unpack packages. Use those sources for the exact format revision under review. Check that required sections are present, offsets and references are internally coherent, metadata describes the intended model, tokenizer assets correspond to the same revision, and any external weight files are included and identified. Then load the exact package through the target Kotlin runtime and run a representative task. Package parsing, runtime load, and task acceptance are separate gates. Do not invent a universal package validator from one example or assume the schema is frozen. Record the LiteRT-LM repository revision or released tooling version used to inspect the candidate, the schema version where exposed, and the exact package digest when available. A package created by a newer builder may include optional or deprecated sections; an older runtime may not support them. The package file may reference tokenizer metadata or external weights, so copying only one file can create an incomplete delivery even if the extension is correct. Renaming a GGUF or TFLite file does not convert it into LiteRT-LM format. The repository’s LiteRT-LM fact says the framework uses its own packaging and APIs rather than GGUF. The project model facts separately warn that current Cove digest data is absent or placeholder. Those facts support clear boundaries: format identity should be based on actual package structure and tool/runtime revision, not filename; a missing digest must remain disclosed. Do not state that any particular device supports a package until the exact artifact-runtime-device-task combination has records. The package-builder guide and schema are primary implementation references, but they do not certify every artifact someone might create. Build an inspection receipt. Record input package name as received, byte length, trusted source revision, builder command and options, inspection tool version, section inventory, metadata checks, tokenizer identity, external assets, and any warnings. Do not log private prompts or credentials. If the format tool says it can parse the file, preserve that result but do not generalize to model load. If runtime initialization fails, record the stage and exact runtime build; do not label the message common or offer an unverified fix. If the package passes load but fails task acceptance, keep the artifact in a candidate state. Test negative cases with controlled package fixtures: wrong extension, truncated header, missing required section, overlapping or out-of-bounds offsets, wrong tokenizer, missing external weights, metadata for another revision, unsupported section type, and valid package with a task failure. Verify the checker rejects malformed structures before sending them to the native runtime when practical. A clean test should also close the engine and allow another candidate to load; package verification is part of the asset lifecycle, not a one-time filename check. For release, maintain a manifest mapping package identity to source and builder provenance, license, target runtime, app version, required companion assets, and acceptance suite. A valid package does not establish licensing, public availability, device support, speed, or output quality. Keep these review decisions separate. If package inspection tools change, rerun the corpus against a pinned tool version and compare receipts rather than silently interpreting old output with a new parser. ### Procedure 1. Identify the exact candidate bytes, source revision, packaging tool commit/version, and expected package format. Preserve the received artifact unchanged for hashing and audit. 2. Inspect with official LiteRT-LM builder/peek tooling pinned to a recorded revision. Save section inventory, metadata, tokenizer linkage, external weights, offsets, and warnings. 3. Compare required fields with the candidate release manifest. Reject missing, ambiguous, cross-revision, or unsupported components before runtime initialization. 4. Load the exact file using the target Kotlin runtime on a controlled environment; record package parse, engine initialization, and a fixed task result separately. 5. Run malformed-package fixtures and close/reopen tests. Retain source, package, runtime, and acceptance records for update and rollback. ### Acceptance criteria - Package identity and inspection tool/schema revision are recorded; extension alone is never accepted as format proof. - Metadata, tokenizer, external weights, section boundaries, and source revision are consistent or explicitly rejected. - Parser acceptance, Kotlin runtime load, and task acceptance are separately evidenced. - Malformed candidates cannot replace the active artifact, and the inspection result makes no unsupported device or product claim. ### Comparison | Check | Establishes | Does not establish | |---|---|---| | Filename extension | A naming convention | Package format, complete sections, or compatibility | | Official package inspection | Expected structure under a pinned tool/schema | Runtime execution or task quality | | Kotlin runtime and task fixture | Candidate loads and meets tested properties | Untested device support or universal performance | ### FAQ **Does a litertlm extension prove the file is a valid package?** No. A filename can be changed without conversion. Inspect actual package sections and metadata using official tools, then load the exact file with the target runtime. **Can the package be checked by opening it in a text editor?** No. It can contain structured binary sections and external references. Use the builder or inspection utility for the relevant pinned format revision and preserve its report. **If the package parser accepts it, is inference guaranteed to work?** No. Parser acceptance checks structure; runtime initialization and operation execution remain separate. Run a representative task and preserve the exact runtime version and result. **Can a package validation guide claim support for a phone model?** Not without device-specific evidence for the exact package, runtime, and task. A format schema or successful desktop inspection does not create an Android compatibility claim.

A package filename looks correct but its companion tokenizer is uncertain

A developer receives one file with a LiteRT-LM extension and a separate tokenizer folder from another export. The team needs to confirm the package sections and assets refer to the same source revision before loading a native engine.

Decision

Inspect the package using pinned official tooling, compare every companion identity, then load and test only the exact coherent candidate.

Expected outcome

A mismatched tokenizer or incomplete package is rejected before activation, while a valid package proceeds through distinct runtime and task checks.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Package manifest and revision
• Tokenizer and metadata record
• Runtime load and rejection result

A runtime comparison is publishable only when artifact identity, build configuration, selected backend, task fixture, and failures are recorded.

Implementation workflow

1. Freeze the exact bytes and tool version. Keep the received candidate immutable and record source revision, package length, builder/inspection tool revision, and schema version where exposed. Do not infer format from the extension.
2. Inspect package sections and metadata. Use official LiteRT-LM tooling to enumerate sections, model metadata, tokenizer references, offsets, external weights, and warnings. Tie the inspection receipt to the candidate digest or other stable identity.
3. Reconcile companion assets. Verify that tokenizer, model config, external weights, and source revisions belong to one release. Reject mixed exports even when each individual file parses.
4. Load through the intended Kotlin runtime. Record parsing, engine initialization, and task execution separately using a fixed non-sensitive fixture. Preserve the exact runtime revision and the first failing stage.
5. Exercise rejection and close paths. Test truncated headers, absent sections, bad offsets, wrong tokenizer, and missing weights. After a valid run, close resources and verify another candidate can be inspected or loaded.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• A pinned inspection tool confirms package structure; file extension alone is not accepted.
• Tokenizer, metadata, external weights, and source revision are coherent for the same candidate.
• Package inspection, Kotlin runtime load, and representative task result are separate recorded gates.
• Malformed candidates are rejected without replacing the active artifact or leaking unsupported claims.

Decision table

Failure patterns to prevent

• Renaming another format
• Mixing package revisions

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• LiteRT-LM repository
• LiteRT-LM package builder and inspection tools
• LiteRT-LM package header schema
• LiteRT-LM Kotlin API guide

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions