The Six Stages of Eastgate's ACDC

The five layers describe what ACDC is built from. The six stages below show when each layer applies, as one change moves from a business request to production feedback. Each stage should leave a usable output for the next person or agent, and the exact setup depends on your systems and approval requirements.

1. Stage 01

   Plan: Agree on the Business Outcome

   +

   Start with the problem and who it affects. Describe what a successful change would achieve, then identify the limits on that change.

   An agent can help turn the discussion into a brief. The business owner checks that it reflects the intended outcome. Keep unresolved questions visible rather than allowing a polished draft to hide them. The business owner confirms the outcome before design starts.

   Output: Intent brief

2. Stage 02

   Design: Make Requirements Testable

   +

   Turn the approved outcome into behavior the team can check. Resolve access rules and important failure cases while changing direction is still inexpensive.

   The design review should also settle what is outside scope. For the order portal, reading an order's status does not automatically include permission to edit it. The team agrees on testable behavior before implementation begins.

   Output: Specification and design decisions

3. Stage 03

   Build: Work From an Approved Plan

   +

   Give implementation a defined scope and a clear order of work. If the approach changes, record why so the reviewer can assess the difference.

   Parallel agents are useful when tasks are sufficiently independent. Set responsibilities and agree on shared interfaces first. Increase concurrency only while the team can still review the resulting work properly. Engineers review the changes against the agreed scope.

   Output: Implementation plan and code diff

4. Stage 04

   Test: Check Behavior Throughout Implementation

   +

   Run relevant checks as the feature develops. A passing unit test does not establish that the complete user journey works, so include integration checks where systems meet.

   For the order portal, test permitted access and rejected access. Also check what the user sees when the order service is unavailable. These cases should come from the requirement, not only from the implementation. Reviewers check the evidence against the requirement.

   Output: Test results and unresolved findings

5. Stage 05

   Deploy: Release With Evidence and a Recovery Plan

   +

   The release decision needs more than an agent's completion message. Review the test results and unresolved findings, then confirm that the release meets the project's approval rules.

   Agree on the recovery path before deployment. Make sure the responsible person can see what changed and knows how to respond if the service behaves unexpectedly. The release owner approves the deployment.

   Output: Release decision and recovery plan

6. Stage 06

   Maintain: Use Production Findings to Guide the Next Change

   +

   Let service evidence inform the backlog. An agent may help summarize an incident or prepare a proposed fix, subject to the access it has been granted.

   Keep authority explicit. Permission to inspect an alert does not also grant permission to alter production. Review the proposed change through the project's normal controls and add a regression check where appropriate. The team reviews the proposed correction like any other change.

   Output: Incident record and follow-up change