May 17, 2026. A reachable local-model endpoint is not enough evidence that classification is ready to run. VALESKA’s classifier has a particular dependency: the expected model must be selected, loaded, and available with sufficient graphics processing unit (GPU) resources before a classification request is sent. This work introduces a runtime preflight for that dependency. The claim is not that every local model will now start successfully. The claim is that the classifier can ask whether its required runtime profile is ready and decline classification when it is not.
The working question
Can local classification fail in a legible way instead of treating an arbitrary responding endpoint as the right model? A simple endpoint probe can confirm that something is listening. It cannot establish which model is loaded, whether the machine has reserved the required graphics memory (VRAM), or whether a competing task has changed the runtime state. Those are operating facts, not details the classifier should guess. The preflight creates a place to state them before a document is classified.
Evidence from May 16 and May 17
On May 16, the Valeska-side helper was added to request a named runtime profile before the AI classifier, training scorer, and training-dataset generator use local inference. The helper reads a classification profile setting and offers explicit controls for the profile, a required-runtime mode, and bypassing the preflight when that is appropriate for a defined environment. If the runtime manager reports that the profile is not ready, the classifier records the failure and does not proceed as though the model had been verified. The change makes readiness part of the classifier’s contract instead of leaving it as a condition assumed by callers.
Today, May 17, that helper is pointed at the standalone GPU arbiter repository. This is a placement decision: model selection, VRAM claims, loading through LM Studio, and release behavior are handled through the arbiter’s profile-based manager rather than being recreated inside VALESKA. The profile named for repository classification identifies the intended model configuration. The classifier remains responsible for deciding whether to perform classification; the arbiter owns the runtime preparation request. Separating those responsibilities makes the dependency easier to inspect when classification is unavailable.
What this does and does not establish
The implementation establishes a gating path. Before it contacts a local model, the classifier can call the runtime helper and receive either readiness information or a reason to disable the operation. It also gives batch-oriented callers the same route, so training work does not silently use a different local state from interactive classification. This is useful because local inference is shared infrastructure: its limits are affected by model size, VRAM, startup state, and other consumers.
It does not establish that the named profile can always be loaded on this machine, that every VRAM claim will be granted, or that a classification result is accurate. Those are separate questions. The design intentionally keeps the distinction visible. A ready runtime is a precondition for classification, not proof of the quality of the classification itself. Likewise, a clean failure from the preflight is preferable to an unsupported claim that a model was ready.
Next test
The next test is to exercise the actual profile under the shared GPU conditions it will face in use. The check should show the selected profile, the availability result, and the classifier’s behavior in both paths: classify only after successful preparation, and remain disabled with an understandable record when preparation fails. The same test should be run through a batch caller, because the shared contract is the point of the change. Results from that operational test belong in a later entry; today’s evidence is the preflight integration and its transfer to the arbiter-managed runtime.
Historical basis: May 16–17, 2026 commits 346b2d9 and 75e0ba4.