Phase 6 — Testing & Audit

Part 8 of The AI-Centric Software Development Playbook

The Independent Eye

Phase 5 built the system. Code was generated from specifications, tested against contracts, scored against the Core Principles, and verified for correctness — all within the implementation feedback loop. By the end of Phase 5, every module passes its tests, meets its coverage targets, and conforms to its specification.

Phase 6 asks a different question: is that enough?

Implementation-time testing and verification are necessary but not sufficient. They are conducted by the same team, using the same tool sets, within the same assumptions that produced the code. Phase 6 steps outside that frame. It applies independent scrutiny — different test strategies, different perspectives, different AI configurations — to determine whether the system genuinely meets the standards it was designed to satisfy.

This is the phase where the Core Principles become pass/fail gates. During implementation, principle scores were continuous signals guiding development. During testing and audit, they become thresholds. A principle that scores below its target is not a signal to monitor — it is a finding that must be resolved or explicitly accepted as a known risk before deployment proceeds.

The distinction matters. Implementation is optimistic by nature — the team is building, progressing, solving problems. Audit is skeptical by design — it looks for what was missed, what was assumed, what broke quietly. Both orientations are necessary. Combining them in a single phase conflates building with verifying. Separating them ensures that verification has its own space, its own rigor, and its own authority to stop deployment if the system is not ready.

What Testing & Audit Accomplishes

Phase 6 produces five primary artifacts.

Comprehensive Test Results — The results of testing that goes beyond what was conducted during implementation: end-to-end integration tests, system-level test scenarios, edge case exploration, chaos testing, and adversarial test cases generated by AI working from the specification rather than the implementation.

Security Audit Report — The results of independent security review: penetration testing, vulnerability scanning at the system level, compliance verification against the applicable standards, and review of the security architecture’s implementation.

Performance Validation Report — Empirical validation of the system against the benchmarks established in Phase 2 and refined through subsequent phases. Not simulation — actual load testing, latency measurement, throughput testing, and resource consumption profiling under realistic conditions.

Documentation Audit — An assessment of whether the documentation is complete, current, and queryable. The test: can AI answer substantive questions about the system using only the documentation? If AI cannot reason about the system from its documentation, neither can a new team member, an incident responder, or a future maintainer.

Final Principle Scorecard — The definitive pre-deployment scoring of the system against all six Core Principles. Each principle receives a final score with evidence. Principles that meet their targets are cleared for deployment. Principles that fall short are documented with remediation plans or risk acceptances.

The SDD Cycle in Phase 6

Phase 6 applies the SDD cycle to the audit process itself. The testing and audit effort is specified, planned, detailed into specific audit areas, tasked with concrete verification activities, and implemented through execution.

Step 1: Specify — Define the Audit Scope

An interview prompt from the Audit tool set scopes the testing and audit effort:

• What testing was already conducted during Phase 5? What gaps remain?
• What are the compliance requirements that must be verified before deployment?
• What are the highest-risk components — the places where a failure would have the most severe consequences?
• What performance benchmarks must be empirically validated?
• What documentation must be reviewed for completeness and currency?
• Are there areas where the team has low confidence in the implementation, even though tests pass?

The output is an audit specification that defines scope, priorities, and acceptance criteria. The specification prevents audit from becoming either an exhaustive but unfocused review or a cursory check that misses critical areas.

Step 2: Plan — Organize the Audit

The audit specification is broken into sections:

• Extended testing — System-level tests, edge cases, adversarial scenarios, chaos testing
• Security audit — Penetration testing, vulnerability assessment, compliance verification, security architecture review
• Performance validation — Load testing, latency profiling, throughput measurement, resource consumption analysis
• Formal verification review — Engineer review of AI-generated verification models from Phase 5
• Specification conformance audit — End-to-end verification that the complete system matches the architecture, API contracts, and design decisions
• Documentation audit — Completeness, currency, and queryability assessment
• Scoring gate evaluation — Final principle scoring and deployment readiness determination

Step 3: Detail — Define Audit Criteria

Each section is detailed into specific criteria and test plans.

For example, the Security Audit section might be detailed into:

