AI SDLC Factory

Phase operating contract

Seven phases. Named human authority. Evidence at every exit.

Each phase starts from an accepted input, bounds where AI can assist, names the accountable human role, and ends at an evidence-backed decision gate. A failed gate creates remediation work; it does not transfer accountability to an agent. The verifiers named in each contract are the documented operating standard for that phase; current in-force coverage is stated in the verifier register.

01

Define / Classify

Purpose: Establish the outcome, use-case class, data boundary, risk posture, and authority model.
Entry criteria: Sponsored problem statement with a named business owner and affected users.
Permitted AI assistance: Summarize approved sources, map requirements, and draft risk questions; AI cannot make the final classification.

Verifiers

Preventive. Source-provenance check on every cited requirement or regulation and a data-classification completeness check on each named data element. Gate. A risk-tier rule check that stops an unclassified use case from advancing.

Accountable human: Product owner with the designated risk and data authority.
Required outputs: Use-case brief, success measures, data classification, risk tier, and authority boundary.
Exit gate: Scope, risk tier, data boundary, and decision rights are accepted by the named owners.
Evidence link: Inspect lifecycle traceability

02

Decompose / Plan

Purpose: Convert the accepted outcome into owned, testable work with explicit dependencies and completion criteria.
Entry criteria: Accepted use-case brief, risk tier, data boundary, and success measures.
Permitted AI assistance: Draft decomposition, acceptance criteria, dependency maps, and test scenarios for human review.

Verifiers

Inline. Acceptance-criteria testability check on every generated work item, requirement-coverage check against the accepted brief, and a dependency-cycle check across the proposed decomposition.

Accountable human: Product owner and delivery lead.
Required outputs: Product requirements, backlog, acceptance criteria, definition of done, dependency map, and test plan.
Exit gate: Bounded work orders have owners, acceptance criteria, dependencies, and an agreed review path.
Evidence link: Inspect the traceability dashboard

03

Architect / Secure

Purpose: Set the service, data, integration, identity, threat, and human-oversight design before implementation.
Entry criteria: Bounded backlog, acceptance criteria, data classification, and risk tier.
Permitted AI assistance: Draft diagrams, threat scenarios, control mappings, and options; AI cannot accept architecture or security exceptions.

Verifiers

Inline. Control-mapping completeness check against the applicable security and privacy controls, data-flow verification that no PHI path crosses an unapproved boundary, and a threat-coverage check that every declared trust boundary carries at least one identified threat.

Accountable human: Designated solution architect plus security reviewer.
Required outputs: Architecture decision record, data flow, threat model, permission map, and control mapping.
Exit gate: Architecture and security reviewers accept the design or return it with recorded remediation.
Evidence link: Review the security control gates

04

Build / Integrate

Purpose: Create and integrate the change inside the approved design and controlled workspace boundary.
Entry criteria: Approved design, scoped work order, repository boundary, allowed tools, and test expectations.
Permitted AI assistance: Generate code, tests, documentation, and integration artifacts in allowlisted tools; no autonomous merge or production action.

Verifiers

Inline. Secret and PHI pattern scan on every diff, contract and schema conformance against the registered API and service contracts, and protected-lane and diff-scope enforcement that stops writes outside the declared work-order scope.

Accountable human: Engineering owner and named code reviewer.
Required outputs: Code and configuration diff, tests, documentation, provenance record, and run manifest.
Exit gate: Code review, integration checks, and workspace evidence are complete or remediation is assigned.
Evidence link: Inspect the scoped run evidence path

05

Validate / Test

Purpose: Demonstrate functional, security, privacy, accessibility, integration, and AI-specific behavior against the plan.
Entry criteria: Reviewed release candidate, approved test plan, traceable acceptance criteria, and available test environments.
Permitted AI assistance: Generate and run allowed tests, analyze results, and propose remediation; AI cannot accept residual risk.

Verifiers

Inline. Test-to-requirement mapping check so every acceptance criterion has an executing test, evidence-capture integrity check on each artifact as it is recorded, and a redaction scan across captured screens, payloads, and logs before they enter the packet.

Accountable human: QA owner with the required security, privacy, compliance, and product reviewers.
Required outputs: FIT and UAT results, scans, evaluations, accessibility evidence, defects, and an open-gap record.
Exit gate: Required tests pass and each open gap has a named human disposition.
Evidence link: Inspect current evidence readiness

06

Package Evidence

Purpose: Assemble a reviewable record that connects requirements, changes, tests, controls, approvals, gaps, and rollback.
Entry criteria: Validated candidate with resolved findings or explicit human disposition for every remaining gap.
Permitted AI assistance: Collect, index, hash, and cross-reference artifacts; AI cannot designate a package export-ready.

Verifiers

Gate. Artifact-completeness check against the required packet contents, manifest and hash verification on every included file, and an open-gap check that refuses a package where any gap lacks a named human disposition.

Accountable human: Evidence owner with compliance and release-authority review.
Required outputs: Evidence index, manifests, test records, approvals, rollback record, and unresolved-gap register.
Exit gate: A named reviewer records package completeness, open gaps, and export-readiness disposition.
Evidence link: Inspect the current FIT evidence-readiness record

07

Release / Operate

Purpose: Make and execute the release decision, then operate with telemetry, support, rollback, and change control.
Entry criteria: Reviewed evidence package, named release authority, deployment plan, rollback path, and support owner.
Permitted AI assistance: Assist deployment, summarize telemetry, and propose bounded remediation; no release approval or unbounded production action.

Verifiers

Gate. Deployment-plan and rollback-path presence check and approval-record completeness check against the named authorities. Continuous. Post-deploy smoke verification that runs before the change is declared operating.

Accountable human: Release authority and operations owner.
Required outputs: Release decision, change record, deployment ID, smoke test, rollback record, support handoff, and telemetry.
Exit gate: Release and operating acceptance are recorded; incidents and material changes return to the applicable phase.
Evidence link: Review the release packet procedure

