Discovery pack
What the source really does.
From contract to result
A running pipeline is only part of the handover. Keep the rules, checks, and execution record behind it.
The output is not just a running pipeline. It is the rulebook, validation trail, and operating notes behind the delivery.
What the source really does.
What the pipeline should produce.
Why the business can trust it.
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.
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.