Publish curated ITWorx-ModelForge source from 990401737f96c8d46a9f7b0d84994516cadcb6a0

docs/operations/MODEL_UPDATES.md

@@ -0,0 +1,38 @@
+# 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.