LMRuntime.com / Source versus evidence
Runtime Capability Matrix
See which capabilities have published package APIs, which artifact evidence is available, and which model, platform, integration, and host responsibilities remain separately scoped.
This matrix separates a published package API from model compatibility, platform evidence, performance, host-owned services, and production support. Read every row through that boundary.
How to read this matrix
A published API can be real and useful without supporting every model or environment. The matrix shows the strongest artifact-level signal, the public boundary, and the next consumer evidence gate instead of collapsing everything into a yes/no compatibility badge.
The capability has a public type, contract, or implementation surface in the UAIX.LmRuntime NuGet package family.
The published package family exposes inspectable metadata, README guidance, and XML documentation for the represented API surface.
A consuming application must retain build, test, cancellation, disposal, and negative-case evidence for its resolved package graph and environment.
A named model identity, tokenizer, tensor storage, workload, operating system, processor, and memory envelope are required before a compatibility or performance claim.
The behavior belongs to the consuming application or is intentionally outside this package family; do not infer it from the runtime API.
Package-family target
Package publication does not create universal model, platform, or production-support guarantees.
The documented facade does not start a subprocess, host a server, download a model, or call a provider API.
Container validity, tokenizer support, model architecture, tensor storage, and kernel coverage remain separate checks.
The family name is not a blanket claim for every derivative, metadata convention, quantization, or context size.
Lower-level packages remain available when an application needs direct ownership of parsing, tokens, tensors, kernels, sampling, sessions, backend selection, or deployment assets.
Capability matrix
Package family and contracts
The runtime is published as layered packages so applications can take only the responsibilities they need.
| Capability | Current evidence signal | Public boundary | Next evidence gate |
|---|---|---|---|
| Complete public NuGet package family | Published package API Foundations, model-pipeline packages, Acceleration, managed CPU and GPU registration packages, CUDA native-asset identities, and LocalEndpoint are represented by public package IDs and dedicated guides. | Package availability does not imply that every lower-level API is required by every application. | Choose the narrowest package and validate the resolved dependency graph in the consumer project. |
| Runtime-neutral inference contracts | Artifact documentation verified Requests, responses, messages, streaming deltas, sessions, tokenizers, runtime settings, diagnostics, and policy interfaces are documented in Abstractions. | An interface does not prove a particular implementation, model, latency, or availability commitment. | Contract tests for each concrete adapter and cancellation or streaming behavior used by the host. |
| Generated member reference | Artifact documentation verified LMRuntime.com publishes package/type/member reference data derived from public package XML documentation. | NuGet remains authoritative for current target frameworks, dependency versions, hashes, and release metadata. | Regenerate the reference whenever the published package API changes. |
Model identity, GGUF intake, and tensor storage
Artifact identity and bounded structure are established before tokenizer selection or model execution.
| Capability | Current evidence signal | Public boundary | Next evidence gate |
|---|---|---|---|
| Bounded GGUF parsing and strict validation | Artifact documentation verified GGUF headers, metadata, arrays, tensor descriptors, alignment, sharding, classification, and configurable structural limits have documented APIs. | A structurally valid container can still use an unsupported tokenizer, architecture, storage type, or tensor arrangement. | Validate each accepted model artifact and preserve malformed or edge-case fixture coverage. |
| SHA-256, byte-count, and path verification | Artifact documentation verified The GGUF and LocalEndpoint layers expose hashing, expected length, allowed-root, reparse-point, and model-size controls. | The host still establishes the trusted digest, source receipt, model license, and accepted storage location. | Consumer tests for path escape, reparse points, mismatched identity, truncation, replacement, and limit failures. |
| Mapped, segmented, and copied tensor access | Artifact documentation verified Mapped-file ownership, tensor views, segmented readers, float32 readers, storage traits, and quantized block metadata are documented. | Views must respect owner lifetime, byte geometry, alignment, row shape, and exact storage-specific bounds. | Lifecycle, disposal, large-file, concurrency, and per-storage validation in declared environments. |
Tokenization and LLaMA-family model binding
Tokenizer behavior and semantic tensor roles are derived from the model artifact and rejected explicitly when unsupported.
| Capability | Current evidence signal | Public boundary | Next evidence gate |
|---|---|---|---|
| GGUF-driven tokenizer construction | Artifact documentation verified Factories, strict metadata readers, multiple tokenizer engines, special-token options, chat rendering, streaming decode, truncation, and parity records are documented. | Vocabulary, merges, normalization, byte fallback, special tokens, and chat templates are model-specific. | Exact token-ID and decoded-byte parity for each accepted model and prompt format. |
| LLaMA configuration and tensor binding | Artifact documentation verified Configuration derivation, invariant checks, required tensor roles, binding manifests, mapped/reference weight sources, and diagnostics are documented. | A LLaMA-family label does not guarantee compatibility with every derivative or metadata/tensor naming convention. | Named artifact binding, forward, logits, and generation evidence with explicit limitations. |
| Broad model compatibility | Model or platform scope required The packages expose strict validation and diagnostics needed to determine support for a concrete artifact. | No universal list of all compatible repositories, quantizations, context variants, or fine-tunes is inferred. | Publish a model matrix only from retained immutable identities, test prompts, results, and known failures. |
Managed CPU execution and sampling
Reference operations, observable CPU dispatch, model sessions, and token selection remain distinct responsibilities.
| Capability | Current evidence signal | Public boundary | Next evidence gate |
|---|---|---|---|
| Reference and dispatched CPU kernels | Artifact documentation verified Float, half-precision, quantized, normalization, matrix/vector, softmax, RoPE, dispatch-selection, and parity APIs are documented. | Represented storage and operations do not imply every shape, ISA tier, processor, or model path is supported end to end. | Operation-specific reference parity, invalid-input tests, selected-tier evidence, and model-level verification. |
| Greedy and probability sampling | Artifact documentation verified Greedy selection, seeded random state, temperature, top-k, top-p, minimum-p, repetition/frequency/presence transforms, bias, stops, and generation control are documented. | A seed cannot compensate for differences in model bytes, tokenizer, logits, floating-point execution, session state, or settings. | Golden vector tests, state replay, stop-boundary tests, and application-specific generation policies. |
| Performance and hardware support | Model or platform scope required CPU selection and benchmark-supporting diagnostics are represented. | No blanket latency, throughput, memory, energy, operating-system, processor, or driver claim follows from the API surface. | Reproducible benchmarks with exact artifact, package graph, build, machine, workload, warm-up, and aggregation details. |
Backend selection and registration
Backend identity, capability declaration, local probing, selection policy, and executable inference are separate states.
| Capability | Current evidence signal | Public boundary | Next evidence gate |
|---|---|---|---|
| Backend registry, probes, and deterministic selection | Artifact documentation verified Acceleration exposes backend contracts, registry ordering, device descriptors, capability records, probe results, require/prefer policies, diagnostics, and visible CPU fallback state. | A successful selection proves only the evidence returned by the registered backend probe under the requested policy. | Retain registry order, requested runtime identifier, probe diagnostics, selected device, fallback state, and failure reason in host validation. |
| Managed CPU backend | Published package API Backends.CpuManaged registers a stable managed CPU identity, reports an available process-local CPU device, and requires no native inference asset. | Availability of the backend identity does not establish model compatibility or performance for a concrete artifact. | Run the named model and workload under retained package, machine, limits, and output evidence. |
| CUDA, DirectML, Vulkan, ROCm, and Metal registrations | Published package API Each package declares backend identity, execution kind, intended API, runtime identifiers, capability metadata, and fail-closed diagnostic behavior. | Package presence and declared compatibility do not prove driver availability, device discovery, native assets, an execution adapter, or model work on the GPU. | Require a successful local probe and retain adapter-specific execution and parity evidence before claiming GPU inference. |
| CUDA native-asset package identities | Artifact documentation verified Separate modern Windows and legacy Tesla K80 package identities reserve explicit native deployment lanes. | The supplied source manifests do not establish an embedded CUDA inference binary or a callable managed API in those packages. | Inspect the installed package assets, verify signatures and hashes, execute a local probe, and retain adapter execution evidence. |
Sessions and LocalEndpoint facade
The high-level package combines the supported local path while keeping host authority and application services outside the runtime.
| Capability | Current evidence signal | Public boundary | Next evidence gate |
|---|---|---|---|
| Verified local model loading and isolated sessions | Artifact documentation verified Load options, execution limits, file expectations, model identity, session contexts, generation requests/results, token observation, and explicit disposal are documented. | The host chooses trusted artifacts, prepares prompts, maps errors, sets limits, and defines its supported usage envelope. | Consumer integration tests for independent sessions, reset/continuation, limits, cancellation, disposal, and failure mapping. |
| UAIX profile and memory context evidence | Artifact documentation verified Session-scoped profile/load-session and memory-route metadata are validated and retained as immutable evidence. | All authority flags remain false. Context does not grant execution, policy override, commands, network, provider access, telemetry, export, or website intake. | Keep import, protected-anchor enforcement, prompt assembly, persistence, and approval in the host application. |
| Downloader, server, provider client, subprocess, and telemetry | Host-owned or not provided The documented LocalEndpoint capability object reports the closed local-only boundary. | These services are not supplied or silently activated by the runtime facade. | Implement any required service explicitly in the host with independent security, consent, persistence, and operational controls. |
Host-application responsibilities
Local inference is one component of an application. The application remains responsible for everything outside the package contract.
| Capability | Current evidence signal | Public boundary | Next evidence gate |
|---|---|---|---|
| Model acquisition, licensing, and catalog | Host-owned or not provided The runtime accepts local artifacts and expected identity; it does not obtain them. | The host retains source receipts, licenses, immutable hashes, storage policy, and update approval. | Define an artifact intake and approval process before deployment. |
| Prompt assembly, memory, tools, commands, and policy | Host-owned or not provided The runtime consumes prepared prompt and evidence inputs and returns generation outputs. | No memory record or model output can silently grant host authority. | Implement explicit user approval, validation, sandboxing, review, and no-op behavior in the host. |
| Transport, persistence, audit, UI, and production operations | Host-owned or not provided The package exposes in-process runtime objects rather than an operational platform. | Authentication, authorization, multi-user isolation, data retention, logging, uptime, deployment, and support are host concerns. | Apply the consuming organization’s architecture, security, privacy, accessibility, reliability, and support controls. |
Tensor storage vocabulary represented by the package
Show represented storage identifiers
These identifiers are present in the public tensor-storage vocabulary. They do not establish that every operation, tensor shape, model architecture, or CPU path supports each type end to end.
F32F16F64BF16I8I16I32I64Q4_0Q4_1Q5_0Q5_1Q8_0Q8_1Q2_KQ3_KQ4_KQ5_KQ6_KQ8_KIQ4_NL
Capability FAQ
Are the UAIX.LmRuntime packages publicly available?
Yes. The package family is published on NuGet, and every package guide links to its version-independent package URL.
Does package publication mean every GGUF model works?
No. Container validity, tokenizer metadata, LLaMA-family graph requirements, tensor storage, kernel coverage, context size, and resource limits must all match the concrete artifact.
Which package should an application install first?
Use UAIX.LmRuntime.LocalEndpoint for the bounded application-facing local GGUF path. Install a lower-level package directly when the application needs to own that layer.
Does installing a GPU backend package enable GPU inference?
No. The GPU packages register identity, capability metadata, runtime identifiers, and fail-closed probes. A host must separately prove native assets, driver and device discovery, an executable adapter, model execution, and parity.
Does LocalEndpoint download models or call cloud APIs?
No. The documented facade accepts local model paths and expected identities. It does not provide a downloader, provider client, network fallback, server, subprocess launcher, or telemetry exporter.
Why are package version numbers absent from this site?
The documentation is intended to remain useful across package updates. NuGet is authoritative for current versions and frameworks; consumers should pin resolved dependencies and test upgrades in CI.
Does UAIX memory or profile context grant execution authority?
No. The context is immutable session evidence only. Commands, network, provider APIs, telemetry, export, policy override, and runtime authority remain false and host-controlled.