Interfaces deserve explicit acceptance tests

An interface is where one package’s output becomes another package’s prerequisite. It may be physical, informational, operational or organisational. The producer can finish its local work while the recipient still cannot proceed. This is why an interface deserves an acceptance test that reflects the recipient’s need. A generic completion statement can hide an incompatible configuration, missing evidence or unresolved authority. Delivery control becomes stronger when the interface is defined before the parties report progress against it.

The fictional assembly task needs accepted equipment and accepted receiving works. The equipment interface includes configuration and availability at the agreed boundary. The receiving interface includes a location fit for the specified assembly method. These are illustrative control categories, not technical specifications for an actual installation. The integrated manager should make the correspondence explicit: which equipment version is being received, which works version supports it, and what evidence permits the assembly team to rely on the match.

Interface readiness has a producer and a recipient. The producer supplies the work and evidence. The recipient checks whether these meet the release condition. A third party may hold the authority to certify a particular requirement. Combining these roles casually can create self-acceptance where independent approval is actually required, or unnecessary waiting where the recipient has authority to accept. The record should follow the real delegation and applicable requirements. A schedule cannot create acceptance authority simply by assigning someone an approval task.

A rejected interface should produce actionable information. State the unmet condition, the evidence supporting rejection, the effect on downstream work and the owner of correction. A red status without a reason cannot guide recovery. A rejection should also be scoped: the recipient may be able to release unaffected work while holding a specific configuration or area. Partial acceptance requires an explicit boundary and residual obligation. It should not be used to conceal a material safety or statutory condition whose failure prevents the proposed work.

The readiness event can be represented as a task when it consumes time and governs release. The interface-gate study inserts such a decision after assembly. Its estimated gate duration is 3.00 weeks and its project duration is 22.00 weeks. These fictional values reveal the consequence of including an omitted release activity. They do not estimate a real review queue. If the actual gate is a categorical permission with uncertain outcome, the network must be labelled conditional rather than treating elapsed duration as assurance of approval.

Interface evidence should be specific enough to survive a handover between teams. A signed checklist can be useful, but its version, scope and underlying records matter. An inspection against an obsolete configuration may be accurately performed yet irrelevant to the current successor. A readiness statement for part of a location may be incorrectly relied on for the whole area. The package record should link the acceptance decision to the exact configuration, place, scope and exceptions that were reviewed.

Evidence completeness should be tested before booking the accepting party’s time. Review capacity is often consumed by incomplete submissions, which generate repeated cycles without advancing release. The control response is to define a completeness check separate from substantive acceptance. Completeness means the required material is present; it does not mean the material is correct. Keeping these stages distinct prevents a submission receipt from being reported as approval, while making avoidable administrative waiting visible.

The recipient should state how exceptions affect use. An outstanding document may be tolerable for limited assembly but unacceptable for energisation. A physical discrepancy may allow inspection while preventing integrated testing. The exception record should name permitted activities, prohibited activities, resolution owner and expiry or review condition. Without this scope, qualified release can gradually become unconditional through repeated reporting. The schedule should link each successor to the correct release level rather than treating all forms of acceptance as equivalent.

Changes can invalidate previously accepted evidence. A revised equipment configuration may require the receiving interface to be rechecked. A changed test method may require a different operating procedure. The change record should identify accepted records whose basis is affected, not only tasks whose durations change. Reopening acceptance is sometimes necessary even when physical work remains complete. The resulting schedule effect is a consequence of the changed obligation, not proof that the earlier acceptance was improper under the information then available.

An interface register should be accessible to both sides. If only the producing team can see the evidence status, the recipient may maintain a conflicting readiness forecast. If only the recipient can edit criteria, the producer may face moving requirements without a change record. Shared visibility does not require unrestricted editing. It requires controlled criteria, clear submissions, recorded decisions and a way to raise a challenge. The important design principle is that both parties can inspect the current obligation and its history.

A fictional recipient signs a receiving certificate that permits inspection but holds assembly pending a compatibility check. An executive summary later reports receiving accepted without the qualification. The planner uses that summary to release assembly. The original certificate was clear; the loss occurred when its scope travelled through reporting. This case shows why evidence control includes the meaning retained in summaries, not only the quality of the underlying document.

The manager restores the qualified state and informs the successor. Inspection progress remains valid, while assembly release remains open. The forecast identifies the compatibility obligation and its owner. The correction should preserve the earlier communication so the team can understand what reliance occurred. It should not silently replace the summary and claim that the recipient had always been correctly informed. If downstream work began, its actual scope and exposure need a separate disposition.

The reporting rule now requires material conditions beside accepted status. A concise phrase can be sufficient if it states permitted scope and the remaining hold. The linked certificate supplies detail. This is proportionate because the condition governs a successor. The lesson is that qualified acceptance can support useful action, but its qualification is part of the evidence claim. Removing it changes the claim and can invalidate the release even when every quoted document is genuine.

In a fictional handover rehearsal, the supplier reports equipment ready while the receiving team reports location ready. The assembly manager discovers that each used a different released equipment configuration. The integrated schedule had joined two valid local milestones that did not describe the same interface. The remedy is not to average the completion percentages. It is to identify the governing configuration, assess the mismatch and record the correction or authorised change. This case illustrates an integration failure without claiming any observed occurrence.

The manager first preserves the evidence behind both readiness statements. This allows the team to determine whether the mismatch arose from an uncommunicated change, an incorrect interpretation or an incomplete release. The distinction matters for recovery and responsibility. Erasing the earlier records would make the immediate chart cleaner but destroy the basis for learning. A controlled correction records the new interface version and the reason that previous readiness no longer releases assembly.

Next, the manager tests whether any bounded work can proceed. A partial assembly activity may be independent of the affected interface. If so, define its scope and acceptance conditions explicitly. If the proposed overlap creates irreversible rework or violates a noncompensable requirement, hold it. The decision should compare executable alternatives, including correction before assembly, qualified partial work and a changed design. An attractive date is not sufficient authority to accept technical or legal exposure.

The schedule update should then represent the chosen remedy. A correction task, a renewed inspection or a readiness decision may be needed. Its duration basis should reflect the actual scope and resource arrangement. The app can test a simplified network once those assumptions are defined, but the qualitative interface record remains necessary to explain what the new task means. Without it, the correction bar can become another ambiguous completion event that repeats the original problem.

Finally, the team should improve the release process at the point of failure. If the configuration changed without recipient acknowledgment, add a controlled notification and compatibility review. If the criteria were ambiguous, revise the interface definition. If the submission was incomplete, strengthen the completeness check. The response should target the evidenced cause rather than adding indiscriminate approvals to every package. Interface control is valuable when it prevents reliance on mismatched evidence; it becomes burdensome when it multiplies signatures without clarifying the release obligation.