Verification control plane

Observability tells you what happened. A control plane determines what is allowed to happen.

Governance sets the rules. The control plane puts them into operation — named, independently owned checks that act before generation, inside it, and at release, so release review becomes the last check rather than the first one that matters.

Read the full doctrine

01 Before generation Preventive verifiers The agent cannot. Halts the work
02 During generation Inline verifiers Checked while working, not after. Halts the work
03 Before release Gate verifiers Nothing ships unverified. Halts the work
04 After release Continuous verifiers Detection, not control. Observes only

How the plane binds the lifecycle

Four verifier classes. No agent verifies its own output. Control acts before and during, not only after.

Observability reports what an agent already did. By the time a dashboard surfaces an unsafe write, an exposed member identifier, or a requirement that was never implemented, the work is finished and the only remaining option is remediation. The verification control plane places named, independently owned checks ahead of generation and inside it, so the boundary is enforced while the work happens.

This is a layer across the existing lifecycle, not an addition to it. The seven phases, the thirteen security and compliance control gates, and named human release authority are unchanged. The AI SDLC defines what happens and who decides; the verification control plane names the checks that enforce those decisions, when each one acts, and who can override it.

What counts as a verifier: A verifier is a named, independently owned check with a defined trigger, a defined scope, stated authority to block, and a recorded disposition. A check with no owner, no trigger, or no recorded outcome is not a verifier; it is a suggestion.
Documented operating standard: The four classes below are the documented WHPS operating standard. Where a specific verifier is in force today it is marked in the register; everything else is the standard the estate is being brought to.

Verifier classes

Ordered by when control acts, from before generation to after release.

01

Preventive verifiers

Before generation

The agent cannot.

Implementation Documented standard. Risk tiering, data classification, model and tool gateway routing, and scoped workspaces are defined in the method today; enforcement coverage across delivery lanes is the target state, not a current claim.

Bounds the action space before an agent produces anything. Policy-as-code, scoped identity, allowlists, protected-lane declarations, and packaged context decide what work is reachable at all. Every constraint applied here removes output that a later layer would otherwise have to inspect, which is why guidance is treated as preemptive verification rather than as documentation.

Verifiers in this class

PHI data-boundary policy — agent workspaces must resolve de-identified or synthetic fixtures only; production PHI stores must not be reachable from any generation context.
Scoped, time-bound workspace credentials — no standing production, DB2, or CMS EDE connectivity may be issued to an agent session, and expiry must be enforced by the issuer rather than by convention.
Tool and dependency allowlist — only registered tools, runtimes, and approved package sources resolve; unlisted network egress fails closed.
Protected-lane declaration — DB2 and mainframe coexistence code, CMS EDE transaction handlers, payment boundary code, and evidence-generation tooling must be read-only unless a work order names the lane and its owner.
Approved-context package — the agent receives the requirement row, acceptance criteria, applicable CMS source reference, architecture decision record, and coding standard; context from unapproved sources is not admitted to the run.
Diff-scope boundary — the work order fixes the writable file scope, and paths outside it are not writable for the duration of the run.
Model and tool gateway routing — every request routes through the registered gateway with data policy, residency, retention, and logging attached before the first token is generated.

On failure: The action never resolves. There is no output to review because the attempt cannot execute. The blocked request is logged against the work order, and if the boundary itself is wrong it changes through policy review — not through an exception granted inside a delivery run.
Authority: Security architecture and platform engineering own the policy set. Data-boundary and PHI rules are owned by the privacy and security functions. Boundaries are changed by their owners, in review, with a record.

02

Inline verifiers

During generation, inside the agentic inner loop

Checked while working, not after.

Implementation Documented standard. This is the target in-loop control set for AI-assisted delivery; it is not presented as running on every WHPS build today.

Runs against partial work while the agent still holds the task. A failing inline verifier blocks and returns a specific correction signal — the failing contract, the offending path, the detected pattern — which the agent must resolve before it can advance. This is the layer that answers what is actually controlling the work between the instruction and the pull request, and it is the difference between a process that inspects AI output and a process that constrains it.

Verifiers in this class

Contract and schema conformance — generated request and response shapes are checked against the registered CMS EDE API contract and the service schema on every write, not once at the end.
Deterministic test execution — the affected unit and integration suites run on each change, so a regression is surfaced in the session that caused it.
Secret and credential pattern scan — keys, tokens, connection strings, and certificate material are detected in the diff before it can be staged.
PHI pattern scan — member identifiers, subscriber IDs, dates of birth, and claim identifiers are detected across code, fixtures, log statements, and test data.
Data-flow check — any path from a PHI-classified source to a log sink, external call, cache, or unencrypted store stops the loop.
Protected-lane and diff-scope enforcement — a write outside the declared scope, or into a protected DB2 coexistence or evidence-tooling path, halts the run and names the owning lane.
Standards and complexity check — coding standard, dependency policy, and complexity thresholds are enforced per change, so technical debt is not accumulated silently at generation speed.

On failure: The loop blocks. The agent receives the failing check, the location, and the expected condition, and cannot advance until the condition is met. Repeated failure against the same verifier escalates to the engineering owner instead of retrying indefinitely. The attempt count and the final disposition are recorded on the run manifest and travel with the change.
Authority: The engineering owner named on the work order. Inline verifiers block automatically. Only that owner can pause a run and route it to review, and no inline verifier can be waived from inside the run it is checking.

03

Gate verifiers

Before release, in the CI verification loop

Nothing ships unverified.

Implementation Partly in force today. The thirteen security and compliance control gates, the release packet contract, a completed penetration test, the evidence vault, and named human release authority are operating. The agentic verification layer described here is the documented standard.

Applies zero-trust, multi-layered verification to the completed change. Algorithmic verification is deterministic and repeatable. Agentic verification reads intent and business meaning. Both layers run against the same candidate, their findings are fused into a single disposition list with severity and owner, and the gate closes at named human authority. The thirteen security and compliance control gates and the release packet contract are the WHPS expression of this class.

