Skip to content

refactor(studio): say "fine-tunable" consistently for the model capability - #1881

Draft
aray12 wants to merge 1 commit into
deployments-tab-order/alrayfrom
models-naming/alray
Draft

refactor(studio): say "fine-tunable" consistently for the model capability#1881
aray12 wants to merge 1 commit into
deployments-tab-order/alrayfrom
models-naming/alray

Conversation

@aray12

@aray12 aray12 commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

Summary

The Models page described one predicate with two words. The filter was labelled "Customizable" while its only option was labelled "Fine-tunable" — same widget, both vocabularies — and its tooltip explained it a third way. The card beside it rendered a "Fine-tunable" badge behind a prop named showCustomizationBadges.

This settles on "fine-tunable" for the user-facing model capability and collapses the underlying predicate to a single definition.

Changes

Vocabulary. "Fine-tunable" is already what the badge, the picker empty state ("No fine-tunable models found"), the form, and the tooltip say. "Customization" stays where it names the customizer service, its jobs, and their parameters — so the UI and the API now diverge deliberately rather than by accident.

One predicate, one definition. Boolean(model.fileset) was re-implemented inline in WorkspaceBaseModelsRoute and BaseModelCard, neither importing the canFineTuneModel that already existed. Both now call it.

Dead alias removed. useModelCustomizationEligibility returned canCustomize: canFineTune — a pure alias with zero production consumers, existing only to let callers pick a vocabulary. Removed, with its test.

Spellings normalised. Four spellings collapse to one:

was where
Finetuning Type CustomModelsDataView, GrpoParametersSection, CustomizationConfigSidePanel
fine-tuneable / Fine-Tuneable BaseModelCard.stories.tsx
Start Fine-Tuning NewCustomizationForm

GrpoParametersSection and TrainingMethodSection are siblings in one form and had disagreed with each other.

Mixed sentence rewritten. The custom-models empty state read "Customize a model with fine-tuning to meet your specific needs." with a "Customize Model" button.

The serialized filter id is deliberately not renamed

FINE_TUNABLE_FILTER_ID keeps its wire value 'customizable'. It is written into the filters search param, so renaming it would break links users have already bookmarked or shared. The constant is renamed and commented instead; the existing URL round-trip tests in WorkspaceBaseModelsRoute/index.test.tsx and routes/utils.test.ts still pin the wire value.

Type of Change

  • Code change (feature, bug fix, or refactor)
  • Code change with documentation updates
  • Documentation only
  • Contributor tooling or automation
  • CI, build, or test infrastructure

Quality Gates

  • Tests added or updated for changed behavior
  • Existing tests cover changed behavior — justification:
  • Tests not applicable — justification:
  • Documentation updated for user-visible behavior
  • Documentation not applicable — justification: no shipped docs quote these labels.

Note there is no i18n layer in web/ — no i18next, react-intl, or locale JSON — so every user-visible string is an inline literal and this is necessarily a cross-file string change rather than a message-catalog edit.

Verification

  • Pull request title follows the repository's Conventional Commit format
  • Every commit includes an appropriate Signed-off-by: trailer
  • uv run pre-commit run -a passes, or any blocked checks are identified below
  • Targeted tests pass, or tests are marked not applicable above
  • No secrets, API keys, or credentials are included

Targeted validation:

  • pnpm --filter nemo-studio-ui test — 338 files, 3320 tests passed (full suite, to catch string assertions anywhere)
  • pnpm --filter @nemo/common test — 124 files, 1549 tests passed
  • pnpm --filter nemo-studio-ui typecheck — clean
  • pnpm --filter nemo-studio-ui lint:fix — clean
  • uv run pre-commit run -a not run in full; the commit-scoped pre-commit hooks ran and passed on commit.

…ility

The Models page described one predicate with two words. The filter was
labelled "Customizable" while its only option was labelled "Fine-tunable" —
same widget, both vocabularies — and its tooltip explained it a third way.
The card beside it rendered a "Fine-tunable" badge behind a prop named
`showCustomizationBadges`.

Settles on "fine-tunable" for the user-facing model capability. That is
already what the badge, the empty-state picker ("No fine-tunable models
found"), the form, and the tooltip say; "Customization" stays where it names
the customizer service, its jobs, and their parameters, so the UI and the API
diverge deliberately rather than by accident.

Collapses the predicate to one definition. `Boolean(model.fileset)` was
re-implemented inline in WorkspaceBaseModelsRoute and BaseModelCard, neither
importing the `canFineTuneModel` that already existed; both now call it. The
`canCustomize` field on `useModelCustomizationEligibility` was a pure alias of
`canFineTune` with zero production consumers — a synonym that existed only to
let callers pick a vocabulary — and is removed with its test.

Also normalises the label spellings: "Finetuning Type" (CustomModelsDataView,
GrpoParametersSection, CustomizationConfigSidePanel) and "fine-tuneable"
(BaseModelCard stories) join the majority "Fine-tuning Type" /
"Fine-tunable". GrpoParametersSection and TrainingMethodSection are siblings
in one form and had disagreed. The custom-models empty state mixed both words
in a single sentence and is rewritten.

The serialized filter id stays `'customizable'`. It is written into the
`filters` search param, so renaming it would break links users have already
bookmarked or shared; the constant is renamed and commented instead, and the
existing URL round-trip tests still pin the wire value.

Signed-off-by: Alex Ray <alray@nvidia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant