Delivery Check · API assurance for integration partners

What happens when your API delivery meets a failure?

Dependency failures. Repeated requests. Partial completion. AIKUS challenges agreed API behaviour in a test environment and records what the evidence supports and what remains unresolved.

You keep the client relationship and release decision.

Discuss a Delivery Check Inspect our lab findings

AIKUS lab engagement

One reservation request. Three calls.

A tool in our lab reserved stock three times for the same request. We added idempotency handling and repeated the same challenge.

Seeded flaw disclosed: the first version was deliberately built without idempotency to show that the challenge detects duplicate reservations. This was an AIKUS-built MCP tool with mock inventory and a model-free harness.

Observed findings · 9 October 2026
Challenge	Seeded version	Fixed version
Same key and inputs, three calls	Failed: 3 reservations, 12 units reserved	Held: 1 reservation, 4 units reserved; identical responses
Same key, quantity changed from 4 to 7	Failed: another reservation; 11 units reserved in total	Held: clear conflict error; original reservation and stock unchanged
Valid request with a new key	Held: separate reservation; 8 units reserved in total	Held: separate reservation; 8 units reserved in total

Each case started with a fresh server process and 100 units of stock. Stock availability did not prevent any requested reservation.

ClaimIdentical retries create one reservation. Reusing a key with different inputs produces a conflict without changing stock. A new key permits a separate reservation.

ChallengeSend repeated calls, change the quantity under the same key, then check a valid new-key request. Run the same cases against both versions.

EvidenceComplete timestamped calls and responses, inventory state after each response, source code and SHA-256 hashes. A short live display recording supports the trace.

Boundary: one AIKUS-built tool, mock inventory, sequential calls within one process. Assumes the caller supplies a stable idempotency key; whether a given agent does is not tested.

Not tested: concurrency, lost responses, crashes, restart durability, key expiry, multiple instances, identity and tenant isolation, retries after unsuccessful reservations, shipping, cancellation, stale data, recovery or production. Keys are remembered only after successful reservations; retry behaviour after errors has not been assessed.

This lab demonstrates detection of a disclosed seeded flaw and verification of the fix under the tested conditions. It is not a customer API engagement and does not extend Delivery Check’s agreed API scope.

Inspect the public trace, findings, hashes and boundary →

Request the case evidence Contact AIKUS

Request the source code, recording and full case pack from the AIKUS team.

Delivery Check

A bounded check alongside your existing delivery and testing work.

Agree the boundaryOne API product, up to 10 endpoints, one test environment and one agreed test-data set.

Challenge the behaviourAgree the relevant conditions, such as dependency failure, retry behaviour, partial completion and recovery.

Get usable evidenceA Delivery Evidence Report with material findings, coverage gaps, unresolved conditions and one retest round.

Report within 15 working days of confirmed working access. Testing takes place in the supplied test environment. Your team retains the release decision.

The MCP tool lab above demonstrates our challenge-and-evidence approach. Delivery Check remains an API package with its own agreed scope.

Read the Delivery Check scope Discuss your project

Work alongside your team

Bring an API delivery and the conditions you want to examine. We agree scope and access with you, then provide reproducible findings your team can use.

For forward-deployed engineering teams: model evals and tool-layer checks answer different questions. Our lab examines what a tool does when requests repeat or inputs change. Whether an agent supplies a stable key remains untested. Any MCP engagement would need separately agreed scope.

AIKUS is operated by Dynacov.