Verifiers in this class

Static analysis and dependency policy — SAST, software composition analysis, secret detection, and license and vulnerability thresholds against the build (control gate 05).
Dynamic and API testing — runtime scans, authentication validation, and route behavior against the deployed candidate (control gate 07).
Independent penetration testing — business-logic, escalation, and attack-path validation performed outside the delivery team (control gate 08).
CMS EDE requirement conformance — an agentic reviewer reads the change against the requirement row and acceptance criteria and reports behavior that is unimplemented, partially implemented, or implemented beyond scope.
Intent-versus-implementation review — an independent agentic reviewer of different model lineage from the generator works from the requirement rather than from the diff and reports where the code does something other than what was asked.
Evidence completeness check — the release packet is checked for required artifact types, manifests, hashes, approvals, and a named disposition against every open gap before it can be presented for review.
AI-specific evaluation — grounding, prompt-injection resistance, privacy, and output-handling evaluations for any model, prompt, tool, or agent-policy change.

On failure: The release is held. Findings become remediation work with a named owner and return to the applicable phase. A finding may be dispositioned as accepted residual risk only by the accountable human at control gate 13, recorded in the risk register with severity, owner, and remediation path. A held gate does not expire on its own and cannot be cleared by re-running the pipeline.
Authority: QA, security, privacy, compliance, and product reviewers hold their own gates; the named human release authority holds the final disposition at control gate 13. No agentic reviewer approves a release, and no agentic finding closes itself.

04

Continuous verifiers

After release

Detection, not control.

Implementation Documented standard. Runtime telemetry, incident response readiness, and revocation paths are already required by the release packet and control gates 11 and 12.

Watches the released change in operation: runtime telemetry, drift, regression, override rates, and incidents. This is the observability layer — the last line, not the control. Everything it reports has already reached a member, a partner, or a regulated transaction. Preventive, inline, and gate verifiers therefore carry the primary assurance burden.

Verifiers in this class

CMS EDE transaction monitoring — submission, response, and error-rate watch with a correlation ID per transaction.
Data-boundary runtime alerting — PHI access outside expected service identities, paths, and hours.
Model and prompt drift watch — output distribution, refusal and override rate, and evaluation replay against the release baseline.
Coexistence regression watch — DB2-to-PostgreSQL parity checks and variance reporting while DB2 remains authoritative.
Dependency re-scan — released components re-checked as new advisories land, rather than only at build time.
Incident feedback into the maintenance loop — every AI-derived defect is classified and returned as a verifier change, not only as a code fix.

On failure: An alert opens an incident or a remediation item with a named owner, and the change re-enters the lifecycle at the applicable phase. Where the incident traces to a condition an earlier verifier should have caught, the corrective action includes adding or tightening that verifier. The finding changes the control plane, not just the code.
Authority: Operations owner and incident commander. Declaring an incident, approving rollback or cutover, and notifying partners or regulators remain human decisions.

Non-negotiable principles

Two rules decide whether a check is verification or reassurance.

Zero-trust independence

No agent verifies its own output.

A verifier has to be independent of whatever produced the work: a deterministic tool, or a reviewing agent of different model lineage that reads the requirement rather than the diff it is checking. A model carries the same blind spots on the second pass that it carried on the first, so single-model self-review reports confidence, not correctness. Independence is what makes the disposition worth recording, and named human authority still holds it.

Fusion, not either-or

Algorithmic and agentic verification run together.

Algorithmic verification is deterministic and repeatable. It finds known patterns, unsafe data flows, exposed secrets, broken contracts, and policy violations, and it finds them the same way on every run. Agentic verification reads intent: whether the change implements the requirement, whether the business logic is right for a regulated transaction, and what nobody thought to write a rule for. Each layer is blind exactly where the other sees, so a gate running only one of them is a gate with a known hole in it.

Three loops

Verifiers operate in every loop, and each loop fails differently without them.

01

Inner agentic loop

Guide, generate, verify inline, correct.

Guide — the work order carries the requirement, acceptance criteria, architecture decision, coding standard, data boundary, and writable file scope.
Generate — the agent produces a bounded change inside the declared scope.
Verify inline — contract, test, secret, PHI, data-flow, complexity, and scope verifiers run against partial work.
Correct — a failing verifier returns the specific condition and the agent resolves it before advancing; repeated failure escalates to the engineering owner.
Hand off — the change leaves the loop with a run manifest recording every verifier that ran and its disposition.

What verification does here: Inline verification turns a plausible change into a checked one before a human reviewer ever sees it, and keeps the cost of correction inside the session that created the defect.
What fails without it: The first real inspection lands at code review, where a person is asked to spot a subtle data-flow or contract defect by reading a diff that looks correct. At agent throughput, volume wins that contest.

02

CI verification loop

Multi-layer verification, fused findings, human gate.

Assemble — the release candidate, its tests, scans, provenance, and requirement references are collected.
Verify algorithmically — static analysis, dependency and license policy, secrets, data and control flow, schema conformance, and the deterministic suites.
Verify agentically — independent review of intent, requirement conformance, and business logic, worked from the source requirement rather than from the generated change.
Fuse — findings from both layers land in one disposition list with severity, owner, and remediation path.
Close at human authority — QA, security, privacy, compliance, and the named release authority accept, hold, or return the candidate.

What verification does here: This is where zero-trust is enforced at the artifact level: nothing is treated as correct because it passed the loop that produced it.
What fails without it: The pipeline reports green on everything it knows how to ask about and stays silent on the requirement that was never implemented. That silence is what reaches an auditor.

03

Maintenance loop

Verified remediation as debt control.

