> ## Documentation Index
> Fetch the complete documentation index at: https://doc.blueapi.ir/llms.txt
> Use this file to discover all available pages before exploring further.

# Model Update Protocol: Controlled Upgrade Pipeline

> Controlled upgrade pipeline from current production version to the next. Evaluation, merge, validation, security review, and approval gates.

ModelUpdateProtocol defines the controlled pipeline for upgrading an enterprise model from the current production version to the next. This page specifies the full flowchart, approval gates, required roles, and the criteria for promotion or archival.

## Update Flowchart

The pipeline below shows every stage from the current production version to the next release.

```mermaid theme={null}
flowchart TD
    START([START]) --> CURRENT[Current vN in Production]
    CURRENT --> CANDIDATE[New Candidate / Base Model]
    CANDIDATE --> EVAL[Evaluation]
    EVAL --> MERGE[Merge / Optimization]
    MERGE --> VALIDATE[Validation]
    VALIDATE --> SECURITY[Security Review]
    SECURITY --> COMPARE[Compare with Production]
    COMPARE --> APPROVE{Approve?}
    APPROVE -->|YES| VERSION[vN+1]
    VERSION --> STAGING[Staging]
    STAGING --> PROD[Production]
    PROD --> END_PASS([END: LIVE])
    APPROVE -->|NO| ARCHIVE[Archive]
    ARCHIVE --> END_FAIL([END: ARCHIVED])
```

## Stage Definitions

| Stage                   | Description                                                                                                             | Output                                      |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
| New Candidate / Base    | Identify the research candidate or base model for the update                                                            | Candidate ID, source lineage                |
| Evaluation              | Run [EvaluationEngine](/evaluation/framework) on the Optimization Set and Validation Set                                | Candidate status: PASS, FAIL, or REGRESSION |
| Merge / Optimization    | If the update involves merging, invoke [MergeEngine](/merge/merge-engine) with [MergeStrategy](/merge/merge-strategies) | Merged artifact                             |
| Validation              | Run [ModelCompatibilityAnalyzer](/compatibility/model-compatibility), tensor shape checks, and smoke inference          | COMPATIBLE or INCOMPATIBLE                  |
| Security Review         | [Security Requirements](/security/security-requirements) audit, license check, SBOM review                              | Approved or Rejected                        |
| Compare with Production | Benchmark the candidate against current vN on the same split                                                            | Performance delta report                    |

## Approval Gates

| Gate                       | Required Role   | Criteria                                         |
| -------------------------- | --------------- | ------------------------------------------------ |
| Evaluation gate            | Model Engineer  | Candidate status is PASS                         |
| Validation gate            | Model Engineer  | Compatibility state is COMPATIBLE                |
| Security gate              | Security Lead   | Security review signed, license compliant        |
| Production comparison gate | Model Lead      | No regression on any benchmark metric            |
| Release gate               | Release Manager | All prior gates passed, rollback plan documented |

<Warning>
  Any gate failure halts the pipeline. The candidate is archived with status FAIL or REGRESSION. There is no bypass mechanism.
</Warning>

## Version Increment Rules

| Change Type                              | Version Increment | Example          |
| ---------------------------------------- | ----------------- | ---------------- |
| Architecture or tokenizer change         | MAJOR             | v1 to v2         |
| New capability, non-breaking merge       | MINOR             | v1.1 to v1.2     |
| Patch, quantization update, security fix | PATCH             | v1.1.1 to v1.1.2 |

The version increment is determined by [ModelCompatibilityAnalyzer](/compatibility/model-compatibility) and [MergeEngine](/merge/merge-engine) output, not by human discretion alone.

## Rollback Plan

Every update request must include a rollback plan before release approval:

* Previous version artifact hash
* Estimated RPO and RTO (placeholders pending operational calibration)
* Verification script for hash and smoke test
* Contact for manual override

See [Model Rollback](/enterprise/model-rollback) for the full rollback execution protocol.

## Integration

ModelUpdateProtocol is initiated by [DeploymentManager](/deployment/deployment-specification) and tracked in [ExperimentTracker](/tracking/experiment-tracking). It reads candidates from [ModelRegistry](/tracking/model-registry) and writes new enterprise versions back to the same registry with updated lineage.