Report Processing

Report definition and schedule — start here. The definition, its parameters and its run configuration, the job the scheduler holds on its behalf, and the instance that records a run. Read it first because everything below assumes the distinction it draws: the definition is configuration, the instance is state.

Report execution pipeline — the six phases end to end, what each is responsible for, which of them can be replaced, and what every phase may assume of the phase before it.

Report execution orchestration — read immediately after the pipeline, because it answers the question the pipeline raises: nothing calls a phase directly. The workflow engine invokes each one, rebuilds the chain on every dispatch, and re-dispatches unfinished work after a restart. The obligations this puts on a phase — idempotence above all — are what the phase pages below must satisfy.

Report execution at scale — read after the orchestration page. It follows one scheduled run through every service, from the definition to the completed instance. It defines the run grant and the token exchange that let a run with no caller act as its tenant and party, and the fair queues that let thousands of runs from many tenants share the platform.

Report processing data characteristics — the three kinds of data a run moves and the access pattern of each. Read it before the phase pages, because it explains their interfaces: why the domain reads must be bulk and scope-limited, why the engine's input is addressed by a digest of its inputs, and why results are loaded in bulk into narrow tables. It also states what to measure, and what each measurement would falsify.

Report pre-processing — selecting the trades, resolving the market data they need, mapping both into the engine's documents, and packaging an archive named by a digest of its inputs. The most expensive phase, and the one with the most dependencies.

Report compute handoff — the contract with the grid: what a run submits, what a workunit requires, what the worker does, what comes back, and what a run must guarantee about submitting twice.

Report post-processing — unpacking the engine's output and loading it into a result store shaped for the queries that will read it.

Report execution substitution — read after the phases it replaces. The two ends of the pipeline can each be replaced by a prepared substitute: pre-processing by an input archive that already exists, post-processing by recording only where the output is. This is what allows the pipeline and the workflow around it to be exercised before the trade and market data components are ready, and the page states what such a run proves and what it does not.

Report processing interfaces — every message and every storage key a run uses, with its publisher and consumer. Read last, or alongside whichever phase page you are implementing; it is a list rather than an argument.