AI Development Lifecycle

A discipline, not a tool adoption. Built into SMART-TA from the start.

SMART‑TA was built using a disciplined AI development framework applied across its full lifecycle. By using this framework, it evolved the development lifecycle beyond AI tool adoption and into a fundamentally reimagined approach to building software.

AIDLC Phase Model SMART-TA
1
Contextualize Architecture, domain model, and agent configuration in structured context files.
2
Specify AI-assisted requirements decomposition with human validation at every step.
3
Design & Model API contracts, data models, and code-ready specification artifacts in complex domains.
4
Build AI agents generate code from formal specifications. Engineers direct and review.
5
Validate Validation gates at every phase transition — not only after code exists.
6
Deploy & Learn Delivery feedback loops back into context files, compounding across every future session.

The core insight

Adding AI to an existing SDLC creates new bottlenecks. The whole system must evolve.

Most organizations bolt AI onto a traditional development lifecycle and wonder why the gains are incremental. AI doesn't just accelerate existing tasks, it changes the economics, throughput, and quality profile of software delivery so significantly that the surrounding process, team structure, and governance must evolve with it.

From the beginning, SMART-TA was designed on the AIDLC principle that this transformation spans six dimensions simultaneously. Technology alone is not the answer.

Process

From sequential to parallel AI-augmented execution with structured agent orchestration replaces human-paced sequential delivery.

Context

Structured knowledge Machine-readable context files that encode expert domain knowledge compound in value across every session.

Metrics

Outcomes, not output Speed of innovation and quality; not ticket velocity, AI usage rates, or lines of code generated.

Team

Roles evolve Context management, AI review, and specification authorship become first-class engineering disciplines.

Culture

Business intent The priority resource is the domain expert, architect, and BSA who can articulate business intent precisely enough for AI to act on it, not the developer who codes it manually.

Governance

Part of the foundation Cost management, security, and compliance guardrails are embedded in the lifecycle from the start.

SMART-TA implementation

A formal specification pipeline. Every module, every jurisdiction.

SMART-TA implements the AIDLC through a two-stage specification pipeline that translates regulatory and business requirements into formal, machine-readable JDSL* specifications before a single line of code is written.

The pipeline operates across two separate AI context environments, one for requirements analysis and one for specification authoring, with a defined handoff protocol at the boundary. Every artifact produced is human-reviewed before it proceeds to the next stage.

*The JDSL (Jaivlin Design Specification Language) is the code-ready specification format that SMART-TA uses. Its seven layers (data, decision, process, scenario, UI intent, integration, and constraint) map directly to UI and microservice implementation structure, giving AI code generation agents complete, validated context without requiring engineers to re-specify domain intent the specification already captures.
Stage 1 Requirements Analysis
Business Requirements Document (BRD)
Functional Requirements Specification (FRS)
Logical Data Model (LDM)
Test Case Pack (TCP)
Cross-artifact consistency review
Scoped handoff brief to Stage 2
Stage 2 JDSL Specification
Design Spec + companion Data Definition Language (DDL)
Multi-point domain expert review gate
Definition of Ready checklist
JDSL YAML (code-ready specification)
Engineering handoff package
Stage 3 Engineering
Engineer-guided AI build from JDSL YAML
Test suites generated from scenario layer
Deployment and monitoring
Operational Procedures, User Guides, Compliance Guides, Training Materials
Feedback loop to context files

From framework to practice

Six domain-specific patterns created for SMART-TA development lifecycle

SMART-TA's specification pipeline derived each new pattern across multiple specification rounds before incorporation into the enhanced development lifecycle.

01
Code-Ready Specification

A DSL-based artifact between design and code that encodes the full domain model, business logic, and compliance rules in a machine-readable form AI code generation can consume directly, eliminating re-specification of intent the specification already captures.

02
Tiered Specification Architecture

Core / Extension / Product Module tiers prevent scope contamination and enable independent versioning across jurisdictions and product lines. Jurisdiction-specific content never appears in the Core tier; product-specific content never appears in the Extension tier.

