Files

2.4 KiB
Raw Permalink Blame History

Updates for chosen project models

ModelForge follows explicitly selected Hugging Face model references. It compares the resolved commit with the exact baseline you selected. A changed commit is an opportunity to review, not proof that a model is newer, safer or better.

In Discover, create a watch for a registered model, an exact baseline revision and the upstream reference to follow. Checks fetch metadata only. Each different commit produces one stored notice; dismissing it preserves history and prevents repeated checks from reviving the same notice. Provider errors remain visible beside the last check and never imply that the current model is up to date.

In production, enabled watches are checked daily by default. Each API process checks at most one due watch per minute, and a database claim prevents processes from repeating the same completed scheduled check. There are at most 100 explicit model/reference watches. Development and test processes do not start background checks. The Console reports the configured monitor mode; individual last-check times and errors show what actually happened. You can always request a manual check with operator access.

MODELFORGE_MODEL_UPDATE_MONITOR_ENABLED=false disables automatic checks after an API restart. MODELFORGE_MODEL_UPDATE_CHECK_INTERVAL_SECONDS controls the per-watch interval (default 86400; permitted range 3600–604800). Compose passes both settings to the API. Pausing one watch stops that reference without affecting model serving.

Use Review candidate to select the exact observed model and SHA in acquisition. Review its metadata and impact before explicitly preparing a download. This action clears any previous acquisition plan; it cannot approve, download or replace a model. Tracking-baseline changes use a separate audited concurrency check and preserve old notices. They change what is compared during future checks, not the deployment.

Real project comparison, recommendation and replacement remain separate evidence and lifecycle steps. The update inbox cannot certify quality or bypass approval, private-worker scheduling, embedding reindexing or rollback requirements.

Schema 0029 stores watches and notices. Upgrade from schema0028 introduces empty tables. Once tracking history exists, rollback uses a pre-migration backup rather than deleting that history through downgrade. Restore preserves tracking state and notice provenance, but clears temporary check claims before allowing READY.