Measure — complexity, duplication, dependency age, coverage, and defect density are tracked per service rather than per release.
Prioritize — debt that raises verification cost or degrades agent comprehension is scheduled as work, not carried as an aspiration.
Remediate under the same controls — remediation changes pass the same preventive, inline, and gate verifiers as feature work.
Verify the reduction — the measure moves or the remediation is not finished.
Feed back — incidents and repeat findings become new or tightened verifiers in the control plane.

What verification does here: Verification is what keeps remediation honest, and it is what converts an incident into a control change instead of a one-time patch. A cleaner codebase also measurably lowers the effort each subsequent agent run needs, so maintenance compounds instead of competing with delivery.
What fails without it: The estate absorbs complexity at generation speed. Every later change costs more context, raises more findings, and takes longer to verify, until the acceleration is fully spent servicing the debt it created.

Verifier register

Every verifier is named, owned, triggered, and dispositioned.

Each row states when the check fires, whether it is deterministic or agentic, whether it can stop work, and what record it leaves behind. Rows marked as documented standard describe the operating standard rather than a claim of production coverage today; rows marked in force are operating now.

Verifier register — twelve named verifiers.
ID	Verifier	Class	Trigger	Owner	Layer	Authority	Recorded disposition	Standing
V-01	Approved-context package check	Preventive	Before a work order is released to an agent	Security architecture	Human	Blocks	Context manifest listing the requirement row, acceptance criteria, CMS or business source reference, architecture decision record, and applicable standard. An incomplete manifest holds the work order.	Documented standard
V-02	Workspace credential scope check	Preventive	At agent session start and on every credential request during the run	Security architecture	Algorithmic	Blocks	Session record carrying issued scope, expiry, and every denied request. Standing production, DB2, or PHI-store credentials are never issued to a generation context.	Documented standard
V-03	PHI boundary scan	Inline	On every generated diff, fixture, log statement, and test dataset in the work order	Platform engineering	Algorithmic	Blocks	Run-manifest entry recording pattern class, file, line, and cleared or blocked state. A positive result stops the loop before the change can be staged.	Documented standard
V-04	Secret and credential exposure scan	Inline	On stage of any change, before commit	Platform engineering	Algorithmic	Blocks	Scan record attached to the diff. A positive result voids the staged change and triggers rotation of any exposed material, recorded against the incident path.	Documented standard; the same control is a control gate 05 deliverable
V-05	Protected-lane and diff-scope guard	Inline	On any write outside the declared file scope, or into a protected DB2 coexistence, payment-boundary, or evidence-tooling path	Security architecture	Algorithmic	Blocks	Blocked-path record on the run manifest naming the attempted path and the owning lane. Extending the scope requires a revised work order, not an in-run override.	Documented standard
V-06	Contract and schema conformance	Inline	On change to any CMS EDE request or response handler, service schema, or published interface	Platform engineering	Algorithmic	Blocks	Conformance result per contract version, stored with the build and referenced from the release packet.	Documented standard
V-07	Dependency and license policy	Gate	On build, and on every dependency addition or version change	Security engineering	Algorithmic	Blocks	Software composition analysis report with vulnerability severity, license disposition, and resolved findings.	Documented standard; control gate 05 deliverable
V-08	CMS EDE requirement conformance review	Gate	On any release candidate affecting an EDE-mapped requirement	CMS EDE requirements owner	Agentic	Flags	Finding list mapped row by row to the traceability spine, each finding carrying a named human disposition before the gate can close.	Documented standard; the traceability spine it reads is implemented today at 21 mapped rows
V-09	Intent-versus-implementation review	Gate	On every release candidate produced with AI assistance	Named code reviewer	Agentic	Flags	Independent review record naming reviewer lineage, the findings raised, and the reviewing engineer's disposition on each. The reviewer works from the requirement, not from the generated diff.	Documented standard
V-10	Evidence completeness check	Gate	When a release or audit evidence packet is assembled	Evidence owner	Algorithmic	Flags	Packet index listing present and missing artifact types with manifests and hashes; a named reviewer records export-readiness. Current MarketLink state: 0 export-ready, 1 review candidate, 11 pending captures, and 1 source-pending case.	In force — evidence vault and current auditor packet are operating
V-11	Release authority sign-off	Gate	At control gate 13, before any production movement	Release authority	Human	Approves	Named release decision with residual-risk record, exceptions, rollback path, deployment ID, and support handoff. This disposition is never delegated to an agent.	In force — named human release authority
V-12	Drift and regression watch	Continuous	Continuously after release, and on every model, prompt, or dependency change to a released component	Operations owner	Algorithmic	Flags	Telemetry record, variance report, and a remediation item or incident routed to a named owner. Findings that an earlier verifier should have caught return as a verifier change.	Documented standard; runtime telemetry and incident readiness are already release-packet requirements

Industry-reported evidence

The case for verification is not that agents produce bad work. It is that plausible and correct are different states.

Every figure below is third-party and industry-reported. None of it is a WHPS measurement, none of it was independently verified by WHPS, and none of it is presented as a WHPS outcome, benchmark, or commitment.

Industry-reported · third-party

Agent benchmarks quote the length of task an agent can complete at a 50% success rate. Hold the same agents to 80% and the achievable task length drops sharply. Eighty percent is not a release threshold for a regulated healthcare transaction.

This is the argument for inline verification. Raising the accuracy an agent must clear inside the loop is what makes longer agentic work usable, because an 80% result cannot be inspected into a 100% one at review time.

Source: METR benchmarking of AI agent task length on software engineering work, as presented in 2026 industry conference material. Industry-reported third-party finding. Not a WHPS measurement.

Industry-reported · third-party

A reported three-to-five-times velocity gain from AI coding agents dissipates within roughly three months as security, maintainability, reliability, and complexity issues accumulate. Technical debt is generated at the same speed as the code.

This is the argument for the maintenance loop. Velocity that is not paired with verified debt control is borrowed, and the repayment lands inside the same quarter.

Source: Carnegie Mellon University research on AI coding agent productivity, as presented in 2026 industry conference material. Industry-reported third-party finding. Not a WHPS measurement.

