What the AI is allowed to do
Manage prompts, policies, model settings, agent instructions, tool permissions, and human interaction as part of the system—not as informal setup.
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.
What the AI is allowed to know
Manage data, knowledge, retrieval, memory, permissions, sources, freshness, and boundaries so answers have an accountable basis.
What supports each important decision
Keep requirements, decisions, evaluations, security results, approvals, operating signals, incidents, and learning connected.
What changed between releases
Version code, models, tools, prompts, knowledge, controls, thresholds, and release configuration together.
For implementers and reviewers
Trace lifecycle guidance to the book and architecture controls.
The First Edition manuscript is mapped to EAINE’s framework and reference architecture (Framework baseline: EAINE v1.0 · Released 20 October 2026). Verification of the latest revision remains in progress.
Framework baseline: EAINE v1.0Officially Released 20 October 2026
Most readers can continue directly to the nine stages. Open this map when you need exact implementation or review references.
Open the lifecycle reference map
The First Edition manuscript is mapped to EAINE’s framework and reference architecture (Framework baseline: EAINE v1.0 · Released 20 October 2026). Verification of the latest revision remains in progress.
First Edition, 2026 · ISBN 978-93-345-4606-4 · Framework baseline: EAINE v1.0 · Released 20 October 2026. Review snapshot: 19 September 2026, covering the 7 September manuscript revision. Chapter-lineage and claim reconciliation remain open. The mappings below are navigation references, not verified alignment or independent review evidence.
Discovery
Book anchor: Chapters 11 and 12
Website anchor: /adoption
Control references: DOM-001, CMP-001, DEC-011
Requirements Engineering
Book anchor: Chapter 11
Website anchor: /framework
Control references: DOM-001, DOM-002, CMP-004, CMP-010, DEC-012
Architecture and Design
Book anchor: Chapter 13
Website anchor: /framework
Control references: DOM-002, DOM-010, CMP-002, CMP-011, DEC-013
Development
Book anchor: Chapter 14
Website anchor: /framework
Control references: CMP-005, CMP-006, CMP-007, CMP-008, IF-004, IF-005, IF-006
Quality Engineering
Book anchor: Chapter 15
Website anchor: /evidence
Control references: DOM-006, CMP-009, REC-010, REC-011
Security Validation
Book anchor: Chapters 16 and 24
Website anchor: /evidence
Control references: DOM-008, CMP-010, CMP-011, DEC-016
Deployment and Release
Book anchor: Chapter 16
Website anchor: /evidence
Control references: DOM-002, DOM-007, CMP-003, CMP-014, DEC-017
Operations
Book anchor: Chapter 16
Website anchor: /adoption
Control references: DOM-009, CMP-012, CMP-013, DEC-018
Continuous Improvement
Book anchor: Chapters 17 and 22
Website anchor: /adoption
Control references: 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?
- What your team should leave with
- Use-case brief, applicability/risk record, affected-party analysis, value hypothesis
- Decision before moving forward
- A valuable, permissible, and accountable opportunity is selected.
- 02
Requirements Engineering
What must the system do, refuse, reveal, and escalate?
- What your team should leave with
- Behavioral requirements, prohibited behaviour, thresholds, human-oversight design
- Decision before moving forward
- Outcomes, boundaries, evidence, and accountability are testable.
- 03
Architecture and Design
Where will context, controls, identity, tools, models, and evidence live?
- What your team should leave with
- Architecture decision records, data flows, threat model, control map
- Decision before moving forward
- The design can enforce the required behaviour and controls.
- 04
Development
How will prompts, code, models, tools, context, and policies change safely?
- What your team should leave with
- Versioned implementation, prompt/context records, provenance, tests
- Decision before moving forward
- The release is reproducible, reviewable, and ready for evaluation.
- 05
Quality Engineering
What evidence supports quality, safety, and business claims?
- What your team should leave with
- Evaluation plan, representative sets, thresholds, regression and human-factor results
- Decision before moving forward
- Approved thresholds are met and limitations are known.
- 06
Security Validation
How can data, models, prompts, tools, agents, identities, and supply chains fail?
- What your team should leave with
- Threat model, adversarial results, access review, residual-risk record
- Decision before moving forward
- Material security risks are treated or explicitly accepted.
- 07
Deployment and Release
Is the system evidence-ready, operable, reversible, and approved?
- What your team should leave with
- Release-readiness record, approvals, rollback, communications, runbook
- Decision before moving forward
- An accountable authority accepts release and residual risk.
- 08
Operations
Is real behaviour, impact, security, reliability, cost, and use observable?
- What your team should leave with
- Telemetry, audit trail, dashboards, alerts, incident and feedback records
- Decision before moving forward
- The service can be operated, challenged, and recovered responsibly.
- 09
Continuous Improvement
How does evidence improve the system and the enterprise practice?
- What your team should leave with
- Learning review, controlled backlog, updated tests, patterns, standards, and knowledge
- Decision before moving forward
- 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.
What has and has not been establishedThe lifecycle is internally tested; independent and real-world validation remain open
Internal checks cover the nine stages, change routing, responsible-AI feedback, and tests for expected failure. Practitioner use, independent review, and field evidence are still required before a final release or a claim that the lifecycle is effective in practice.
Release decisionValue + quality + safety + security + operability
Residual uncertainty is recorded and accepted by an accountable authority. It is not hidden behind model performance averages.