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

# Agent Update Lifecycle

> How Layerup manages agent updates to dedicated SaaS clusters: advance notice windows, maintenance schedules, freeze request policy, pre-update validation, and rollback SLA.

# Agent update lifecycle — who controls updates, how you are notified, and what happens to your cluster.

This page covers how the Layerup AI Agent is updated over time, with a clear distinction between the two deployment models. For Option 2 (your private cloud), your CI/CD pipeline controls every promotion — see [CI/CD Pipeline & Deployment Strategies](/agents/lifecycle/cicd) for that model. This page is specifically for Option 3 (Layerup's Cloud), where Layerup operates the dedicated cluster on your behalf.

***

## The fundamental difference: who controls promotion

| concern                       | Option 2: Your Private Cloud                                 | Option 3: Layerup's Cloud                                                          |
| ----------------------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------------------- |
| **Who applies the update**    | Your platform engineering team                               | Layerup                                                                            |
| **What gates promotion**      | Your five-gate CI/CD pipeline (see `/agents/lifecycle/cicd`) | Layerup's internal release process + customer advance notice + freeze status check |
| **Customer veto**             | Always — your team chooses when to promote                   | Yes — via freeze request; see §U2 below                                            |
| **Rollback authority**        | Your team executes rollback via load balancer config         | Layerup executes rollback within 4 hours of a confirmed regression report          |
| **Testing before production** | Your regression test suite against historical cases          | Layerup runs validation against your dedicated cluster's shadow-mode baseline      |

***

## Two update categories

### Category 1 — Non-critical updates (new capabilities, performance improvements, dependency refreshes)

Non-critical updates include new agent capabilities, OCR pipeline improvements, dependency version refreshes, performance optimisations, and LLM orchestration framework updates that do not address a confirmed security vulnerability.

**Advance notice:** Layerup sends a release notification to your designated technical contact at least **14 calendar days** before the update is scheduled to be applied to your dedicated cluster. The notification includes:

* A changelog describing all changes in the new version
* The scheduled maintenance window (date, time, expected duration — maximum 30 minutes)
* A link to the updated SBOM and Cosign-signed image digest
* Instructions for submitting a freeze request if needed

**Maintenance window:** Non-critical updates are applied during your agreed maintenance window — a recurring time slot (e.g., Sunday 02:00–04:00 ET) established during the deployment engagement. No updates are applied outside this window for non-critical releases.

***

### Category 2 — Critical security patches (CVSS ≥ 7.0 vulnerabilities)

Critical security patches address confirmed vulnerabilities in the agent container, its dependencies, or the underlying OS layer.

| CVSS severity             | notice period   | applied during maintenance window?                        |
| ------------------------- | --------------- | --------------------------------------------------------- |
| **Critical (CVSS ≥ 9.0)** | 48 hours        | No — applied as soon as the patch is tested and validated |
| **High (CVSS 7.0–8.9)**   | 7 calendar days | Yes — next available maintenance window within 7 days     |

For Critical patches, Layerup will notify your designated contacts as soon as the patch is confirmed ready, with a minimum 48-hour window before application. For CVSS ≥ 9.0 vulnerabilities, freeze requests do not apply — Layerup will apply the patch to protect the integrity of your cluster and the BAA obligations.

***

## Freeze requests

### What a freeze is

A freeze request instructs Layerup not to apply a scheduled non-critical update to your dedicated cluster. Freeze requests are honored for up to **90 calendar days** from the scheduled update date.

**When to use a freeze:**

* Your team has a live regulatory examination or audit period where any system change must be avoided
* Your organization's change freeze calendar prohibits non-emergency changes during a specific period
* Your integration team needs additional time to validate a specific release against your UAT environment before it is applied to production

### How to request a freeze

Submit a freeze request to your Layerup implementation engineer at least **5 business days before** the scheduled maintenance window. Include:

* The specific update version you are requesting to freeze
* The duration of the freeze (up to 90 days)
* The reason (optional, but useful for Layerup to plan the rescheduled window)

Layerup will confirm the freeze in writing within 1 business day.

### Freeze limits and exceptions

| rule                      | detail                                                                                                                        |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| Maximum freeze duration   | 90 calendar days per release                                                                                                  |
| Consecutive freezes       | Permitted — but clusters more than 180 days behind the current release require a joint review with Layerup's engineering team |
| Critical security patches | Freeze requests do not apply to CVSS ≥ 9.0 patches (see Category 2 above)                                                     |
| End of freeze             | Layerup schedules the deferred update in the next available maintenance window after the freeze expires                       |

***

## Pre-update validation

Before applying any update to your dedicated cluster, Layerup runs an automated validation against a representative sample of your cluster's recent processing history:

1. **Shadow run:** The new agent version is run against the 100 most recent cases from your cluster (from the shadow mode log — no live cases are re-processed). Shadow outputs are compared against the outputs produced by the current production version.

2. **Regression check:** Layerup's release team reviews any recommendation-level differences between the shadow and production outputs. A diff rate above 2% on any decision type blocks the release from being applied to your cluster until the discrepancy is investigated.

3. **Performance check:** Processing time and confidence score distributions are compared against your cluster's established baseline. A statistically significant shift in either metric blocks the release.

If any pre-update check fails, Layerup will not apply the update to your cluster. You will be notified within 24 hours of the check failure, and a new maintenance window will be scheduled once the issue is resolved.

***

## Rollback

If a production regression is confirmed after an update is applied to your dedicated cluster, Layerup will execute a rollback to the prior version within **4 hours** of a confirmed regression report.

### How to report a regression

Contact your Layerup implementation engineer via the dedicated support channel (provided during the deployment engagement). Include:

* The case IDs exhibiting anomalous behavior
* The specific output dimension that appears incorrect (recommendation type, confidence score range, evidence citation quality)
* The approximate time the anomaly started (to correlate with the update application time)

Layerup retains the prior agent version on your dedicated cluster for **30 calendar days** post-update. After 30 days, the prior version is decommissioned and rollback to that version is no longer available.

***

## Update notification contacts

During the deployment engagement, your organization designates:

| contact role                      | purpose                                                                                                   |
| --------------------------------- | --------------------------------------------------------------------------------------------------------- |
| **Technical contact (primary)**   | Receives all release notifications, maintenance window confirmations, and pre-update validation reports   |
| **Technical contact (secondary)** | Receives all notifications in copy; acts as backup if primary is unavailable                              |
| **Security contact**              | Receives critical security patch notifications specifically; may be the same as primary technical contact |

Contact designations can be updated at any time by notifying your Layerup implementation engineer.

***

## Summary of SLAs

| commitment                                   | SLA                            |
| -------------------------------------------- | ------------------------------ |
| Non-critical update advance notice           | ≥ 14 calendar days             |
| Critical patch (CVSS 7.0–8.9) advance notice | ≥ 7 calendar days              |
| Critical patch (CVSS ≥ 9.0) advance notice   | ≥ 48 hours                     |
| Maximum maintenance window duration          | 30 minutes                     |
| Freeze request confirmation                  | ≤ 1 business day               |
| Pre-update validation report (on failure)    | ≤ 24 hours after check failure |
| Rollback execution (confirmed regression)    | ≤ 4 hours                      |
| Prior version retention post-update          | 30 calendar days               |