Submission Deadline Architecture
Designing a reporting pipeline around a fixed external deadline, where late is a breach and the recovery window is part of the schedule rather than a contingency.
An internal report that is late is an inconvenience. A regulatory submission that is late is a reportable failure, so the pipeline's design constraint is not throughput but certainty of completion by a specific time.
That changes the arrangement in specific ways. The schedule must include a recovery window: if the run completes at the last possible moment, a single failure means a breach, so the target completion is early enough to permit at least one full re-run. Every stage needs a checkpoint so a failure resumes rather than restarts. Dependencies on upstream systems become contractual — a source that delivers late makes the submission late, so their delivery time is part of the obligation chain and needs an agreement rather than an assumption.
Two further requirements distinguish these pipelines. Lineage must be demonstrable, because a regulator may ask how a figure was derived and the answer has to trace to source records. And the submitted version must be reproducible — what was sent, from which inputs, under which code version — which means archiving the inputs and the logic alongside the output rather than only the output.
The failure to design for is a correction after submission, which is a defined process with its own notification requirements, not an ad-hoc re-run.