From contract to result

Evidence behind the delivery.

A running pipeline is only part of the handover. Keep the rules, checks, and execution record behind it.

Evidence stays with the client.

The output is not just a running pipeline. It is the rulebook, validation trail, and operating notes behind the delivery.

01

Discovery pack

What the source really does.

02

Transformation contract

What the pipeline should produce.

03

Validation notes

Why the business can trust it.

Review the execution record

A workload returns structured status and diagnostics, but that result is not itself the official control-plane record. Orchestration interprets the result and records the queue outcome, run history, and failure evidence. The execution record can then be read alongside unit-test results.

These records answer different acceptance questions: what was executed, where it failed, what error was recorded, and which quality checks ran. Review them against the approved transformation contract rather than treating the existence of a target table as sufficient evidence.

State what the checks establish

The documented runtime supports data-integrity, duplicate-business-key, and null-business-key checks. Only enabled checks run. Their scope is narrow: they do not prove every business rule or every aspect of historical correctness, and a completed status can be returned when no checks are enabled.

Required test failure blocks successful completion, but checks run after the target write and do not automatically roll it back. Acceptance therefore needs the configured checks, their results, and the agreed requirement together.