Make integration acceptance a reproducible test

Define the deliverable before testing it

Write an acceptance schedule around the artifact being purchased: a daily file, an API response, a research report or an executable package. Identify its schema version, supported identifiers, units, publication calendar and intended recipient. A spreadsheet opening without an error says nothing about whether a percentage was interpreted as a decimal or whether a discontinued instrument was silently dropped.

For each requirement, record the input fixture, expected output, tolerance, evidence location and responsible reviewer. Keep connectivity checks distinct from interpretation checks. A delivery team can confirm that credentials work while the research owner remains unable to reconcile the output. Neither team should sign the other's conclusion merely because a purchase order needs to close this week.

• Name the artifact and version in every test result.
• Assign separate owners for transport and interpretation.

Distinguish every relevant clock

Require separate fields for the observation time, calculation time, publication time and local receipt time whenever those distinctions affect use. RFC 3339 specifies an Internet timestamp format with a UTC offset; it does not define which business event a vendor's timestamp represents. The delivery specification must supply that meaning and identify the calendar governing expected publication.

Build fixtures around a holiday, an early close and a clock change relevant to the workflow. Include a perfectly formed timestamp attached to an old observation. That case should demonstrate the buyer's freshness rule rather than merely its date parser. Record whether missing observations are withheld, marked unavailable or carried forward, and ensure the receiving screen preserves that distinction.

• Test valid formatting and business freshness independently.

Work through a fictional acceptance result

In this hypothetical procurement, a fictional provider offers a daily model file under an invented acceptance schedule containing 24 tests. Eight tests are critical because a failure could misidentify an instrument, expose unauthorized data or publish stale output as current. The first run passes 22 tests, including seven critical tests. Its overall pass rate is 22 divided by 24, or 91.67% rounded.

One failed critical test concerns a correction that overwrites the original publication without preserving its identity. The other failure is a noncritical documentation link. The buyer withholds acceptance despite the high aggregate percentage. After a repair, it reruns the failed cases and the complete regression pack against the same build, retaining both runs rather than replacing the unfavorable first receipt.

• Do not let an average score override a declared critical gate.

Prove safe retry and correction behavior

RFC 9110 distinguishes idempotent operations from operations that cannot safely be retried without additional knowledge. Apply that distinction to the actual integration: a timed-out read and a timed-out job submission require different handling. Ask the supplier to demonstrate the documented retry mechanism instead of assuming that repeating every request leaves the same business state or the same invoice.

Replay the same delivery twice, interrupt a transfer, and deliver a correction after the original has been consumed. Check the receiving record count and the relationship between original and revised records. A useful receipt captures request identifiers and revision identifiers together. Duplicate prevention should not discard a legitimate correction merely because both records refer to the same instrument and observation date.

• Include duplicate, interrupted and corrected deliveries in the fixture pack.

Exercise failure boundaries deliberately

Test an expired credential, a malformed row, an unexpected field and an unavailable upstream input. Agree whether each condition causes rejection, quarantine or a clearly marked partial result. Partial delivery is especially important when the buyer expects a complete universe: receiving ninety plausible rows can conceal ten missing instruments unless completeness is measured against the declared population.

Keep destructive tests inside an authorized isolated environment with synthetic information. The procurement team should approve the test window and the supplier should know which traffic is deliberate. Retain a clear stopping condition so an acceptance exercise cannot become an uncontrolled load test. A supplier's refusal to permit a particular test becomes an evidence gap, not an automatically inferred defect.

• Agree safe test limits and explicit handling of partial output.

Connect evidence to the payment milestone

Attach the agreed test pack to the commercial acceptance process and identify who can approve exceptions. Specify the proposed remediation period and the evidence needed for a retest, subject to the negotiated agreement. Do not assume a failed test creates a refund, cancellation right or payment suspension. Those consequences require review of the actual terms and applicable law.

An exception should name the affected use, temporary restriction, owner and expiry date. For example, a missing historical revision export might permit a sandbox evaluation while blocking operational use. Avoid a general waiver saying that the buyer accepts all outstanding issues. That wording makes it difficult to determine which defect was consciously tolerated and which was never examined at all.

• Tie each exception to a specific permitted use and expiry.

Preserve an acceptance boundary

The final record should identify the delivered version, fixture version, execution date, observed results and signatories. Store it somewhere the buyer controls and can retrieve without the supplier's portal. Preserve a machine-readable result where practical alongside a short decision summary. Future reviewers need to distinguish a test that passed from a requirement that was removed after failing.

Acceptance establishes only the tested delivery behavior within the recorded scope. It does not certify investment returns, all future releases or every downstream use. Define which later events reopen acceptance, such as a schema change or a new distribution route. This turns the test pack into a reusable procurement control without allowing an old signature to authorize materially different service.

• Reopen acceptance when the deliverable or authorized route materially changes.

Source notes

1. RFC Editor: RFC 3339, Date and Time on the Internet
2. RFC Editor: RFC 9110, HTTP Semantics, section 9.2.2