Saved reports
FR-8: a saved governed metric request, re-run on demand
A saved report is a structured governed request — a metric plus grouping and filters — recomputed in the engine on each run, never a stored instruction to a model.
The routing choice was made once, when the report was saved from a question, and that choice can be wrong: check that the metric and filters shown below are the ones you intend, because a misroute would produce a correct number for the wrong question.
Scheduling is not executed in this build. There is no server-side scheduler here: the schedules below are saved definitions only, every run on this page is user-triggered, and saved definitions live in this browser alongside sample fixtures rather than in a governed server-side store.
What this surface does and does not do
Every run is a governed query against a read-replica / ODS under query governors — never live Core Banking OLTP — and is recorded in the audit trail. The system reads and reports only; it never writes to a system of record.
There is no per-user authentication in this build — the principal on each report is a config value, not a signed-in user.
The audit entry carries the principal, the applied policy, the SQL, a row count and a content hash. The audit and saved-report layer persists query metadata and tokenised references, not raw PII; the dataplane persists no source rows into the graph.
The system takes no autonomous action. If alerting is wanted, it belongs here as a threshold on a saved governed metric that a person acts on, never as a free-text instruction to a model. Shareable Liveboards built from these saved queries are later-phase work (E6, FR-9) and are not present in this build.
§8 explicitly rejects a config-value principal as production auth: it requires SSO/OIDC against BoM Active Directory, with the principal derived from the session token. Nothing on this page demonstrates enforced per-user scoping.