03
Multi-Project Context Architecture

Separate AI context environments for requirements analysis and specification authoring, with a formal handoff protocol at the boundary that carries exactly the cross-project context the next stage needs.

04
Domain Expert Review Gates

Structured pre-build validation with per-item PASS/FAIL, ACCEPT/AMEND/OPEN ITEM disposition, and specific patch recommendations per finding. The review checklist is distilled from real review history, not written speculatively before any reviews are conducted.

See the review gate process →
05
Validation as Cross-Phase Discipline

Validation gates at every phase transition, not only after code exists. A defect caught at the specification layer costs a text edit. The same defect caught after code generation costs a code change, a re-review, and a re-test.

06
Specification as Collective Knowledge

In complex, regulated domains, no single practitioner holds the full scope of requirements. The specification assembles distributed expertise at a breadth that exceeds any individual's knowledge ceiling, enabling team scaling without sacrificing domain accuracy.

Governance & validation

Every artifact reviewed before it proceeds.

SMART-TA's specification pipeline operates at AIDLC autonomy Level B: AI generates every artifact, and every artifact passes through explicit human review before proceeding. This is not a safeguard applied after the fact, it is the structural design of the pipeline.

Five validation mechanisms fire before the JDSL YAML reaches engineering, each calibrated to the phase where the defect class it catches is cheapest to fix. Findings from domain expert review are encoded as standing rules in context files so expert judgment compounds across sessions, not re-applied from scratch.

T
Terminology scrub

Continuous and embedded in every authoring session. Banned terms checked across all specification files before any version bump.

CA
Cross-artifact consistency

Mandatory pass in the Requirements project: every LDM reference resolved, every enum matched, every TCP linkage verified before the pack proceeds.

SME
Multi-point domain expert review

A standing checklist distilled from real review history, applied at every Design Spec and JDSL YAML review. Findings drive targeted patches.

DoR
Definition of Ready

A 10-point gate at the Design Spec to JDSL YAML boundary. A specification does not enter YAML production until it passes all ten points.

VAL
Domain expert review

Specialist domain validation at Design Spec stage and post-JDSL YAML production. Structured output: ACCEPT / AMEND / OPEN ITEM per finding, with a patch recommendation for each AMEND.

Review gate process

Three gates. Domain SME review at every stage boundary.

SMART-TA's specification pipeline defines a review gate at each stage transition. Every artifact, from initial requirements through design specification to JDSL YAML, is reviewed by a domain SME before it advances. The gate structure ensures defects are caught at the stage where they are cheapest to fix.

Each gate produces a structured review record capturing the artifact, categorized SME feedback, and an explicit disposition. Feedback is organized as critical issues that block progression, general improvements, and open questions requiring a decision. Findings are integrated into revised artifacts and tracked to closure. Recurring findings are distilled into standing review rules in the relevant context files. Expert judgment compounds across specifications rather than being re-applied from scratch.

Implementation: each gate type uses a structured issue template capturing artifact details, reviewer feedback, and disposition. Issues remain open until all critical findings are resolved and the disposition is confirmed.
Gate 0 Requirements Artifact Review
Covers BRD, FRS, LDM, and TCP artifacts
Domain SME review for regulatory correctness and completeness
Freeform feedback: critical issues, general improvements, open questions
Disposition: approved, approved with comments, or revise and resubmit
Must close before Design Spec authoring begins
Gate 1 Design Spec — Definition of Ready
Structured completeness checklist for the Design Spec and DDL pair
Covers document control, data model correspondence, open item resolution, and terminology
All checklist items must pass before JDSL specification authoring begins
Mechanical completeness check confirms readiness, not correctness
Gate 2 Specification Quality Review
Multi-point domain SME checklist covering all specification layers
Per-item PASS/FAIL with ACCEPT/AMEND/OPEN ITEM disposition
Patch recommendation required for every finding requiring amendment
Checklist distilled from accumulated domain SME review findings
Must pass before engineering handoff