• Penetration testing scope: All external-facing API endpoints, authentication flows, authorization boundaries, file upload handlers, and third-party integration points. Test for: injection (SQL, NoSQL, command, LDAP), authentication bypass, authorization escalation, session management flaws, CSRF, SSRF, and data exposure.
• Vulnerability assessment: Full dependency tree scan against current CVE databases. Container image scan. Infrastructure-as-code scan for misconfigurations. Secrets detection across the codebase and configuration.
• Compliance verification: For each applicable compliance requirement (mapped in Phase 2, constrained in Phase 3, implemented in Phase 5), verify the control exists, functions correctly, and produces audit evidence. Produce a compliance matrix showing requirement, control, evidence, and status.
• Security architecture review: Independent review of authentication flows, authorization policies, encryption implementation, and audit logging against the security architecture from Phase 4. Conducted by a different AI configuration than the one that reviewed during implementation.

Step 4: Task — Assign Specific Audit Activities

The audit criteria are broken into concrete tasks:

• Execute penetration testing against all external API endpoints using the OWASP Testing Guide methodology. Document all findings with severity, reproducibility, and recommended remediation.
• Run system-level integration tests for all cross-module workflows identified in the architecture. Include happy path, error conditions, timeout scenarios, and partial failure modes.
• Execute load tests at 1x, 5x, and 10x projected peak load. Measure and record: p50/p95/p99 latency, throughput, error rate, CPU utilization, memory consumption, and connection pool behavior. Compare against Phase 2 benchmarks.
• For each AI-generated formal verification model from Phase 5, the engineer reviews: Does the model accurately represent the component? Are the safety and liveness properties complete? Are boundary conditions captured? Does the model verify what matters, not just what is easy to verify?
• Generate adversarial test cases: AI reads the specification and generates inputs designed to break the implementation — boundary values, type confusion, race conditions, resource exhaustion, malformed data. Execute and document results.
• Conduct the documentation queryability test: give AI access only to the project documentation (no codebase access) and ask it twenty substantive questions about the system’s architecture, security model, deployment process, and operational procedures. Score the accuracy and completeness of its answers.

Step 5: Implement — Execute the Audit

The Audit tool sets execute the tasks. This is where independent scrutiny is applied.

Extended testing execution — AI generates system-level test scenarios from the architecture and specifications, working independently from the implementation-time testing. The goal is to find what implementation-time tests missed. Edge cases that were not in the original specification. Interaction patterns between modules that were tested individually but not together. Failure modes that only manifest at the system level.

Security audit execution — Penetration testing, vulnerability scanning, and compliance verification are conducted. AI assists by automating portions of the testing, analyzing scan results, and mapping findings to the threat model and compliance requirements. Human security expertise validates findings and assesses severity.

Performance validation execution — Load tests, latency profiles, and resource consumption measurements are run against the actual system under realistic conditions. Results are compared against the benchmarks from Phase 2. Deviations are documented with analysis of root cause and remediation options.

Formal verification review — The engineer conducts the review of AI-generated verification models. This is the most explicitly human-judgment-dependent activity in the entire framework. AI built the proofs. The engineer decides whether the proofs prove the right things. This review cannot be automated or delegated — it is where the engineer’s understanding of the domain, the business requirements, and the consequences of failure is most critical.

Correctness Verification at Scale

Phase 5 ran correctness verification at the module level during implementation. Phase 6 elevates it to the system level.

End-to-End Specification Conformance

The complete system is verified against the complete specification. This is more than testing individual modules against their contracts — it is verifying that the assembled system behaves according to the architecture, the design decisions, and the business requirements.

End-to-end specification conformance checks:

• Do the API endpoints behave as documented in the OpenAPI specifications when called in realistic sequences, not just individual calls?
• Does data flow through the system as described in the data architecture? Do transformations, validations, and persistence operations match the specification at every step?
• Do cross-cutting concerns (authentication, authorization, logging, error handling) behave consistently across all modules, as specified in the shared architectural standards?
• Do the monitoring and observability hooks emit the metrics and logs specified in the architecture?

When conformance checks find deviations, each deviation is classified: is the specification wrong (update it), is the implementation wrong (fix it), or is it an acceptable deviation (document it)? Every deviation must be resolved — ignored deviations accumulate into a system that no one can reason about with confidence.

AI-vs-AI Audit at System Level

During implementation, AI-vs-AI review operated at the module level. In Phase 6, an independent AI configuration reviews the entire codebase against the original specifications. This system-level audit looks for:

