IMPLEMENTATION: build, verify and decide

IMPLEMENTATION combines bounded agent execution with review, tests, evidence and a human decision about whether the change is acceptable. The agent's output is a draft, not a delivery; generating code is only part of the phase.

This is the fourth Core phase of AI Architect Mastery's AI Driven Development Methodology. It takes an authorized TASK and checks the result against its scope and the underlying PRD.

Content baseline 3 October 2026 · Source: AAM Methodology v1.2, §§3, 4.4 · Owner: AI Architect Mastery

Why generation is not completion

A result can compile or look correct while violating a requirement or introducing architectural drift. Keep the same review discipline expected of any contributor. The methodology does not guarantee or certify production-ready software, regardless of who wrote the first draft.

Evidence ≠ an agent's completion claim. Evidence is observable information: the reviewed diff, actual test results, runtime observations and documented limitations. A confident summary or a proposed test command is not proof that the required behavior holds. Record the implementation state and environment actually checked.

What implementation review checks

• Does the actual change satisfy the TASK and stay within its scope?
• Do tests and other evidence demonstrate the required behavior?
• Does the result follow project conventions and architectural direction?
• Have security, performance, relevant edge cases and regressions been evaluated?
• Which claims remain unverified, and what risks or limitations must the human consider?

Inputs, output and responsibility

Input: an authorized TASK and its selected context. Output: a reviewed change, verification evidence and a human verdict. Owner: the agent executes within scope; the human owns evidence evaluation and acceptance.

Human Judgment and the Human Checkpoint

Human Judgment evaluates evidence against intent, constraints and acceptance criteria, including architectural direction and remaining risks. The human decides whether the observations are relevant and sufficient; passing tests do not transfer accountability to the agent.

A Human Checkpoint makes that judgment an explicit decision:

ACCEPT

The work meets the agreed scope and criteria with sufficient evidence.

REVISE

The result needs correction or additional evidence within a suitable approach.

REJECT

The submitted result must not progress as delivered.

REASSIGN

The work needs another responsibility holder, capability or execution environment.

RETURN

An earlier PRD, PLAN or TASK decision must be corrected before continuing.

Checkpoints are meaningful decision boundaries, not approval of every micro-action. Acceptance does not automatically authorize release or deployment; the project's separate delivery controls still apply.

Explore build, verification and decisions

• Bugs and state-aware evidence explains why plausible output is not proof.
• Scoped BUG correction restores established behavior without opportunistic expansion.
• Human implementation checkpoint makes the acceptance decision explicit.
• Controlled iteration returns to PRD, PLAN or TASK when the issue belongs earlier.

When to correct and when to return

A known failure within valid scope calls for correction and revalidation. If evidence exposes an earlier problem, the human chooses the return target: PRD for missing intent, constraints or acceptance criteria; PLAN for an inadequate approach; or TASK for insufficient context, scope or verification.

Pause affected execution, correct and review the earlier decision, then refresh dependent plans, assignments, context and verification. Resume under renewed human authorization and revalidate the resulting behavior and affected regressions before acceptance. An updated artifact alone does not validate downstream work, and return is not automatic routing.

Watch the IMPLEMENTATION methodology overview on YouTube (optional video; this text is the current reference).