2025-05-14 · 3 min read

Public vs Private Adapters in a Team Registry

A team registry often needs both public and private adapters, sometimes for the same project. Public artifacts are useful for browsing, sharing, and documentation. Private artifacts are useful for experiments, internal workflows, and data that should not leave the team. The challenge is to support both without making the product feel split in half.

The most important rule is that metadata and visibility are not the same thing. A private adapter can still have a title, version, base model, sample outputs, and release notes. It simply should not expose the download by default. That keeps the registry useful for discovery while preserving access control.

Promotion is a natural workflow. A private adapter can start as an experiment, move into a team review stage, and then become public if the release is ready. The registry should reflect that journey. A clear status tag helps users understand whether an adapter is internal, pending, or public.

The UI should avoid pretending that private artifacts do not exist. It is better to show a gated card with enough metadata to be informative than to hide the artifact completely. Users can then tell that the adapter exists, what it targets, and why they need permission to access the file.

Access control should be predictable. A user who can view the card should also know whether they can download the file, see sample outputs, or inspect the job history. Mixed visibility rules lead to confusion. Keep the rules simple enough that the team can explain them without a diagram.

Private adapters are also useful for quality control. A team may keep a few internal releases private while they compare versions or gather feedback. Public release should happen only when the card, the metadata, and the evaluation notes are complete enough to support external use.

Another reason to keep the split explicit is auditability. If a public adapter changes behavior, the team should be able to trace which private experiments led to that release. A private catalog with clean versioning makes that possible without exposing half-finished artifacts to the outside world.

The release process should not change just because visibility changes. Public and private adapters should pass through the same packaging, hashing, and model card generation steps. The only difference is who can see the download and where the card appears in the catalog.

{
  "slug":"internal-support-tone",
  "public":false,
  "status":"private",
  "visibility":"team"
}

That kind of visibility flag is enough for the registry to render the right UI state. The key is consistency across the list view, detail page, and API response.

This separation is also helpful for support. If a user reports a problem with a public adapter, the team can compare it with the last private candidate and see whether the issue came from packaging, data changes, or the final promotion step. That kind of traceability is one of the quiet advantages of a well-structured registry.

A small registry can keep the policy simple by using a single boolean for visibility and a separate status for release stage. That makes the UI easier to read and keeps the API predictable. If the team later needs finer-grained roles, the structure can grow without changing the basic public/private story.

ModelForgeLab can make the public/private split feel natural by keeping one catalog and one set of metadata fields, while changing only the access policy. That avoids duplicated workflows and lets the same publishing path work for both internal and external releases.