You build the integration. AIKUS works alongside your delivery team as a specialist assurance subcontractor, challenging the evidence before it reaches your client. Your team retains the client relationship and delivery responsibility; your team and client make the release decision.
The check applies when an integration delivery includes a defined, testable API product. AIKUS assesses that API boundary, not the entire platform implementation.
The engagement at a glance
Scope: One API product, up to 10 endpoints, one supplied test environment and one agreed test-data set. One retest round and a written Delivery Evidence Report are included.
Timing: The report is provided within 15 working days after working access is confirmed.
What we examine
The questions depend on the API. We may challenge contract and behavioural correctness, input boundaries, data transformation, dependency failure, error handling, retries, partial failure, state consistency and recovery. We also examine whether existing test evidence supports the claims made about the integration.
An illustrative finding
An order API returns a timeout after committing an order. The caller retries, receives a successful response, and the existing suite passes. A Delivery Check could test whether that sequence creates duplicate fulfilment work, how the consuming system represents the error, and whether later reconciliation reveals the second order. This is an example of a question we can test, not a claim about a completed client engagement.
What you receive
The Delivery Evidence Report records the agreed boundary and existing evidence, tests and conditions exercised, observed behaviour, evidence for material findings, coverage gaps, untested or unresolved areas, and the outcome of the included retest. It identifies residual risks observed in scope. It is evidence for the partner and client, not a release certificate.
What your team provides
Before the clock starts, provide an API specification or equivalent documentation, a working test environment, authorised credentials, usable test data, relevant existing tests, and access to dependencies or suitable stubs. We also need the end client and sector to confirm fit and authority to test.
How the work runs
1. Confirm fit and access. We agree the API boundary, environment, data and material questions. The 15-working-day window starts when working access is confirmed.
2. Examine and challenge. We review relevant evidence and exercise the agreed behaviours, including material failure and recovery paths.
3. Report the evidence. We describe observations and limitations for the partner and client to assess.
4. Retest once. After the team addresses agreed findings, we perform the included retest and record its result.
Boundaries and next step
Additional APIs, endpoints, environments, data sets, retests or materially changed implementations require separate scope. This check does not include penetration testing, load or performance testing, or unapproved production access. If the environment becomes materially unavailable, the delivery clock pauses; after five working days without restored access, the work may need re-scoping.
Tell us what you are delivering, the end client and sector, when you need the evidence, and the state of the test environment. Email AIKUS to discuss fit and commercial terms.