Industry-reported · third-party

Organizations operating multi-layered verification report AI-derived production outages roughly 44% less frequent.

The variable these organizations report changing is verification depth, not model choice. That is the part of the system WHPS controls.

Source: outcomes reported by organizations operating multi-layered verification, as presented in 2026 industry conference material. Industry-reported third-party finding. Not a WHPS measurement and not independently verified by WHPS.

Industry-reported · third-party

One large banking organization's test of disciplined multi-layered verification reported a 92% reduction in issues.

One organization, one estate, one test. It sets an expectation worth testing against the WHPS estate; it is not a number WHPS carries.

Source: a large banking organization's reported internal test of multi-layered verification, as presented in 2026 industry conference material. Industry-reported third-party finding. Not a WHPS measurement and not independently verified by WHPS.

WHPS reports its own state separately and conservatively: thirteen control gates in force, a completed penetration test, 21 mapped traceability rows, and current evidence readiness at 0 export-ready, 1 review candidate, 11 pending captures, and 1 source-pending case.

AI-native organization model

Agile, agentic, and governed is the operating model, not a tool choice.

The governed delivery framework connects accepted intent, scoped agent execution, independent verification, evidence, and named human release authority.

Framework posture

Models and tools can change. The method stays enforced.

WHPS uses agentic capabilities to accelerate analysis, engineering, testing, documentation, operations, and evidence creation. The governance layer keeps authority bounded through risk tiers, scoped workspaces, model and tool gateways, architecture review, secure coding, AI evaluations, human approval, telemetry, rollback, and incident response.

01 Define / Classify

Outcome, use-case class, risk tier, data boundary, success measures, and named authority.

02 Decompose / Plan

Requirements, backlog, acceptance criteria, dependencies, definition of done, and test plan.

03 Architect / Secure

Architecture decisions, data flow, threat model, permissions, controls, and human oversight.

04 Build / Integrate

Bounded engineering, APIs, tests, documentation, provenance, and integration evidence.

05 Validate / Test

Functional, security, privacy, accessibility, integration, and AI-specific test evidence.

06 Package Evidence

Indexed requirements, changes, tests, controls, approvals, gaps, manifests, and rollback evidence.

07 Release / Operate

Human release decision, deployment record, smoke test, telemetry, support, rollback, and change loop.

WHPS AI SDLC Factory deep dive

Inside one controlled run, from a framed outcome to an authorized release.

The same run path is reusable across portals, contact center expansion, reconciliation, prior authorization, and modernization work. Each artifact below carries an output contract, a human checkpoint, a verifier, and the evidence it leaves behind.

Model agnostic Evidence first Human governed Agent ready

Not just faster delivery. Controlled acceleration with a reusable evidence trail.

A strategic idea becomes scoped work, architecture decisions, bounded agent runs, security checks, release evidence, and operating metrics. Agent-to-agent handoffs happen through controlled work orders, artifacts, gates, and handoff records.

7 Lifecycle phases

6 Agent handoff roles

1 Release packet contract

Controlled run path Explore the system from intent to operating signal

Decision window open

Use case Regulated healthcare application change

Owner, data class, risk tier, architecture path, and release authority are declared before agent work begins.

01 · Decision plane Shape the system while change is cheap.

Outcome → architecture → typed program design

02 · Tracer plane Prove one thin path end to end.

Interface → service → data → test

03 · Proof plane External checks push back on the run.

CI → independent review → evidence gate

Operating loop

Telemetry, incidents, support signals, and user feedback reopen the applicable decision with its prior evidence attached.

Choose an artifact to inspect its output contract, human checkpoint, verifier, and release evidence.

Context-cheap decision window A01 Frame the measurable outcome before implementation exists.

Accepted problem, outcome measure, non-goals, risk tier, owner, and acceptance criteria.

Human trajectory check: The product owner resolves ambiguity while changing direction is still inexpensive.
Verifier / back-pressure: A criteria-to-test map blocks progression when an outcome has no observable proof.
Inspectable evidence: Accepted PRD, named authority, measurable target, and decision record.

Why the loop stays human-led

People review the design while it is still cheap to change, inspect small working slices, understand the resulting logic, and retain release authority. Production signals return to the appropriate decision instead of feeding a lights-off code factory.

Human authority People keep decision rights.

Business, architecture, security, QA, compliance, and release owners approve the meaningful gates.

Agent composition Agents are scoped by role and handoff.

Product, architecture, build, security/test, evidence, and release roles exchange artifacts, not unmanaged authority.

Security by design Controls run before production movement.

SAST, dependency checks, secret scanning, vulnerability scanning, pen-test evidence, and AI evals sit inside the method.

Reusable platform The process extends to other teams.

The same delivery rails can support GroupLink, BrokerLink Portal, Contact Center AI, ReconLink, prior authorization, and modernization waves.

Demand Strategic idea enters as a governed request.

Value target, owner, data class, risk tier, users, success measure, and operational impact.

Policy orchestration Gate logic scopes the work before agents act.

Model gateway, tool gateway, identity boundary, workspace rules, architecture review, and approval depth.

WHPS AI SDLC Factory Define / Classify → Decompose / Plan → Architect / Secure → Build / Integrate → Validate / Test → Package Evidence → Release / Operate

Every handoff carries a clear output: decision, design, code, test, security result, evidence, or operating signal.

Agentic workspace Agents execute bounded work with traceability.

Run manifest, file scope, tool calls, tests, generated docs, security findings, and diff-based review.

Evidence and release Production movement requires proof.

Release packet, named approvals, rollback path, deployment ID, smoke test, telemetry, and revoke loop.

Run path · agent roles

Agent-agent communication is structured through role contracts and evidence handoffs.

R01 product Frames outcome and acceptance.

Input: strategy, constraints. Output: PRD, success criteria, risk prompt.

R02 architecture Sets the service and control design.

Input: PRD. Output: data flow, API path, threat model, review record.