• Specification drift — Places where the implementation diverged from the specification without documentation. This happens even in disciplined processes. Module A’s implementation of an API might subtly differ from the contract in ways that Module B’s contract tests did not catch because they tested different aspects.
• Undocumented behavior — Code paths, error handling, or side effects that exist in the implementation but are not reflected in any specification. These represent either missing specification (update it) or unintended behavior (remove it).
• Cross-module inconsistencies — Patterns that are correct within each module but inconsistent across modules: different error response formats, different logging conventions, different authorization check patterns.
• Architectural compliance — Does the implementation respect the architectural boundaries? Are there direct database calls that bypass the data access layer? Are there inter-module communications that bypass the defined API contracts?

The system-level AI-vs-AI audit produces a findings report that the team triages. Not every finding requires action — some are acceptable trade-offs, some are false positives — but every finding must be reviewed and dispositioned.

Security Audit

The security audit in Phase 6 is independent from the continuous security scanning in Phase 5. Implementation-time scanning catches known vulnerability patterns and dependency issues. The Phase 6 audit tests the system’s security posture as a whole.

Penetration Testing

Penetration testing simulates real attack scenarios against the deployed system. AI can assist by generating attack payloads, automating reconnaissance, and analyzing results, but the testing methodology should follow established frameworks (OWASP Testing Guide, PTES) to ensure coverage.

Critical penetration testing areas:

• Authentication: Can authentication be bypassed? Are session management mechanisms secure? Do password policies and rate limiting function correctly?
• Authorization: Can a user access resources or operations beyond their assigned role? Do authorization checks apply consistently across all endpoints?
• Input handling: Are all inputs validated and sanitized? Do injection attacks succeed against any endpoint?
• Data exposure: Does the system leak sensitive information through error messages, API responses, headers, or logs?

Compliance Verification

For each applicable compliance standard, the audit produces a compliance matrix: requirement, implementing control, evidence of effectiveness, and status (pass, fail, or partial). This matrix is the artifact that compliance auditors will review, and it should be producible from the system’s documentation and test results without manual investigation.

AI assembles the compliance matrix from the compliance requirements mapped in Phase 2, the controls implemented in Phase 5, and the audit evidence gathered in Phase 6. The practitioner reviews for accuracy and completeness.

Performance Validation

Phase 2 defined benchmarks. Phase 3 simulated whether the design could meet them. Phase 5 ran performance checks during implementation. Phase 6 validates empirically.

What Gets Validated

• Latency under load: p50, p95, and p99 response times at projected peak load. Measured for every critical user workflow, not just individual endpoints.
• Throughput ceiling: The maximum sustained request rate before error rates exceed acceptable thresholds.
• Resource consumption: CPU, memory, network, and storage utilization at steady state and under peak load. Compared against the infrastructure cost model from Phase 2.
• Scaling behavior: How does the system behave as load increases beyond projections? Does it degrade gracefully or cliff?
• Cold start and recovery: How quickly does the system reach operational readiness after deployment? How quickly does it recover from a component failure?

When Benchmarks Are Not Met

Benchmark failures in Phase 6 are not surprises if the implementation scoring was working correctly — they should be marginal misses that require tuning, not fundamental failures that require redesign. If a benchmark failure is severe, it signals a problem in earlier phases: the simulation in Phase 3 was inaccurate, the architecture in Phase 4 was structurally incapable, or the implementation in Phase 5 introduced a performance regression that the scoring system did not catch.

The response depends on severity. Minor misses may be addressed through optimization without architectural change. Significant misses require root cause analysis tracing back through the phases. The SDD cycle supports this: the specification, design, and architecture artifacts provide the traceability needed to identify where the performance problem originates.

Documentation Audit

The documentation audit applies a specific, testable standard: can AI answer substantive questions about the system using only the documentation?

The Queryability Test

The test is straightforward. Give an AI access to the project’s documentation — architecture documents, module specifications, API specifications, security architecture, operational runbooks, deployment guides — but not the codebase. Ask it substantive questions:

• How does the authentication flow work for a new user?
• What happens when the payment processing service is unavailable?
• How is data encrypted at rest and in transit?
• What monitoring alerts exist for the transaction processing module?
• How do I deploy a new version of the user service?
• What compliance controls address the HIPAA data access logging requirement?

Score the AI’s answers for accuracy and completeness against the actual system. Where the AI cannot answer or answers incorrectly, the documentation has a gap.

Why This Standard Matters

If AI cannot reason about the system from the documentation, the documentation is insufficient for its three audiences: humans now, humans later, and AI tool sets in subsequent work. Documentation that passes the queryability test is documentation that will support incident response, onboarding, compliance audits, and future development. Documentation that fails is documentation that creates dependency on tribal knowledge.

