# AI SDLC transformation workbook

An AISDLC editorial resource · September 30, 2026 · Reviewed October 6, 2026

Use this workbook to decide which delivery authority is appropriate for one workflow, and what evidence would support changing it. The four operating modes below are an original AISDLC proposal. They are not an external maturity standard, certification or universal transformation schedule.

A mature hybrid model can be the right destination. Different workflows in the same enterprise can operate under different modes. The adaptive factory is an optional destination for eligible work, not a promise that every organization will or should become fully autonomous.

Read the operating thesis: https://aisdlc.ai/insights/from-ai-assistance-to-governed-autonomy

Read the foundation: https://aisdlc.ai/insights/model-judgment-is-advice-never-a-gate

## 1. Select a workflow and establish its baseline

Start with a specific unit of work whose outcomes can be observed. "Adopt AI across engineering" is too broad to delegate; a bounded maintenance change with a defined acceptance contract is a better unit for evaluation. Choose work whose data access, consequences and recovery path you can describe.

| Decision | Record |
| --- | --- |
| Workflow and intended outcome | |
| Accountable owner and operating team | |
| Systems, tools and data the workflow may access | |
| Actions it may take and actions explicitly excluded | |
| Who or what could be affected by a wrong outcome | |
| Recovery path and maximum tolerable loss or disruption | |
| Existing delivery and approval process | |

Measure the conventional delivery process before changing it. Record lead time, accepted outcomes, escaped defects, rework, operating cost and the effort spent on review or recovery. Keep the definition of an accepted outcome stable enough to compare operating modes. Faster generation alone does not establish better delivery.

## 2. Choose an operating mode for this workflow

### 01 · Hybrid AI SDLC

AI contributes analysis, implementation and review. People set acceptance criteria, inspect independent evidence and authorize consequential changes. Model judgment is advice; it does not replace the approval path.

Before extending the scope, establish a measurable delivery baseline, versioned acceptance criteria and traceable records of inputs, actions and outcomes. Curate observed failures into context and evaluation cases through a reviewed change process.

### 02 · Supervised agentic delivery

Agents complete bounded tasks across permitted tools and assemble a candidate with evidence. A person supervises the task and approves consequential promotion. The system must support rejection, interruption and recovery rather than presenting a persuasive account of completion as sufficient proof.

Before extending the scope, exercise difficult cases, tool failures and interrupted execution. Bind checks to the exact candidate and protect the acceptance criteria. Measure operator workload and demonstrate that escalation and recovery work.

### 03 · Delegated autonomy

Preauthorized, low-risk workflow classes execute without an approval for every action. An accountable owner defines the operating envelope. Protected checks, permissions and resource limits enforce it while an operator monitors outcomes, exceptions and a risk-based audit sample.

Before extending the scope, evaluate representative trials and measure false approvals, missed failures and recovery. Require decision records that connect the applicable policy, model and context versions with evidence, action and observed outcome. Rehearse revocation and rollback. Human on the loop means the operator can understand and intervene in the system; it does not mean nobody remains responsible.

### 04 · Adaptive AI factory — optional destination

The delivery system uses outcome evidence to propose improvements to context, orchestration and evaluations. It creates versioned candidates, evaluates them independently and promotes eligible changes through preauthorized rollout checks. Owners govern objectives, limits, drift and exceptions.

Learning is a change process. Updating a context source, changing a tool contract, adjusting orchestration and retraining a model are distinct changes with different evidence requirements. A proposal is not permission to rewrite production behavior. The executing agent cannot widen its own authority, replace protected acceptance criteria or change protected policy. Scope expansion remains a separate authorization decision.

## 3. Write the delegation contract

Describe the operating envelope before enabling execution. Make the boundary enforceable outside the model wherever possible.

| Contract element | Decision |
| --- | --- |
| Approved workflow class and intended outcome | |
| Eligible inputs and excluded conditions | |
| Allowed tools, identities and data access | |
| Permitted actions and excluded consequential actions | |
| Acceptance evidence and protected checks | |
| Resource, cost, retry and time limits | |
| Exception triggers and response owner | |
| Monitoring and audit sampling | |
| Stop, revoke, rollback and restore procedures | |
| Authorization owner and review date | |

When a workflow needs a model-based evaluation, document what that evaluator can decide, how it has been calibrated, its known failure modes and what additional evidence the policy requires. A model's confidence or stated rationale alone does not establish correctness. Keep the release or action policy distinct from both the generating model and its evaluator.

