8. Completion and delivery

8.1 Establish the remaining claim

Completion means that the agreed work and its required examination are fulfilled within the authorized scope. Reliance is using a contribution as a basis for a decision or action. A completion claim needs evidence for the agreed result; it does not settle every later use of that result.

Before adding a closure activity, identify the required claim that remains unsupported. If existing evidence already establishes the agreed result, another general review is optional improvement rather than a hidden completion gate.

Three questions organize the examination. Does the result cover the commitments? Do the required relationships work together? Do the actual checks support the proposed use?

Follow both directions where the scope warrants it. A commitment may lack an output. Implemented behavior may exceed or contradict the accepted scope. Current source documents should reflect the decisions that govern those differences.

This comparison belongs with the work when its meaning changes. A separate documentation closeout is useful only when a real uncovered relationship remains. Do not require it after every undertaking by default.

8.2 Examine the product in use

Begin with the activity the product should support. Define the candidate, starting state, user action or scenario, relevant environment and expected observations.

Exercise the actual connecting path. An interface can display a success message while failing to preserve data. An exported artifact can be valid in isolation while unreadable by its intended consumer.

Use representative difficult cases, not only the easiest valid example. Consider invalid input, interruption, cancellation, state restoration and the limits of the environment where these affect the claim.

An exercise you conduct can provide evidence. It does not replace practitioner assessment where the question concerns professional usability or reliance. State what your exercise establishes and what it leaves to another examination.

8.3 Repair without losing valid work

A late finding should identify the affected requirement, candidate and consequence. Diagnose the cause and preserve unrelated valid work.

The repair may invalidate only part of the earlier evidence. Recheck that part and its affected consumers. Do not repeat a whole programme automatically, and do not retain a result whose governing conditions changed.

A change to a protected criterion requires its own substantive reason and authority. Keep the distinction between correcting implementation and changing what the product promises.

If the authorized result cannot be achieved, present the actual position. A narrower proposal, a deferral or termination can be responsible outcomes when the person understands their consequences. They are not completion of the original obligation unless that obligation changes.

8.4 Transfer an identified result

Give the recipient a result they can identify and use. Explain what you delivered, what it is for, its limitations and who carries the continuing responsibilities.

For software, a source merge is not necessarily the artifact a user installs. For a technical document, an editable source is not necessarily the issued edition. Check the actual delivery form where that distinction matters.

Preserve operational instructions, known limitations and recovery information with the result. Reference existing evidence rather than copying the entire development history into a handover packet.

The final account should make the outcome understandable: fulfilled commitments, authorized changes, remaining responsibilities and the relevant acceptance or release acts. It need not narrate every intermediate action.