Publish curated ITWorx-ModelForge source from 990401737f96c8d46a9f7b0d84994516cadcb6a0

docs/operations/CONFIGURATION_WORKFLOW.md

@@ -0,0 +1,54 @@
+# Managing serving configuration
+
+Open **Configuration** after unlocking the Console. The catalog lists typed values, deployment
+source where provable, sensitivity, validation bounds and whether the value is editable.
+
+Five numeric controls have a live serving consumer: embedding batch size, input character limit,
+gateway request timeout, gateway queue timeout, and telemetry staleness threshold. Other entries
+remain deployment-managed. The separate Scheduler policy workflow remains authoritative for its
+policy values; this editor cannot create a competing scheduler policy.
+
+1. Enter one or more safe overrides. Queue timeout must remain below request timeout. Use
+   **Use deployment value** to remove an existing override.
+2. Choose **Preview changes**. Review before/after values, source changes and impact.
+3. Acknowledge the impact and choose **Apply reviewed changes**. Administrator authority is
+   required; operators may preview and viewers may inspect.
+4. The result names the accepted revision and consumer. The API's serving policy reader uses that
+   snapshot for new requests. Requests that already consumed their configuration retain their
+   snapshot; no worker restart or model promotion is implied.
+
+If another operator applies a change or deployment-resolved values change after preview, apply
+fails with a conflict. Refresh and preview again; the Console does not retry mutations silently.
+
+**Revision history and rollback** retains actor, time, request correlation and complete override
+sets. Restoring an earlier revision or deployment defaults creates another preview followed by
+explicit apply. It does not erase history. Revision zero means the current deployment defaults;
+it does not restore an old environment file.
+
+**Export and import safe overrides** exports JSON with format/product compatibility metadata,
+safe overrides and names of secret slots. It excludes connection strings, credentials and unrelated
+deployment topology. Import replaces the complete override set after a compatibility check and
+review. Slot names are references only; imports never set, rotate or revoke secrets.
+
+Bootstrap and deployment-managed credentials still require the deployment's documented procedure.
+The fixed Hugging Face control-plane slot has a separate administrator-only write-only workflow for
+candidate creation, testing, activation, rotation and revocation; it never reveals or exports a
+token. It does not manage node download credentials. See the [secret lifecycle procedure](SECRET_LIFECYCLE.md).
+Do not paste credentials into the numeric editor or a configuration export.
+
+## Persistence, upgrade and recovery
+
+Schema `20260907_0025` adds `configuration_state` and `configuration_revisions`. Both are
+authoritative PostgreSQL backup state. A validated override, active pointer and attributable audit
+event commit together. Failed audit writes roll back the configuration change. Runtime credentials
+can append revision history but cannot update, delete or truncate it.
+
+The migration leaves existing model, project, credential and audit evidence unchanged and initially
+introduces two empty tables. It supports a mechanical downgrade only while there is no operator
+revision history. After configuration changes, recovery uses the verified pre-migration backup;
+the downgrade guard refuses to destroy the history. Restore compatibility accepts older-schema
+backups only when the added configuration tables are exactly empty, and requires exact retained
+configuration fingerprints for schema-0025 restores.
+
+This source milestone does not create a release or change the deployed 1.2.2 schema. A release
+requires exact-head validation and the separate install/upgrade/rollback qualification.