R03 build Creates bounded implementation artifacts.

Input: work orders. Output: code, docs, tests, migration notes, run log.

R04 security + test Runs deterministic and AI-specific checks.

Input: build. Output: static analysis, dependency review, secret scan, vulnerability scan, AI evaluation, and pen-test evidence.

R05 evidence Assembles the reviewer packet.

Input: approvals and results. Output: AI BOM, gate record, rollback, release manifest.

R06 release authority Approves movement or sends it back.

Input: complete packet. Output: release decision, exception, remediation, or revoke action.

Security assurance

Security is a release condition, not a late-stage advisory step.

Gate Control focus Evidence produced

Intake

Risk tier, PHI/PII exposure, autonomy level, reversibility, and production impact.

Use-case record, data classification, owner, approval depth, and decision log.

Architecture

Architecture review board path, data flow, threat model, service boundaries, and human oversight.

Architecture note, threat model, control mapping, exception record, and review outcome.

Build

SAST, dependency review, secret scanning, secure coding, schema validation, and tool permissions.

Scan results, resolved findings, pull request review, test evidence, and workspace run manifest.

Validate

Vulnerability scanning, AI evaluations, prompt-injection checks, privacy tests, and pen-test evidence.

Evaluation report, vulnerability report, internal or external penetration-test findings, and remediation proof.

Release

CISO/security review path when required, QA acceptance, product approval, CAB/change record, and rollback readiness.

Named approvals, release packet, deployment ID, smoke test, rollback plan, and support handoff.

Operate

Runtime telemetry, drift, incident response, tool/model revocation, credential rotation, and re-evaluation triggers.

SLO dashboard, override rate, incident record, revoke log, corrective actions, and refreshed evidence packet.

Security AI SDLC review overlay

Thirteen security and compliance gates sit on top of AI-assisted delivery.

Agentic delivery can accelerate build, validation, and evidence collection, but movement stays governed by application classification, architecture and threat review, secure build controls, runtime testing, external validation, identity, privacy, monitoring, incident readiness, and final risk acceptance.

01-04 Intake and design assurance

Classify application risk, review data flows, identify threats, and validate secure design before build momentum.

05-08 Build and runtime security

Run static, dependency, infrastructure, dynamic, API, and penetration testing before production movement.

09-12 Access, data, and operations

Validate IAM, encryption, privacy, logging, monitoring, and incident readiness as operating controls.

13 Final risk acceptance

Document residual risk, exceptions, owners, severity, and the release or remediation decision.

01 Initiation

Intake and classification for PII/PHI, business criticality, owner, and approval depth.

Deliverable: intake form and risk classification.

02 Architecture review

Architecture, data flows, trust boundaries, integration paths, and external exposure points.

Deliverable: architecture risk assessment.

03 Threat modeling

Threat identification using STRIDE and MITRE ATT&CK mapping for the application surface.

Deliverable: threat model document.

04 Secure design validation

Control alignment against OWASP ASVS, NIST, HIPAA, and application-specific design standards.

Deliverable: design compliance checklist.

05 Code and build security

Static scans, dependency review, secret detection, and secure build evidence before release packaging.

Deliverable: SAST, SCA, and vulnerability reports.

06 Infrastructure security

Cloud and platform configuration, CIS benchmark posture, firewall rules, and hardening evidence.

Deliverable: configuration audit report.

07 Dynamic testing

Runtime scans, API fuzzing, authentication validation, and route behavior verification.

Deliverable: DAST and API test results.

08 Penetration testing

Independent validation of business logic, attack paths, escalation attempts, and advanced scenarios.

Deliverable: penetration test report.

09 Identity and access review

SSO, MFA, role-based access, token handling, credential boundaries, and access evidence.

Deliverable: IAM compliance report.

10 Data protection review

Encryption in transit and at rest, tokenization, masking, privacy controls, and data handling posture.

Deliverable: data protection checklist.

11 Logging and monitoring

Audit logs, SIEM readiness, alert use cases, detection signals, and operational telemetry.

Deliverable: logging validation report.

12 Incident response readiness

Application-specific playbooks, escalation path, containment plan, and recovery responsibilities.

Deliverable: incident response readiness checklist.

13 Final risk assessment

Open risks, severity, exceptions, accountable owners, remediation path, and release decision.

Deliverable: risk register.

Artifacts and documentation

Reviewers can follow the strategy claim into the proof record.

These artifacts demonstrate that the AI SDLC is documented, governed, security-aware, and tied to release evidence. The external reference links are supporting context; the controlled WHPS method record is this site.

AI SDLC Release packet checklist

Typed evidence required for low-code, pro-code, RAG, model, tool, agent, and migration changes.

Governance Tool and model registry

Approved, restricted, deprecated, and revoked tool/model posture with usage boundaries.

Governance Policy crosswalk

Controls, procedures, required evidence, review cadence, and accountable owners.

BrokerLink Portal Security architecture

Current trust boundaries, control layers, and evidence standing for the regulated portal path.

BrokerLink Portal Controls and evidence standing

Requirement, control, owner role, gap, and evidence-standing metadata without raw controlled artifacts.

Deep dive AI SDLC phase-by-phase walkthrough

The full technical reference for the governed lifecycle, verifiers, and evidence trail — self-contained on this site.

Doctrine Verification Control Plane

The governing-agentic-delivery doctrine: four verifier classes, zero-trust independence, and the three loops.

NIST AI RMF Govern, map, measure, manage.

AI risk management posture for trustworthy AI design, deployment, and monitoring.

NIST SSDF Secure software practices inside the SDLC.

Secure development controls integrated into each delivery path and release packet.

OWASP GenAI LLM and agentic threat awareness.

Prompt injection, insecure output handling, excessive agency, tool misuse, and agent governance risks.

Governance stages · WHPS AI SDLC Factory

A documented methodology for low-code, pro-code, and multi-agent delivery.

