Governed metric catalog
GET /discover — the closed set the router must choose from (FR-1).
Every figure the system reports is computed by the engine from one of the definitions below. The model chooses which definition matched the question — never the number — and it can choose wrong, so that choice is surfaced and measured.
Aadhaar / UID numbers render last four digits only. Everything else in the catalog is answerable — nothing is held back as out of scope.
Catalog for principal: owner — demo stub, not a per-user login.
The model never emits the number and never authors SQL text. It emits a structured MetricRequest; the semantic-layer compiler resolves that to SQL. What the model does choose is which definition, dimensions and filters matched the question, and it can choose wrong: a misroute returns a correct value for the wrong question. That interpretation error is surfaced (clarify and trace) and measured as a KPI (§3); it is not eliminated.
In the bank's own terms, the surface this catalog spans is: business and branch operations across the network; the deposit and lending book, including asset quality; financial inclusion and priority sector — PMJDY, DBT, PMSBY / PMJJBY, Atal Pension Yojana, Mudra and PSL achievement; payments and cards across Maha UPI, IMPS, NEFT and RTGS; and the digital channels — MahaConnect, MahaSecure, Zen Lyfe, WhatsApp Banking — together with the service quality that sits in front of all of it.
There is no phased restriction on which of the bank's data the Ask layer may reach. Monetary and payment figures, ATM Electronic-Journal activity, and KYC operational and document-status data are all in the catalog and answerable. What is governed is not which fields exist but how a figure is produced: every value below resolves to a single sanctioned, versioned definition, there is no ad-hoc SQL path, and the emitted SQL, join-paths, freshness and definition version travel with the answer into the audit log.
A question is declined only when it resolves to no governed metric at all — it is not in this catalog — or when policy denies it for the caller (FR-13 keeps those two causes distinct). “That field is out of scope” is no longer a reason this system gives.
Aadhaar and other UID numbers render with the last four digits only (XXXX XXXX 4021) and are never returned in full. The Aadhaar Act attaches criminal liability to UID handling, which is a materially different risk class from the disclosure and localisation regimes that govern payment data. Everything else about KYC — operational counts, processing durations, document status, verification state — is in scope and answerable. This is a masking rule applied at the catalog and presentation level, not a scope phase; definitions it applies to are marked Masked in the Sensitivity column.
Sensitivity records the class of data a definition touches, so the obligations attaching to an answer are visible at the point of use. It does not gate whether the metric is answerable.
- Operational — counts, rates, durations and ratios from operational systems.
- Financial — carries monetary values; rupee figures are rendered in lakh and crore, never as a raw integer.
- Payment — payment system data, which brings the Payment and Settlement Systems Act, 2007 and RBI's payment-data localisation direction into play.
- Personal — personal data of an identifiable data principal, so DPDP obligations apply.
Because the catalog covers payment and financial data, this build owns the Payment and Settlement Systems Act, 2007, RBI's payment-data localisation direction, RBI customer-liability rules on unauthorised transactions where relevant, and DPDP obligations across a materially larger personal-data surface — alongside the RBI Outsourcing of IT Services and IT Governance Master Directions and CERT-In. That characterisation is 360 Labs' working position, subject to confirmation by BoM legal and the BoM DPO. It is not settled fact.
Version and effective-from (Appendix C). Each definition change creates a new version with an accountable owner in the CDO office. A saved report pins the version in force when it was saved; a later version annotates that report rather than silently recomputing it.
- Sanctioned — signed off by the CDO office and safe to act on.
- Draft — authored, not yet signed off; not board-ready.
- Quarantined — a source column the definition depends on changed, so the metric is held in the metric-broken state (FR-7) and returns no result instead of a silently wrong one.
FR-1 requires /discover to be principal-aware, but this build has no per-user authentication (§8): the principal is a configuration value, which §8 explicitly rejects as production auth. What you see is therefore the full governed set for one configured principal, not a role-filtered view — no per-user scoping is enforced here. With financial, payment and personal definitions now in the catalog, that gap is materially larger than it was.