01 · Delivery contract
Scope that can close
Acceptance criteria, interfaces, constraints, reviewers, and the boundary around what is not included.
- Outcome and non-goals
- Acceptance path
- Delivery risks
A Build Sprint takes one bounded outcome from an approved scope through implementation, testing, deployment preparation, documentation, and a clean ownership handoff.
What is the smallest production outcome that would materially change the operation—not merely demonstrate potential?
Build Sprints begin with a clear outcome, boundary, and acceptance path. The best scopes usually come from an Agent Teardown, Architecture Review, or an equivalent internal decision package.
The sprint is not a promise that every system fits an arbitrary calendar. Scope and commercial terms follow the actual integration, security, data, and operating constraints.
Acceptance criteria, interfaces, constraints, reviewers, and the boundary around what is not included.
The agreed capability built and exercised against representative and failure cases.
Documentation, runbooks, architecture decisions, and a walkthrough for the people keeping it.
Resolve acceptance, dependencies, access, risk, and non-goals before delivery starts.
Implement in useful increments and bring the right reviewers into consequential decisions.
Test the agreed outcome, document limitations, and transfer operating knowledge.
The sprint closes on agreed acceptance evidence and a handoff your team can use. A working demo without tests, operating notes, or clear ownership is not the finish line.
Share the system, workflow, or decision in front of you. We will confirm whether this lane fits, identify the information needed to scope it, and recommend a smaller or different start when appropriate.
No urgency timer. No obligation to continue into another engagement.