The framework does not depend on a single vendor model or named coding tool. It standardizes how WHPS accepts work, decomposes it, selects a model path, scopes agent authority, validates output, and produces evidence for release.

G01 intake Use case and product lane

ServiceLink, BrokerLink, GroupLink, Contact Center AI, migration wave, or platform foundation.

G02 classify Risk tier and data boundary

Autonomy, PHI/PII exposure, EDE impact, reversibility, customer impact, and approval depth.

G03 select Model and agent roster

Route through the WHPS model gateway using quality, security, latency, cost, context, and data policy.

G04 execute Low-code plus pro-code execution

Generate workflow shells, APIs, tests, documentation, diagrams, and integration stubs in scoped workspaces.

G05 prove CI, security, and AI eval gates

Run unit, integration, accessibility, SAST, dependency, grounding, privacy, prompt-injection, and parity tests.

G06 govern Release, monitor, revoke

Deploy only with approvals, AI BOM, rollback plan, telemetry, drift checks, and kill-switch path.

Release packet procedure

The documented release contract requires a typed evidence packet, not an informal tool transcript.

The delivery framework is intentionally tool-agnostic. WHPS controls the artifact, authority boundary, evidence, approval, rollback, and monitoring requirements. The model, automation runner, or development workspace can change without changing the release procedure.

Change / release type	Required packet contents	Blocked until	Runtime evidence
Low-code workflow or automation	Use-case ID, owner, data classes, workflow diagram, permission map, test scenarios, exception path, runbook.	Business owner, security, QA, and operations approve trigger, data scope, and rollback.	Execution log, user/action trace, error queue, control totals, incident path.
Pro-code app, API, or portal feature	Requirement trace, architecture note, API/schema contract, tests, SAST/dependency scan, accessibility check, deployment plan.	Code review, security scan, test suite, product acceptance, and rollback proof pass.	Deployment ID, smoke test, logs, SLO dashboard, support handoff.
RAG or knowledge-source change	Source owner, data classification, freshness date, citation policy, retrieval thresholds, redaction rules, golden Q/A set.	Grounding eval, prompt-injection test, stale-source check, PHI redaction, and citation sampling pass.	Retrieval trace, source IDs, citation score, unresolved knowledge gaps, QA review.
Model, prompt, tool, or agent-policy change	Registry ID, reason for change, baseline eval, substitution test, allowed actions, tool schemas, revocation plan, AI BOM update.	Risk tier, eval deltas, privacy/security review, human approval, and rollback plan are complete.	Model/tool gateway trace, drift monitor, override rate, cost/latency, incident trigger.
Mainframe migration wave automation	Wave ID, source artifacts, dependency graph, data map, batch calendar, replay plan, parity thresholds, decommission condition.	Source completeness, contract tests, data checksums, EDI/file replay, operations runbook, and rollback owner are approved.	Parallel-run result, variance report, cutover log, consumer-zero evidence, retired jobs/feeds/licenses.

Authority boundary	AI-assisted teams may do	Human authority retains	Evidence required
Drafting and analysis	Draft requirements, diagrams, test cases, code, runbooks, risk summaries, and comparison matrices.	Approve business intent, scope, priorities, risk acceptance, and final narrative.	Source links, assumptions, diff, review notes, and owner signoff.
Execution	Run allowed tasks in scoped workspaces with logged commands, generated artifacts, tests, and traceable outputs.	Authorize production access, privileged changes, destructive actions, customer-facing releases, and regulatory submissions.	Run manifest, permission scope, logs, scans, tests, and release packet.
Operations	Monitor telemetry, detect anomalies, open remediation tasks, draft incident summaries, and recommend rollback.	Declare incidents, approve rollback/cutover, notify regulators or partners, and close POA&M items.	Correlation IDs, incident record, decision log, corrective actions, and closure evidence.

Selected AI SDLC diagram set

Three views expose the operating flow, delivery architecture, and release evidence sequence.

The visible diagram set is intentionally curated. It gives leadership a clean progression while still giving architects and engineers enough detail to inspect policy, agents, tools, evals, evidence, release gates, and runtime revoke loops.

AI SDLC Operating Flow

Explains the canonical lifecycle from Define / Classify through Release / Operate, including the runtime change loop.

Best for orientation, operating model, and delivery governance.
Shows agent roster, controlled workspace, registry, eval gate, and runtime control.

View operating flow

Agentic Delivery Architecture

Shows the technical boundary between human demand, policy orchestration, agent workspace, CI/evals, evidence, and release operations.

Best for architecture, security, engineering, and platform review.
Names the gates engineers need to build and auditors need to inspect.

Inspect delivery architecture

Release Evidence Sequence

Tracks model, prompt, agent, or tool change from scoped task through policy, CI/evals, evidence, approval, remediation, and release.

Best for showing how the method prevents unmanaged AI change.
Retains an explicit fail path back to remediation and re-test.

Review release sequence

Supplemental archive Notation-heavy L0/L1/L2/L3 views are kept as engineering references, not presentation diagrams.

L0 context

Program strategy entering the agentic delivery architecture and producing evidence packets for operating review.

L1 system

Human decisions, policy controls, agent workspace, delivery systems, runtime operations, and incident loop.

L2 workflow

Request-to-release sequence with policy classification, sandbox execution, CI/evals, evidence, release, and remediation.

L3 gate logic

State-machine logic for risk tiering, design approval, build, eval, release review, deploy, monitor, change, and retirement.

Canonical lifecycle · operating flow

Move through seven governed phases with evidence at every handoff.

The canonical lifecycle becomes an implementable operating flow. Agent work is useful only when each run has scope, identity, a controlled workspace, approved tools, evals, human gates, runtime telemetry, and a revocation path.

Level 3 agentic delivery

Agents plan and execute bounded work instead of only pairing with a developer.
Human ownership remains attached to product, architecture, security, QA, and release decisions.

Registry triad

Model, prompt, tool, MCP, dataset, vector index, and agent definitions are versioned.
Statuses include approved, restricted, deprecated, and revoked.

