Create an enterprise integration acceptance matrix

A connector is not accepted because one happy-path API call returns 200. Enterprise acceptance spans data contract, authorization, tenant isolation, retries, recovery, business exceptions and operability.

Build the decision artifact

Build rows from risks and acceptance criteria. Give each row a layer, test, precondition, expected result, owner and immutable evidence reference. Include normal, boundary, failure and recovery paths. Decide which failures block release and who may accept a documented residual risk.

The enterprise delivery lab makes this reasoning executable with synthetic data:

from enterprise_cases import acceptance_matrix_case

result = acceptance_matrix_case()
assert result["passed"] == 3
assert result["failed"] == ["UAT-09"]
assert result["accepted"] is False
assert len(result["rows"]) == 4

Three synthetic rows pass, but the business exception assignment fails UAT-09, so overall acceptance is false. This is the point of the matrix: strong contract, security and recovery evidence cannot erase a broken user outcome.

Test the failure path

Large matrices become ceremonial when rows say only “tested” or link to mutable screenshots. Keep them risk-based, executable where possible and connected to the exact build. Re-run affected rows after connector, model, identity or policy changes.

Save evidence that another reviewer can inspect:

• risk-to-test acceptance matrix
• versioned fixtures and build identifier
• machine-readable reports plus reviewer notes
• waiver owner, expiry and residual risk

This exercise aligns with the enterprise delivery, secure integration, operations and leadership work in the FDE for Professionals course. The course link describes the pathway; this local draft and its synthetic verifier do not claim that a client deployment, security approval or production result occurred.

Practice task

Create one acceptance row for each of four layers. Make one fail and write the exact decision required before release can proceed.

Continue learning

This article is part of the Enterprise AI delivery and architecture sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Define operational ownership before client handover.
• Continue with Review an AI architecture for avoidable complexity.

Reference: GOV.UK Service Manual: service assessments.