Behavior
Prompts, policies, model settings, agent instructions, tool contracts, and human interaction.
AI Software Development Lifecycle
Manage AI from the first idea to daily operation.
AI systems depend on more than code. EAINE helps teams manage models, prompts, context, agents, policies, tests, releases, and live performance through one lifecycle.
Cross-cutting assuranceControl remains continuous from intent to operation
- Governance
- Evidence
- Human authority
- Phase 01Frame the work
Value, requirements, and architecture
Evidence gate - Phase 02Engineer + prove
Build, evaluate, and secure
Evidence gate - Phase 03Release + learn
Release, operate, and improve
Evidence gate
Runtime signals + outcomesControlled learning loopUpdates requirements, tests, controls, and architecture
↺What changes
AI changes more than code.
Traditional software controls still matter. AI also introduces changing behaviour, context, autonomy, evidence, and learning that teams must manage.
Context
Data, knowledge, retrieval, memory, permissions, provenance, freshness, and boundaries.
Evidence
Requirements, decisions, evaluations, security results, approvals, telemetry, incidents, and learning.
Change
Code, models, tools, prompts, knowledge, controls, thresholds, and release configuration.
Book and control trace
Each lifecycle stage maps directly to RA control IDs.
This page stays aligned to both the book and the canonical RA contract.
Discovery
Book anchor: Chapters 11 and 12
Website anchor: /adoption
Control proof: DOM-001, CMP-001, DEC-011
Requirements Engineering
Book anchor: Chapter 11
Website anchor: /framework
Control proof: DOM-001, DOM-002, CMP-004, CMP-010, DEC-012
Architecture and Design
Book anchor: Chapter 13
Website anchor: /framework
Control proof: DOM-002, DOM-010, CMP-002, CMP-011, DEC-013
Development
Book anchor: Chapter 14
Website anchor: /framework
Control proof: CMP-005, CMP-006, CMP-007, CMP-008, IF-004, IF-005, IF-006
Quality Engineering
Book anchor: Chapter 15
Website anchor: /evidence
Control proof: DOM-006, CMP-009, REC-010, REC-011
Security Validation
Book anchor: Chapters 16 and 24
Website anchor: /evidence
Control proof: DOM-008, CMP-010, CMP-011, DEC-016
Deployment and Release
Book anchor: Chapter 16
Website anchor: /evidence
Control proof: DOM-002, DOM-007, CMP-003, CMP-014, DEC-017
Operations
Book anchor: Chapter 16
Website anchor: /adoption
Control proof: DOM-009, CMP-012, CMP-013, DEC-018
Continuous Improvement
Book anchor: Chapters 17 and 22
Website anchor: /adoption
Control proof: DOM-010, CMP-015, DEC-019
Lifecycle evidence
Every stage updates the same operating record.
The nine stages are not a separate story from the book. Each stage strengthens one or more of the five traces and leaves evidence for the next accountable decision.
Intent
What outcome matters, for whom, and within which constraints?
Authority
Who may decide, approve, act, stop, and answer?
Behaviour
Which exact configuration produced the outcome?
Evidence
What justified release, and what remains unknown?
Learning
What did production change for the next decision?
Nine stages
Every stage ends with a clear, evidence-based decision.
- 01
Discovery
Should this problem use AI, and under what constraints?
- Minimum artefacts
- Use-case brief, applicability/risk record, affected-party analysis, value hypothesis
- Evidence gate
- A valuable, permissible, and accountable opportunity is selected.
- 02
Requirements Engineering
What must the system do, refuse, reveal, and escalate?
- Minimum artefacts
- Behavioral requirements, prohibited behaviour, thresholds, human-oversight design
- Evidence gate
- Outcomes, boundaries, evidence, and accountability are testable.
- 03
Architecture and Design
Where will context, controls, identity, tools, models, and evidence live?
- Minimum artefacts
- Architecture decision records, data flows, threat model, control map
- Evidence gate
- The design can enforce the required behaviour and controls.
- 04
Development
How will prompts, code, models, tools, context, and policies change safely?
- Minimum artefacts
- Versioned implementation, prompt/context records, provenance, tests
- Evidence gate
- The candidate is reproducible, reviewable, and ready for evaluation.
- 05
Quality Engineering
What evidence supports quality, safety, and business claims?
- Minimum artefacts
- Evaluation plan, representative sets, thresholds, regression and human-factor results
- Evidence gate
- Approved thresholds are met and limitations are known.
- 06
Security Validation
How can data, models, prompts, tools, agents, identities, and supply chains fail?
- Minimum artefacts
- Threat model, adversarial results, access review, residual-risk record
- Evidence gate
- Material security risks are treated or explicitly accepted.
- 07
Deployment and Release
Is the system evidence-ready, operable, reversible, and approved?
- Minimum artefacts
- Release-readiness record, approvals, rollback, communications, runbook
- Evidence gate
- An accountable authority accepts release and residual risk.
- 08
Operations
Is real behaviour, impact, security, reliability, cost, and use observable?
- Minimum artefacts
- Telemetry, audit trail, dashboards, alerts, incident and feedback records
- Evidence gate
- The service can be operated, challenged, and recovered responsibly.
- 09
Continuous Improvement
How does evidence improve the system and the enterprise practice?
- Minimum artefacts
- Learning review, controlled backlog, updated tests, patterns, standards, and knowledge
- Evidence gate
- Signals produce governed improvement rather than uncontrolled drift.
AI SDLC is not a waterfall. Stages may iterate, but accountability, evidence, and release authority must never disappear inside iteration.
Release principle
A working demo is not enough for release.
Before release, teams need realistic testing, security checks, named approval, operational ownership, monitoring, and a recovery plan.
Candidate statusInternally complete; external validation remains open
The nine-stage control model, change routing, responsible-AI loops, and negative tests pass internally. Practitioner use, independent review, and field evidence are still required before v1.0 or an effectiveness claim.
Release decisionValue + quality + safety + security + operability
Residual uncertainty is recorded and accepted by an accountable authority. It is not hidden behind model performance averages.