Eval harness

Golden datasets, trace replay, adversarial prompts, tool misuse checks, and regression thresholds.
Failed gates block release and create remediation work.

Incident and revoke loop

Freeze agent, revoke credentials, isolate workspace, preserve evidence, and roll back release.
Update risk tier, policy, eval suite, and AI BOM before re-entry.

Deep architecture diagram

Agentic delivery architecture with agents, tools, evals, evidence, and runtime feedback.

This is the documented engineering model: human requests enter through portfolio intake, policy controls scope agent execution, tool access runs through a gateway, and production movement requires evidence and named approvals.

Governance stages

Eight operating governance stages from intake to retirement.

These governance stages overlay the seven-phase lifecycle with artifacts engineering teams can produce and reviewers can inspect.

Governance stage	WHPS message	Required evidence
Intake and risk tiering	Classify use case, data sensitivity, autonomy, external impact, and oversight model.	AI inventory record, owner, intended use, prohibited use, human oversight.
Architecture and threat modeling	Design model, data, RAG, tools, permissions, fail-safe paths, and abuse cases.	Threat model, data-flow diagram, agent/tool permission map, kill-switch design.
Data and model supply chain	Govern datasets, embeddings, model vendors, prompts, skills, and third-party components.	Dataset lineage, model card, vendor review, AI BOM, provenance checks.
Build and agentic delivery	Agents operate in scoped workspaces with tests, trace logs, and human review points.	Agent task log, code review, tests, tool-call traces, branch and change record.
Evaluation and red teaming	Test correctness, abuse, privacy leakage, prompt injection, tool misuse, drift, and business impact.	Eval suite, adversarial results, residual risk decision, mitigation plan.
Secure release gate	Ship only when model, prompt, agent, data, and application controls pass policy.	Release checklist, approval record, rollback plan, monitoring plan.
Runtime governance	Monitor outputs, tool actions, access, cost, latency, drift, incidents, and user feedback.	Telemetry, audit logs, drift report, access review, incident records.
Change and retirement	Reassess when models, prompts, tools, data, or context change. Decommission safely.	Change ticket, re-eval result, updated risk tier, decommission plan.

Run path · secure AI release

Every model, prompt, tool, and agent change passes through evidence checks.

Release is treated like a controlled software supply-chain event, not a slide approval or informal review.

R01 change Model, prompt, agent, or tool

Versioned request tied to owner, use case, environment, and risk tier.

R02 registry Artifact and AI BOM

Store model, prompt, dataset, tool, dependency, vendor, and configuration metadata.

R03 evaluate Regression and adversarial tests

Run factuality, grounding, injection, jailbreak, privacy, and business rule checks.

R04 secure Access and tool validation

Validate least privilege, schema constraints, secrets, dependencies, and unsafe output handling.

R05 approve Named human gate

Record architecture, security, product, compliance, QA, and business signoff.

R06 operate Monitor and revoke

Deploy with telemetry, alerts, rollback, kill switch, incident path, and re-evaluation trigger.

Control coverage

Engineer-readable AI governance controls.

These controls are intentionally concrete so delivery teams know what to implement, test, and produce as evidence.

Agent identity and tools

Distinct agent identities
Scoped authorization
Tool allowlists
Tool-call logging

Prompt and RAG security

Prompt injection tests
Source trust scoring
Context isolation
Secrets filtering

Evaluation harness

Regression suites
Adversarial prompts
Privacy leakage tests
Business KPI checks

Incident response

Kill switch
Prompt/model revocation
Credential rotation
Post-incident re-eval

Sources

Governance and delivery references.

Grounded in tool-agnostic AI risk management, secure software development, secure AI system guidance, LLM application security, AI BOM practices, and software delivery measures.

NIST AI RMF NIST Generative AI Profile NIST SSDF SP 800-218 OWASP LLM Top 10 OWASP agentic AI threats CycloneDX ML-BOM DORA software delivery metrics

Agentic delivery,bounded by proof.

From accepted intent to a human release decision.

Seven phases. Named human authority. Evidence at every exit.

Governance sets the rules. The control plane enforces them.

Four verifier classes. No agent verifies its own output. Control acts before and during, not only after.

Ordered by when control acts, from before generation to after release.

Preventive verifiers

Verifiers in this class

Inline verifiers

Verifiers in this class

Gate verifiers

Verifiers in this class

Continuous verifiers

Verifiers in this class

Two rules decide whether a check is verification or reassurance.

No agent verifies its own output.

Algorithmic and agentic verification run together.

Verifiers operate in every loop, and each loop fails differently without them.

Every verifier is named, owned, triggered, and dispositioned.

The case for verification is not that agents produce bad work. It is that plausible and correct are different states.

Agile, agentic, and governed is the operating model, not a tool choice.

Models and tools can change. The method stays enforced.

Inside one controlled run, from a framed outcome to an authorized release.

Not just faster delivery. Controlled acceleration with a reusable evidence trail.

Agent-agent communication is structured through role contracts and evidence handoffs.

Security is a release condition, not a late-stage advisory step.

Thirteen security and compliance gates sit on top of AI-assisted delivery.

Reviewers can follow the strategy claim into the proof record.

A documented methodology for low-code, pro-code, and multi-agent delivery.

Release is a decision backed by a packet, not a model assertion.

The documented release contract requires a typed evidence packet, not an informal tool transcript.

Three views expose the operating flow, delivery architecture, and release evidence sequence.

AI SDLC Operating Flow

Agentic Delivery Architecture

Release Evidence Sequence

Move through seven governed phases with evidence at every handoff.

Agentic delivery architecture with agents, tools, evals, evidence, and runtime feedback.

Eight operating governance stages from intake to retirement.

Every model, prompt, tool, and agent change passes through evidence checks.

Engineer-readable AI governance controls.

Governance and delivery references.

Agentic delivery,
bounded by proof.