Documentation Freeze

After the documentation audit, the documentation is “frozen” for deployment — meaning it represents the state of the system as deployed. Post-deployment changes to the system trigger documentation updates through the maintenance process defined in the documentation strategy (Phase 4). The freeze establishes a known-good baseline of documentation that is verifiably accurate at the time of deployment.

The Scoring Gates

Phase 6 culminates in the scoring gates — the pass/fail evaluation that determines deployment readiness.

Gate Structure

Each Core Principle has a scoring gate with defined thresholds:

• Security: All penetration testing findings at severity “high” or above must be remediated. All compliance requirements must have passing controls. All dependency vulnerabilities at severity “critical” or “high” must be resolved or have documented mitigation plans with timelines.
• Maintainability: Test coverage must meet or exceed the target established in Phase 4. Documentation must pass the queryability test. Code quality metrics must be within defined thresholds.
• Economics: Actual infrastructure costs at projected scale must be within the cost model tolerance (e.g., within 20% of forecast). Actual development effort must be tracked and the cost model updated for future reference.
• Operations: All monitoring hooks must be functional and emitting data. Health check endpoints must respond correctly. Deployment must be repeatable and automated. Rollback procedures must be tested.
• Scoring & Metrics: All automated metrics must be collecting data. The Principle Scorecard must be current and complete. Benchmark results must be recorded and compared against targets.
• Correctness Verification: End-to-end specification conformance must pass. Formal verification models for designated components must be reviewed and confirmed. The AI-vs-AI audit findings must be triaged and resolved.

Gate Outcomes

For each gate, three outcomes are possible:

Pass — The principle meets its threshold. No action required. Deployment proceeds for this dimension.

Conditional pass — The principle falls short of its threshold, but the shortfall is understood, bounded, and acceptable given the project’s context. A remediation plan with a timeline is documented. The risk is explicitly accepted by the responsible stakeholder. Deployment proceeds with the documented conditions.

Fail — The principle falls significantly short of its threshold, and the shortfall represents unacceptable risk. Deployment does not proceed until the issue is resolved. The SDD cycle iterates — typically cycling back to Phase 5 for implementation fixes, but potentially back to Phase 4 or earlier if the root cause is architectural.

The scoring gates are not a rubber stamp. They exist to prevent the common pattern of deploying systems that “mostly work” with a list of known issues that never get addressed. Every conditional pass has a remediation timeline. Every fail blocks deployment until resolved.

Core Principles in Phase 6

Phase 6 is where the Core Principles reach their most rigorous application. Every principle is evaluated independently with evidence, and the evaluation determines whether deployment proceeds.

Security

The security audit provides the evidence: penetration testing results, vulnerability scan results, compliance matrix, and security architecture review findings. Security’s gate is typically the strictest — high-severity findings block deployment without exception.

Maintainability

Test coverage, documentation queryability, and code quality metrics provide the evidence. Maintainability’s gate ensures that the system is not just functional but sustainable. A system that works but cannot be maintained, documented, or reasoned about is a future liability.

Economics

Cost model validation provides the evidence. Economics’ gate ensures that the system operates within its budget and that the cost model is accurate for future forecasting. This is also where actual development effort is reconciled against estimates, providing data for future project planning.

Operations

Monitoring functionality, deployment automation, and rollback testing provide the evidence. Operations’ gate ensures that the system can be operated safely in production — that the team can deploy, monitor, diagnose, and recover.

Scoring & Metrics

The completeness and currency of automated metrics provide the evidence. Scoring’s gate ensures that the measurement infrastructure is operational — that the team will have visibility into the system’s health from day one of production operation.

Correctness Verification

Specification conformance, formal verification review, and AI-vs-AI audit provide the evidence. Correctness’ gate ensures that the system does what its specification says it does — not approximately, not mostly, but verifiably.

Tool Sets for Phase 6

Extended Testing Tool Set

Purpose: Generate and execute test scenarios beyond implementation-time testing.

Building blocks: - The architecture, module specifications, and API contracts as input resources - An action prompt that generates system-level test scenarios from the architecture — cross-module workflows, failure cascades, edge cases at system boundaries - An action prompt that generates adversarial test cases — boundary values, malformed inputs, race conditions, resource exhaustion - MCP connections to the test runner, the deployed system, and monitoring dashboards - An evaluation prompt that assesses test coverage gaps compared to the architecture

Security Audit Tool Set

