Sample report — verify the layout before you commit
Step 3 of the workflow (§3 Goal 3, FR-4).
- 1. NL query
- 2. agent finalises prompt scope
- 3. sample report to verify layout — you are here
- 4. on-command data-inconsistency scan
- 5. automated on-demand reports
Compose a governed metric request below — you never write SQL — and a bounded sample renders with the exact column set the full run would use.
Catalog scoped to principal: not supplied — demo stub, not a per-user login.
There is no SQL input here by design: Phase 1 has no unrestricted ad-hoc SQL path (§3). The compiled SQL is shown as evidence (FR-5), never authored by you, and a question no governed metric covers is declined honestly rather than guessed (FR-13).
Changing group_by, filter_by or max_rows re-runs the sample bounded at max_rows, so no re-render costs a full-table scan.
Dynamic shareable dashboards (Liveboards) sit after this workflow and are later-phase work (E6, FR-9) — they are not part of this build.
The principal is a config value in this build, not per-user authentication; §8 rejects that as production auth.
Compose the governed request
Result
Rendered exactly as the full report will render it.
Compose a request above to render a bounded sample.
How to read this
Every figure is computed by the engine from one sanctioned definition and shown with the SQL that produced it. The model never emits a number — but it can still route a question to the wrong metric, which is why you pick the metric yourself here.
Governed queries run against a read-replica / ODS. No query path touches live OLTP.
Aadhaar / UID numbers render last four digits only. Everything else in the catalog is answerable.
Because the engine authors every figure from the metric's single sanctioned definition, fabricated values are removed by construction on this path. What is not removed is interpretation error: when a question is routed automatically, the model still chooses which governed metric and filters match it, and it can choose wrong, in which case the engine returns a correct value for the wrong question. That is why the interpretation is surfaced for confirmation (/clarify, /trace) and why misroute rate is a measured KPI (§3). On this page you make that choice yourself.
The read-replica / ODS runs under query governors and per-connection resource caps, so no report can degrade the bank's operational systems (§6, R8).
Data access is not phased. The catalog spans the bank's full governed surface — deposits and advances, payments and ATM Electronic-Journal cash, KYC and financial inclusion, alongside the operational domains — so every metric listed above can be selected here. What governs an answer is the sanctioned definition it compiles to, not a restriction on which domain you may ask about.
The masking carve-out is a rule rather than a boundary: the raw Aadhaar / UID column is not projectable by any governed metric, because the Aadhaar Act attaches criminal liability to UID handling. Processing payment and financial data places this build inside the Payment and Settlement Systems Act and RBI's payment-data localisation direction — 360 Labs' working position, subject to confirmation by BoM legal and the BoM DPO.