AI does not ship as a release

The fall release slot belongs to the claims-platform upgrade. It has belonged to it since February, and it will belong to it through the regression window in November. That is a well-run release calendar doing exactly the job a release calendar exists to do.

The AI workflow that was supposed to be live in month nine is queued behind it. The sandbox extract it was built against is from March, so before UAT can restart the extract has to be refreshed, and refreshing the extract moves the test cases, and moving the test cases pushes the next realistic slot to spring. Nobody in this sequence says no to AI. The calendar says it, in a language everyone in the room already agreed to speak.

The diagnosis afterward is usually that the organization moves slowly. It doesn't. It moves at exactly the speed of its delivery method, and that method was built, over decades and for defensible reasons, to ship releases. Requirements, build, test, stage, approve, deploy. Every step in it assumes the thing being delivered is a new version of a system.

AI is not a new version of a system, and that is the argument of this piece: organizations keep trying to adopt AI through the SDLC they already have, when the SDLC is the thing AI actually changes. The unit of delivery stops being the release. It becomes the governed workflow — assessed as it really runs, then rebuilt in shadow beside the live operation. Promotion comes last, and it comes under the accountable owner's signature.

We call the method AISDLC. Three phases.

The map and the floor

Assess starts on the floor, because the process map is a document about the workflow and the floor is the workflow. The map says intake, review, determination. The floor says fax intake, rekeying across three portals, and a first-in-first-out queue that has never heard of clinical urgency. The first deliverable is that real path reverse-engineered — every system it touches, every point where a person exercises judgment, every branch the map forgot existed.

Two things then go on paper before anything gets built. The accountable owner who will eventually sign the workflow into production, by name. And the pass condition the workflow has to beat, in writing. You write that condition, and it is yours alone.

Shadow beats the sandbox

The workflow is rebuilt as a governed agent graph and run in shadow — beside the current path, on the same live inputs, while the current path keeps deciding. It sees the same faxes and the same eligibility lookups, and it is there when a policy update lands mid-quarter on a Friday afternoon.

A sandbox pilot proves the demo. It sees the data someone chose to extract, and extracts age: March data contains none of July's edge cases — the malformed fax, the eligibility mismatch, the criteria version that changed while the case was open. Shadow sees whatever the operation sees, the moment the operation sees it, and it can hurt nothing, because a shadow has no authority to act.

The sandbox tests whether the software works. Shadow tests whether it survives your Tuesday.

It also runs where your operation runs. The connectors attach to the systems you already have — mainframe included, the read-only parts marked read-only — because a method that begins with "first, modernize" is a modernization program wearing an AI badge.

Promotion is a signature

The shadow phase ends in a review. Every case where the shadow would have decided differently than the operation did, and why, goes into a divergence log, and that log is held against the pass condition written in the charter. If the evidence clears your bar, your accountable owner signs and the workflow is promoted. If it doesn't, the workflow stays in shadow, and we say so out loud. Our name does not appear on that signature line.

The signature matters more than the deploy because of who will eventually ask about it. The NAIC's model bulletin on the use of AI, adopted in roughly two dozen states, requires an insurer to hand over its AI governance documentation when an examiner asks for it. Texas SB 815 lets the insurance commissioner audit an automated decision system at any time. California's SB 1120 opens AI tools used in utilization management, and the algorithms under them, to DMHC inspection. A deploy answers "is it running." A signature answers "who signed it into production, and against what test." Promotion produces that answer as a byproduct of shipping, instead of as a scramble two years later.

The second workflow tells the truth

The first workflow establishes the operating foundation: connectors, the data boundary, human authority, evaluation, observability, and the record each run writes into. Workflow logic is one part of that production system rather than a standalone automation.

Subsequent workflows can reuse that reviewed machinery instead of rediscovering every control and integration pattern. Each still earns its own release authority against its operating boundary, evidence, and acceptance condition.

That compounding technical foundation makes larger operating models tractable: later workflows inherit proven interfaces and controls while contributing new patterns to the same governed substrate.

The change-management objection

The obvious objection is that this is change management with new vocabulary — parallel runs and staged sign-offs. Every operations leader has bought that binder at least once.

Here is why the objection misses. Change management is the discipline of moving people to a new system: training curricula, cutover weekends, adoption dashboards, floor walkers in week one. All of it presumes the destination is somewhere else. AISDLC never asks the operation to move. The intake queue is the same queue. The adjudication system is the one you already run. What changes at promotion is who does the work inside a path that stays exactly where it was. There is no cutover weekend because there is no cutover.

What the method leaves behind comes last on purpose. Every shadow run, every divergence, every gate decision and every signature lands in an append-only record that stays with the plan — reconstructable years later independently of us, and of our software.

And the method is transferable. Client teams can extend the next workflow using the same documented connectors, control model, and operating record, with clear ownership of the production boundary from the first shadow run.

From the delivery method to the engineering lifecycle

Assess, shadow, and promote describe the operating delivery method. The LockedIn Labs AI SDLC field guide maps the engineering lifecycle in eight phases, from intake and architecture through independent verification, release, operations, and retirement. Read the guide alongside our AI SDLC specifications to connect each delivery decision to the evidence required to accept it.