Modular skill package ABI from the current runtime

Translates the single-model source into a concrete package manifest, compatibility key, lifecycle, and request contract for hyper-specialized tiny models.

Experimental
Last verified
2026-06-25 00:00 UTC
Updated
Reading time
2 minutes

Translates the single-model source into a concrete package manifest, compatibility key, lifecycle, and request contract for hyper-specialized tiny models.

Implementation evidence: this topic is grounded in the reviewed GGUF.MiRust.com source snapshot. It documents observed code and artifacts without claiming broad deployment, model quality, or production readiness.

Architecture topic: this page does not claim that the WordPress website implements or executes the described runtime behavior.

Package identity

Each skill needs a stable ID, semantic version, artifact SHA-256, source and license, model family, tokenizer ID and hash, format/version, quantization, task contract, authority scope, resource estimate, and evidence status.

Compatibility key

Independent models may differ in architecture and tokenizer. Shared-base adapters must match base artifact identity, target modules, rank/scaling convention, tokenizer, tensor names, and runtime adapter ABI.

Lifecycle

Installed, verified, resident, active, suspended, retired, and quarantined are separate states. The current load_model/free_model pair supplies only a single resident slot; a module registry needs handles and an eviction policy.

Request contract

Inputs and outputs require typed schemas, max sizes, confidence/uncertainty semantics, deterministic settings, cancellation, error codes, and side-effect authority. A role label alone is insufficient.

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?