​

10 — CI/CD pipeline & deployment strategies — image promotion, blue/green, shadow mode & progressive rollout.

This section describes how the Layerup AI Agent’s container image is updated over time, how your team controls its promotion to production, and the safe deployment strategies that govern both the initial production launch and subsequent major updates. It is addressed to your Platform Engineering and Underwriting Operations teams.

---

​

10.1 Two independent versioning tracks

The Layerup AI Agent operates on two independently versioned tracks. Changes to one track do not require changes to the other:

---

​

10.2 Layerup’s release process — gates before it reaches your registry

Each new container image version released by Layerup passes through the following automated gates before it is available in your AWS Marketplace subscription or ACR mirroring pipeline:

1. Automated test suite — greater than 95% code coverage requirement across unit and integration tests.
2. Static Application Security Testing (SAST) — via Semgrep, scanning all application code against a ruleset of known vulnerability patterns.
3. Dynamic Application Security Testing (DAST) — against a sandboxed test environment with representative document payloads.
4. SBOM generation — CycloneDX format, published alongside the image for your security team’s validation.
5. CVE scan — against the final built image before signing.
6. Image signing — via Cosign, anchored to Layerup’s build identity.
7. Semantic versioning and release tagging — changelog published; image available in your subscription within 24 hours of release.

---

​

10.3 Your container image promotion pipeline — five mandatory gates

When a new Layerup image version is available, your internal CI/CD pipeline governs its promotion to production. Layerup does not push image versions to your production environment — promotion is controlled entirely by your platform engineering team. Fig. A10.1 — Container image promotion pipeline. Your team controls every gate. Layerup is not involved in production promotion. Gate 1 — Vulnerability Scan: The new image is automatically scanned by Amazon Inspector (AWS) or Microsoft Defender for Cloud (Azure) when it lands in your staging ECR / ACR. Findings must meet your defined severity thresholds before promotion proceeds. Gate 2 — Regression Testing: Your QA team runs the staging agent against a defined set of historical validation cases using the current production AOP. Results are compared against the established baseline for recommendation quality and processing time. Gate 3 — Approval Gate: A designated approver (e.g., your platform engineering lead or underwriting operations lead) reviews the test results and explicitly approves the promotion. This approval is recorded in your source control system as the merge of the image version bump pull request. Gate 4 — Deployment Strategy: The approved image is promoted to the production compute environment using your selected deployment strategy (see 10.4 below). Gate 5 — Production Verification: Post-deployment, your CloudWatch Alarms / Azure Monitor Alerts are monitored for a defined settling period. Any alarm breach during this period triggers automatic rollback.

---

​

10.4 Safe deployment strategies

Given the sensitivity of AI-assisted underwriting decisions, a phased rollout strategy is strongly recommended for both the initial production deployment and subsequent major updates. Three strategies are available within your cloud-native infrastructure.

​

10.4.1 Blue/Green deployment

In a Blue/Green deployment, two identical production environments run simultaneously:

• Blue (Current): The existing production version of the Layerup agent, processing 100% of incoming cases.
• Green (New): The new version of the agent, deployed in a parallel production-equivalent environment but receiving no live traffic initially.

The promotion sequence:

1. Deploy the new agent version to the Green environment.
2. Run the Green environment’s agent against a sample of recent historical cases (not live applications).
3. Compare Green output against the established Blue baseline for recommendation quality, confidence distribution, and processing time.
4. If output quality is satisfactory, route a configurable percentage of live traffic (e.g., 10% → 25% → 50% → 100%) to the Green environment over successive days or weeks.
5. If a regression is detected at any traffic percentage, roll back to 100% Blue with a single load balancer configuration change.

On AWS, traffic shifting is implemented via ECS Service load balancer target group weights or via API Gateway canary deployment configuration. On Azure, the equivalent is Azure Container Apps’ traffic splitting feature.

​

10.4.2 Shadow Mode deployment

Shadow Mode is particularly valuable for validating a new AOP version before it influences production decisions:

• The new agent version (with the updated AOP) runs in parallel to the existing production agent for all incoming cases.
• Both agents process every case. The shadow agent’s output is logged to a separate CloudWatch Log Group or S3 bucket for offline analysis.
• The shadow agent’s output is not written back to your systems of record. It has no write access to production databases. Its outputs are read-only audit records.
• Your underwriting team reviews a sample of shadow agent outputs alongside the production agent’s outputs, comparing recommendation quality before deciding to promote the new AOP version.

This approach allows you to validate the impact of any underwriting configuration change against real live case volume, with zero risk of incorrect decisions reaching your production system of record. Fig. A10.2 — Shadow Mode. The shadow agent processes every live case alongside the production agent but writes no output to systems of record. Pure validation mode.

​

10.4.3 Progressive Volume Rollout — the recommended initial deployment sequence

The recommended initial production rollout for enterprises deploying the Layerup AI Agents for the first time is volume-progressive. The pace of progression is governed by your organisation’s own risk appetite and the agreement rate data produced at each phase.