Story: Design the report pipeline and the run configuration

One report definition is designed to run end to end from the scheduler through the workflow to the compute grid and back. The run's configuration decides which phases execute and which are replaced by a prepared substitute, so the pipeline can be exercised while the components it depends on are still being built. The implementation split to Implement the full report pipeline at the sprint 26 close on 2026-10-05.

The target state is written as Report Processing, a structure note over nine pages covering the definition and schedule, the pipeline, the orchestration, the data characteristics, pre-processing, the compute handoff, post-processing, substitution, and the interfaces.

On 2026-10-05, at the sprint 26 close, this story was reworded to the design and the run configuration it delivered and closed DONE: the run configuration selects a definition's phases, the reports have a document type and an inventory, and the target state and the decisions are written. The eight implementation tasks moved to Implement the full report pipeline.

• A definition's run configuration selects which phases execute, and the phases it names are the ones that run.

1. The run's configuration is the definition's own state. A column, resolved when the instance is created and carried into the workflow start message, so a run is reproducible from the database and works with no operator present.
2. The configuration is not the report type. The type axis stays a category of report; how a run executes is separate, so a substituted run and a live run of one definition differ in one field.
3. Phases hand each other storage URIs, never structures. Both chains therefore produce the same object at the boundary, which is what keeps the compute grid unaware of how its input was produced.
4. Phase results are addressed by role, not by index. Positional access is fragile with one chain and becomes a defect generator with two, so it changes before the second chain lands.
5. The engine package is a prerequisite. Registering the ORE build is seeded per engine build, not a phase of a run.
6. The reporting to compute handoff stays with the ACME smoke-test story. That story already owns the three defects that stop the tail being driven from reporting, and this story waits on it rather than duplicating it.
7. The demo-and-full pair was withdrawn. The story was commissioned around two modes, and the two tasks that carried them — task_demo-mode-end-to-end and task_full-mode-selection-export-import — were removed rather than re-scoped, because the substitution mechanism replaced the first and the pre-processing and post-processing tasks replaced the second. Their remaining purpose, proving each chain end to end, is carried by the two proof tasks below.
8. Live processing is designed now and built later. No phase that a substituted run proves may need to change to admit it.
9. The orchestration contract starts with the idempotency check. The analysis on Does reporting use what the workflow engine guarantees? found that no reporting handler checks whether the step it answers has already run, so a run recovered after a restart repeats the work of every phase it re-dispatches: assemble_bundle writes a second bundle row, and the export and the upload happen twice. The engine offers the check a handler needs and reporting does not use it. The contract cannot be called enforced while a phase does not converge, so Define and enforce the orchestration contract begins there rather than with the interface, and Use the engine's idempotency check in the reporting handlers carries the code fix.
10. A report page is where a report is described. Each report gets a page carrying its purpose, audience, frequency, measures, ORE configuration, parameters and test coverage, and an inventory lists them. The tree holds three enumerations of reports that do not agree, at three levels: a business catalogue, the seeded definitions, and the engine's analytic types. A report page is where those three meet for one report; they are not merged, because they are not the same list.
11. The phase list and the step list are different decompositions. A run is six phases and seven steps, or four when pre-processing is substituted. Pre-processing is four steps rather than one, and retrieval and post-processing are one step rather than two. Both decompositions are correct, so the pages state the mapping rather than picking one.
12. Deadlines and warnings are decided, not assumed. The engine has no step timeout, so a phase whose service never answers leaves the run in progress and is re-dispatched on every restart; until a deadline exists, recovering such a run needs a person. No reporting phase answers with warnings, and adopting them is a behaviour change rather than a cosmetic one, because the engine does not compensate a warned step.
13. A workflow owns no failure policy. The engine has one behaviour: on a failed step it compensates the steps that completed. workflow_definition has no policy field, so the story does not ask a workflow to declare the compensate-or-stop choice the engine cannot honour.

• Building the live chain. It is designed and tasked, not built.
• Parsing ORE results beyond writing them into the database; no analytics on them.
• Implementing the reports their pages describe. A page states what a report is for, who reads it and how it is configured; the analytics that produces it is separate work, and the pages say which parts of a report's run are not built.