Locara

Out-of-scope modalities

Status: ⛔ explicitly out of scope for Locara v1.

Recorded for completeness against the HuggingFace task taxonomy. These tasks either don’t fit the “foundation model as runtime modality” framing, or are better served by app-bundled tooling rather than framework-level support.

Tabular ML

HF tasks: tabular-classification, tabular-regression.

Classical ML — XGBoost, LightGBM, TabPFN are the right tools. Apps that want tabular ML can ship a small model bundled in their app’s WASM tool runtime — that’s the right factoring (it’s a custom op the app provides, not a runtime-shared modality).

Why not first-class: Locara’s modality system is optimized for foundation models (encoder-only / autoregressive / diffusion transformers, GB-scale weights, shared across apps). Tabular ML models are tiny (KB-MB), heavily fine-tuned per dataset, and shouldn’t share a model registry with chat LLMs.

For LLM-shaped time-series forecasting (Chronos, TimesFM, Lag-Llama), see time-series-forecasting — that is a candidate v2+ first-class modality.

Reinforcement Learning

HF task: reinforcement-learning.

A training paradigm, not a runtime modality. RL agents in apps ship as trained policies (a fixed-weights model used like any other inference); they don’t need a runtime “RL” modality declaration any more than a trained classifier does.

If a reference app emerges that ships an RL policy, it should fit under text-to-text (decision transformer / ReAct shape) or out-of-scope bundled tooling, not a new top-level modality.

Robotics

HF task: robotics.

Same reasoning as RL: a training paradigm. The runtime modality of a robotics app is whatever shape the policy expects — usually multimodal (vision + sensors → actions). Wouldn’t fit Locara’s sandboxed laptop deployment target anyway.

Graph Machine Learning

HF task: graph-machine-learning.

Niche — Locara’s app surface area doesn’t include graph algorithms naturally. Apps that need graph ML can bundle a solver in their WASM tool runtime.

Unconditional image generation

HF task: unconditional-image-generation.

Image from noise alone, no prompt. Every generative model can do this with a dummy/empty prompt — it’s a trivial special case of text-to-image and not worth a dedicated modality slot.

Fill-mask

HF task: fill-mask.

BERT-style masked language modeling. An internal training / inference primitive, not an app-facing modality. Apps that want mask-fill behavior in 2026 use a chat LLM with appropriate prompting.

Classical NLP tasks (text-classification, NER, extractive QA, zero-shot classification, table QA)

These have their own dedicated note — classical-nlp-tasks.md — because unlike the genuinely out-of-scope items above, they could be first-classed if a reference app needed the latency/determinism of specialist models. For now they’re handled implicitly via text-to-text.

When something here might come back

This list is a current judgement, not a permanent verdict. The right re-evaluation triggers:

  • Tabular ML: if Locara grows a “data app” reference that needs serious tabular forecasting beyond time-series-forecasting.
  • RL / Robotics: probably never as a first-class modality; always bundled.
  • Graph ML: if a knowledge-graph app reference emerges.
  • Classical NLP: if hard-real-time classifiers (e.g. content moderation latency-critical) become a use case.

Re-walk this file at every phase boundary along with the rest of the modality survey.

See also