Customer Delivery

Overview

Customer Delivery closes the gap between “the work exists” and “the customer received the promised result”. It keeps the original requirement, the selected knowledge, the implementation delta, test evidence, merged revision, deployed revision, live result, and customer disposition in one auditable chain.

Acceptance chain

1. Capture the source. Store the customer's exact statement and split it into stable requirement IDs. Corrections supersede earlier text without deleting the history.
2. Pin applicable knowledge. Record the immutable role, skill, blueprint, constraint, policy, and success-criterion revisions before implementation starts.
3. Build and verify. Connect the requirement to the implementation delta, red/green evidence, and the resulting merged revision. A test-only or documentation-only result is enabling evidence, not visitor-facing delivery.
4. Prove delivery. Record the deployed revision and fresh live evidence. For visual work, include the required locale, viewport, theme, and operator visual disposition.
5. Close honestly. Mark the customer disposition as accepted, rejected, superseded, or pending. A missing edge in the chain is not a pass.

Coverage receipt

The machine-readable receipt maps Requirement → knowledge revisions → implementation → red/green evidence → merge → deploy → live evidence → disposition. It is acyclic and mutation-tested: removing any required edge must make the gate fail.

What cannot substitute for delivery

• A green unit test without a deployed and live result.
• A knowledge, documentation, ledger, or CI change without a visitor-facing outcome.
• A staging screenshot when production is still behind the accepted revision.
• An agent's assumption that a pending customer review is implied acceptance.