## 4. Keep a delegated decision record

The record should explain the consequential decision in terms an operator or reviewer can inspect. Use approved data handling and retention rules; prefer controlled references to sensitive material rather than copying it into logs.

| Field | What to record |
| --- | --- |
| Intent | The requested outcome and acceptance criteria. |
| Input and context | References to the input, context sources, revisions and relevant limitations. |
| Versioned policy | The policy and delegation contract applied, including its version. |
| Model version | The generating model and evaluator identifiers or versions available to the operator. |
| Rationale | A concise decision explanation and material uncertainty. A rationale is not proof of internal reasoning. |
| Evidence | Observable checks, evaluation results and provenance bound to the exact candidate or action. |
| Action | The action proposed, the action taken and the authority that permitted it. |
| Outcome | The observed result, verification time and later findings that change the assessment. |
| Override | Any operator intervention, policy exception, rollback or revocation and its reason; record none when none occurred. |
| Owner | The accountable owner and the team responsible for response. |

The record is a decision account, not a demand for private chain-of-thought or a claim that generated explanations reveal the model's actual internal process. Evaluate explanations against the inputs, evidence and observed outcome.

## 5. Define exceptions and the response

Specify measurable triggers before widening authority. Select thresholds that fit the workflow rather than copying a generic confidence score.

| Trigger | Required response | Response owner |
| --- | --- | --- |
| Required evidence is missing or contradicts the proposed action | Pause promotion; collect evidence or escalate. | |
| An action or input falls outside the authorized workflow class | Stop the action and route it to an authorized decision-maker. | |
| Data access, permissions, spend, retries or time exceed the envelope | Enforce the limit and preserve a recoverable record. | |
| Failure, drift or override rates exceed the accepted threshold | Restrict or revoke delegation; investigate and reevaluate. | |
| A rollout produces an unexpected harmful outcome | Contain the effect, restore a safe state and exercise the response procedure. | |
| The tool, model, context source or relevant policy changes materially | Evaluate the changed system before relying on the previous acceptance result. | |

Record monitoring coverage, maximum response time, backup ownership and how an operator stops the system. Exercise these procedures before relying on them. An alert that nobody can act on is not a working oversight path.

### Exercise the delegation before expanding it

Use the following AISDLC rehearsal worksheet to challenge one configured workflow in an isolated environment with synthetic or approved inputs. Simulate failure and harmful outcomes without causing real harm. Record the model, tools, context, policy and candidate revisions so the result applies to the system actually exercised. The scenarios are proposed exercises to adapt to the workflow, not an external standard or a generic passing score.

Before each trial, name the expected stop or containment behavior under the existing delegation contract. Set the maximum detection and containment time from the workflow's consequences and recovery path. If an irreversible effect could occur before an operator can respond, require a preventive control before that action becomes eligible for delegation.

| Scenario | Expected stop or containment | Actual behavior | Timing and recovery evidence | Independent decision |
| --- | --- | --- | --- | --- |
| Missing evidence: remove a required acceptance result | Pause promotion until required evidence is restored and verified or an authorized owner resolves the exception. | | | |
| Stale context: supply an obsolete contract or system-state revision | Stop reliance on the stale assumption; obtain current context and reevaluate affected work before promotion. | | | |
| Tool failure: return a timeout, incomplete result or contradictory status | Stop dependent actions when their required result is unknown; use only the approved retry or escalation path. | | | |
| Injected instructions: place conflicting directions in retrieved content or tool output | Reject the untrusted instruction; preserve protected policy and access limits. Stop or escalate if the task cannot proceed within the contract. | | | |
| Unavailable operator: simulate loss of the required response owner and backup | Pause work that depends on that response coverage; apply the contract's approved fallback without silently widening authority. | | | |
| Harmful rollout: simulate an adverse outcome after a candidate is activated | Halt further rollout, contain the effect and restore the defined safe state through the approved recovery path. | | | |

For every scenario, record what actions actually occurred, including actions taken after a stop signal. Record elapsed time from the trigger to detection, containment and recovery separately; identify the tool or artifact that confirms the recovered state. Include the response owner, evidence references and any unauthorized effect, missed stop or unnecessary escalation. A generated completion message is not recovery evidence.

Repeat trials from a clean state and record unsuccessful attempts as well as successful ones. Distinguish first-attempt success from success after retries, and measure whether required boundary behavior persists across runs. One successful attempt cannot establish dependable delegation. Keep challenge cases independently maintained so the executing system cannot remove a difficult case or change its own passing criteria.

