Deployment

Deployments happen without any formal process. A developer SSHs into a server and copies files. There is no deployment record, no version tracking, and no rollback capability. 'What version is running in production?' gets answered with 'whatever was on the server last time someone deployed.' When something breaks, nobody knows what changed or when.

None — AI cannot predict deployment risk, automate rollbacks, or correlate incidents with releases because no deployment records exist.

Deployments go through a CI/CD pipeline, but the process is loosely defined. Some deployments have release notes; others don't. Version numbering is inconsistent — some teams use semantic versioning, others use commit hashes, and some just use dates. Rollback capability exists but is untested. 'What changed in the last deployment?' requires reading through raw commit logs.

AI can see that deployments happened and identify timestamps, but cannot assess deployment content, risk level, or rollback safety because deployment metadata is inconsistent and release notes are sparse.

Deployments follow a standardized process with consistent records. Each deployment has semantic versioning, auto-generated changelogs, tagged rollback points, and a deployment manifest. Deployment pipelines run automated smoke tests before promoting to production. But deployments are self-contained events — they don't link to the engineering tasks they complete, the production metrics they affect, or the customer-facing features they enable.

AI can assess deployment content and validate pre-deployment checks. Can trigger automated rollback when smoke tests fail. Cannot predict deployment risk based on what is being deployed because deployments don't connect to business context or production health history.

Deployments are comprehensive release records with full delivery context. Each deployment links to completed engineering tasks, affected services with their production health baselines, feature flag configurations, and the rollback decision criteria. A release manager can query 'show me all deployments to the payment service in the last month, what they changed, their production error rate impact, and which feature flags were toggled' and get a complete answer.

AI can predict deployment risk by analyzing change content against historical production impact patterns for similar deployments. Can recommend optimal deployment windows based on traffic patterns and team availability. Cannot yet autonomously decide to deploy or roll back because release decision criteria aren't formalized.

Deployments are formal entities with machine-readable release criteria, quantified risk thresholds, and structured canary analysis rules. An AI agent can evaluate a pending deployment against all defined criteria — change risk score, production health of affected services, team on-call coverage, and traffic conditions — and produce a go/no-go recommendation with confidence intervals.

AI can autonomously manage routine deployments — evaluating risk, executing canary analysis, promoting or rolling back based on quantified criteria. Human decision-making is reserved for high-risk releases and novel deployment patterns.

Deployments are self-documenting release events that capture their own outcomes in real-time. Risk models recalibrate from actual deployment impact. Canary analysis thresholds adjust from observed error patterns. Rollback criteria evolve from incident learnings. The deployment process is a self-refining system that gets smarter with every release.

Fully autonomous deployment intelligence. AI manages the full release lifecycle — risk assessment, execution, canary analysis, promotion, and rollback — with continuous learning from production outcomes.

Ceiling of the CMC framework for this dimension.