Purpose: Conduct independent security review and compliance verification.

Building blocks: - The threat model, security architecture, and compliance requirements as input resources - A skill that frames the AI as a security auditor, independent from the implementation team’s perspective - An instruction set for penetration testing methodology (based on OWASP or equivalent) - An action prompt that assembles the compliance matrix from requirements, controls, and audit evidence - MCP connections to vulnerability scanners, dependency audit tools, and container image scanners - An evaluation prompt that assesses finding severity and prioritizes remediation

Performance Validation Tool Set

Purpose: Empirically validate the system against performance benchmarks.

Building blocks: - The benchmarks from Phase 2 and the cost model as input resources - An instruction set for load testing methodology: scenarios, load profiles, measurement points, acceptance criteria - MCP connections to load testing tools, monitoring systems, and resource utilization dashboards - An action prompt that generates the performance validation report, comparing results against benchmarks with root cause analysis for any misses

Documentation Audit Tool Set

Purpose: Assess documentation completeness, currency, and queryability.

Building blocks: - The documentation strategy from Phase 4 as the standard - An evaluation prompt that assesses documentation completeness against the architecture — every module, every API, every security control, every operational procedure - An instruction set for the queryability test: twenty substantive questions across architecture, security, operations, and deployment, scored for accuracy and completeness - An action prompt that generates the documentation audit report with specific gaps identified

Scoring Gate Tool Set

Purpose: Evaluate deployment readiness against all six Core Principles.

Building blocks: - All Phase 6 audit results as input resources - The Principle Scorecard history (Phase 3 baseline through Phase 5 updates) as context - An evaluation prompt that scores each principle against its defined threshold, producing the final Principle Scorecard with evidence, gate status (pass/conditional/fail), and remediation requirements - An action prompt that generates the deployment readiness report — the definitive artifact that authorizes or blocks deployment - A correctness verification instruction set that cross-references all findings, ensuring no audit area was skipped and no finding was left undispositioned

Common Pitfalls

Treating Audit as a Formality

If the team approaches Phase 6 as a rubber stamp — running the audits but expecting to deploy regardless of findings — the phase loses its value. The scoring gates must have real authority. A “fail” must actually block deployment. If it doesn’t, the entire scoring framework becomes decorative.

Auditing With the Same Assumptions

Phase 6’s value comes from independent scrutiny. If the security audit uses the same prompts and the same AI configuration as the implementation-time security scanning, it will find the same things and miss the same things. Use different AI configurations, different testing methodologies, and where possible, different perspectives (a team member who was not deeply involved in the module’s implementation).

Skipping the Formal Verification Review

AI-generated formal verification models from Phase 5 require engineer review. This review cannot be automated. The engineer must confirm that the model represents the right system, verifies the right properties, and covers the right boundary conditions. Skipping this review means relying on proofs that may be technically correct but practically irrelevant — proving that a function preserves an invariant that does not matter while missing the invariant that does.

Documentation Audit as Checkbox

The documentation queryability test is specific and measurable. “Documentation reviewed — looks good” is not an audit finding. “AI correctly answered 16 of 20 substantive questions; 4 gaps identified in operational runbooks and disaster recovery procedures” is an audit finding. The queryability test produces actionable results. Use it as designed.

Conditional Passes Without Timelines

A conditional pass without a remediation timeline is an indefinitely deferred problem. Every conditional pass must include: what the shortfall is, what will be done to address it, when it will be addressed, and who is responsible. Without these, conditional passes accumulate into a pile of known issues that degrade the system’s quality over time.

Validation Checkpoint

Phase 6’s validation checkpoint is the deployment readiness determination. It is the most consequential checkpoint in the entire process.

• All scoring gates evaluated: Every Core Principle has a gate status — pass, conditional pass, or fail.
• No unresolved fails: Any fail status must be resolved (by fixing the issue and re-auditing) before deployment proceeds.
• Conditional passes documented: Every conditional pass has a remediation plan with a timeline, responsible owner, and acceptance by the appropriate stakeholder.
• All findings dispositioned: Every audit finding — security, performance, conformance, documentation — has been triaged, addressed, or explicitly accepted.
• Final Principle Scorecard complete: The scorecard includes final scores with evidence for all six principles, comparison to the Phase 3 baseline, and trend analysis across all phases.
• Deployment readiness report produced: The definitive artifact that authorizes deployment, summarizing all audit results, gate statuses, conditional passes, and any known risks being carried into production.