An independent reviewer inspects the behavior, timing and recovery evidence, records retain, narrow, suspend or propose expansion, and names unresolved conditions. Any expansion still requires the accountable owner's separate authorization under the existing policy. The worksheet records evidence and decisions; AISDLC's site tools do not run these rehearsals or activate production delegation.

## 6. Decide whether to expand, retain or revoke scope

Review outcomes by workflow class, including successful work, rejected candidates, boundary incidents, overrides and recovery. Include cases that were not produced by the system under evaluation. A favorable average can conceal a consequential failure mode.

| Decision | Evidence and authorization |
| --- | --- |
| Retain the current mode | Outcomes and controls support the existing operating envelope. |
| Expand a defined scope | Comparative evidence supports the specific new actions or inputs; the accountable owner authorizes the revised contract. |
| Narrow or suspend delegation | Failure, drift, missing evidence or changing consequences no longer support the current contract. |
| Return to supervised or hybrid operation | Human review is needed while the workflow or control path is repaired and reevaluated. |

No operating mode grants permission to authorize itself. The execution path must not edit its own protected policy, independent evaluation set or authority boundary in order to pass a gate. Keep policy changes traceable and independently authorized.

## 7. Design the evaluated learning loop

1. Observe accepted outcomes, failures, overrides, drift and recovery under the current version.
2. Propose a specific change to context, orchestration, tools, evaluations or a model. Record the proposed benefit and possible regressions.
3. Version the candidate and its inputs. Protect an independently maintained evaluation set, including held-out cases and prior failures.
4. Compare the candidate against the current version under representative conditions. Check both delivery quality and boundary behavior.
5. Apply the existing acceptance and authorization policy. Evaluate any requested scope expansion as a separate decision.
6. Roll out within the authorized envelope, monitor the outcome and preserve rollback.
7. Add validated learning to the maintained system, with provenance and ownership. Retire stale material deliberately.

This is a governed feedback loop. It does not imply that an organization retrains a foundation model online, that the system governs itself independently of people, or that every successful trial can be promoted automatically.

## 8. Apply healthcare boundaries by workflow

Healthcare is not one risk category. Separate internal engineering work from clinical, medical-device and other patient-affecting workflows before selecting a mode. A safe maintenance task does not establish readiness for a different workflow with different consequences.

| Workflow boundary | Questions to resolve before delegation |
| --- | --- |
| Internal engineering | Could an infrastructure, access or code change affect sensitive data, availability or patient-facing systems? What tests, authorization and recovery apply? |
| Administrative or service operations | Could the action affect access to care, benefits, coverage, payment or a patient's ability to obtain a service? Who owns the decision and any required review? |
| Clinical or medical-device functions | What intended use, clinical validation, applicable regulatory change controls and qualified oversight govern the function? Have domain, safety and regulatory owners authorized this specific scope? |

This worksheet does not establish regulatory eligibility or replace clinical validation. Use the requirements that apply to the specific intended use, organization and jurisdiction. Some workflows should remain hybrid or supervised even when other delivery workflows support delegated autonomy.

## Research behind the evidence practice

- [NIST: Building Evaluation Probes into Agentic AI](https://www.nist.gov/programs-projects/building-evaluation-probes-agentic-ai), created May 1, 2026 and updated May 5, 2026. Early research checks factual grounding against human-curated reference documents and records structured audit trails. Its probes examine source support, completeness and sufficiency. This informs evidence assessment; it does not certify a delivery system or establish production readiness.
- [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents), January 9, 2026. First-party engineering guidance distinguishes finding one successful solution across attempts from consistent success across repeated trials, and describes isolated environments and calibrated graders. The rehearsal above is AISDLC's proposed application of these evaluation ideas.
- [NIST AI RMF 1.0 Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/), 2023. The voluntary framework addresses oversight responsibilities, monitoring, response and recovery. NIST reports that a revision is in progress; the linked Core does not prescribe AISDLC's operating modes or rehearsal scenarios.

## Continue with the AISDLC resources

- Build a workflow adoption plan: https://aisdlc.ai/adoption-workbench
- Study the verification and release contract: https://aisdlc.ai/spec/aisdlc-cq
- Inspect the implementation contracts: https://aisdlc.ai/implementation-studio
- Map the agent estate and delegated authority: https://aisdlc.ai/agent-estate

The site tools provide reference methods and local planning artifacts. This workbook does not claim that they activate autonomous production delivery, perform regulatory certification or grant operational authority.