When all gates pass (or conditionally pass with documented plans), deployment proceeds to Phase 7.

What Comes Next

Phase 6 applies independent scrutiny to the complete system and produces the deployment readiness determination. The scoring gates either clear the system for deployment or identify what must be fixed first.

Phase 7 is the final phase. The next part covers Deployment & Evolution — where the system goes live, monitoring activates, the operational practices designed throughout the entire process begin running, and the framework shifts from building to sustaining. This is where runbooks become AI orchestration scripts, where incident response leverages the toolkit, where technical debt is tracked and managed, and where the SDD cycle continues driving the system’s evolution.

This is a living document. The tool sets, audit patterns, scoring gate criteria, and examples will be expanded and refined as the series develops. Every part of this framework is open to iteration.

Navigate Forward/Back

Previous: Part 7: Implementation

Next in the series: Part 9: Deployment & Evolution

Complete Series:

Part 0: The Manifesto — Small Teams, Big AI, New Paradigm

Part 1: Core Principles, establishes the six core principles that act as the compass by which we navigate each aspect of our project — Security, Maintainability, Economics, Operations, Scoring & Metrics, and Correctness Verification. These principles define what you care about.

Part 2: Building Your Toolkit, define the means to act on our Core Principles and define the methodology that puts them into practice. This includes Tool Sets made up of Building Blocks (i.e. Prompts, Agent Instructions, Skill Documents, MCP Servers, Custom AIs, etc) for each Phase of the Specification Driven Development (SDD) process that should have each phase producing structured artifacts which act as input for the following phases.

Part 3: Information Gathering, began our exploration into the first of seven phases of building software with AI. Phase 1 of any project is the gathering of all available information on the subject. Using our Tool Set for this Phase results in a structured Informational Report.

 Part 4: Analysis & Stack Selection, we explored the second phase of any software project and applied our Core Principles to help understand how we should build out our toolkit for this Phase 2. This phase results in four artifacts, a Business Analysis, a Cost Model, a Stack Decision with Rationale, and an Initial Threat Model. Additionally, Phase 2 establishes a benchmark framework.

Part 5: Design & Technical Analysis, we had the AI systematically apply our four artifacts and our benchmark framework from Phase 2 (see Part 4: Analysis & Stack Selection) resulting in a Design Direction Document, a Principle Scorecard, and a Technical Feasibility Assessment. Additionally, Phase 3 identifies two critical forward-looking concerns, monitoring and observability hooks, and compliance design constraints.

Part 6: Architecture & Modular Design, we applied our artifacts from Phase 3 (see Part 5: Design & Technical Analysis) and committed to the blueprints that we will use to build our project. This resulted in seven critical artifacts (collections) including Module Specification Documents, API Specifications, Security Architecture, Data Architecture, Documentation Strategy, Governance Model, and an Updated Principle Scorecard.

Part 7: Implementation, we took our specifications and other architectural documents from Phase 4 (see Part 6: Architecture & Modular Design) and coded, or had our agents code, with proper boundaries and controls meant to maximize the abilities of AI-centric Software Development utilizing our Specification Driven Development cycle. This resulted in working module implementations, test suites, monitoring and observability implementations, infrastructure-as-code, continuous scoring data, and an updated principle scorecard.

Part 8: Testing & Auditing, we audited our project with a skeptical view and an attackers mindset. In Phase 6 we are applied independent scrutiny to try to game our system and measure using different test strategies from different perspectives using a different AI Tool set. The results of this phase was a Comprehensive Test Results, a Security Audit Report, a Performance Validation Report, a Documentation Audit, and a Final Principle Scorecard. Failure to meet expectations set earlier meant cycling back through phases 5-7 with the aim of fixing bugs and mitigating security findings before deployment or signing off on acceptable risks to be corrected in a future release.

Part 9: Deployment & Evolution, in which we deploy our project with utilizing the configuration we prepared earlier and we move into the evolutionary cycle. Phase 7 results in a deployed, observable system, operational runbooks as AI orchestration scripts, continuous compliance, technical debt tracking and management, evolution artifacts and continuously updated principle scorecard. The SDD cycle does not stop at deployment — it continues driving the system’s evolution, with the same discipline, utilizing the same principles and expanding the tool sets. Thanks to our earlier work it is far easier to iterate through over and over as features are added, performance is tuned, security threats evolve, compliance requirements shift, infrastructure is upgraded, and technical debt is addressed.