Analytics & KPIs

The complete measurement system for the Sindh IT Portal — Facilitation Desk (SITP): the nine metric families, seven role dashboards, GIS heatmap, public transparency layer, scheduled digests, exports, anomaly detection, self-serve reporting, and the master KPI catalog.

1. Purpose & Scope

This document specifies every metric, dashboard, report, and control the SITP analytics plane must produce. It is the single reference used by the engineering team (MAAHIR) to build materialized views, by the S&ITD product owner to accept dashboards, by departmental stakeholders to interpret their performance, and by the public to understand what is and is not published.

The analytics plane is responsible for three things:

1. Operational insight — let officers, DGs, department admins, secretaries, the SACM/Minister, and the super admin see the live and historical state of the portal relative to SLAs and targets.
2. Accountability & transparency — let companies track their own interactions and let the public see anonymized aggregates about how departments are serving the IT industry.
3. Governance & cost control — let S&ITD govern data access, AI spend, retention, and audit completeness from the same plane.

This document covers the nine metric families, the seven role dashboards (including the public transparency dashboard), the GIS/district heatmap, scheduled digests, exports, anomaly detection and SLA-breach prediction, saved views / favorites / embeddable widgets, a definitions glossary, data freshness and accuracy controls, and the self-serve report builder (Metabase). The underlying architecture (MariaDB materialized views/cubes, Metabase embedding, ECharts/Recharts, WebSocket live push, server-side export, cron digests) is summarized in §3 and detailed in /specs/en/15-tech-architecture/ §14.

2. Analytics Principles

Every metric, dashboard, and report in SITP obeys the following ten principles. They are referenced by ID (AP-1 … AP-10) throughout this document and in acceptance criteria.

3. Analytics Architecture (Recap)

This section recapitulates the analytics-specific portion of /specs/en/15-tech-architecture/ §14 so this document is self-contained. The full component-by-component rationale lives in the technical architecture doc.

3.1 Aggregation strategy

Dashboard reads never hit transactional tables directly. The Analytics module maintains a set of materialized views and lightweight cubes in MariaDB, refreshed by scheduled BullMQ workers on cadences defined per KPI (see §6). The pattern is:

• Transactional tables (tkt_*, org_*, aud_*, ai_*, not_*, …) are the system of record.
• Aggregation tables (anl_mv_*) are denormalized, pre-grouped rollups (by day × dept × category × district × severity × …) keyed for the dashboard's hottest group-by queries. Each anl_mv_* is refreshed on its own schedule (every 5 min for live-ish; hourly for operational; nightly for historical completeness).
• Cube-style tables (anl_cube_*) hold multi-dimensional sums and counts that allow the UI to pivot by any of the pre-cubed dimensions without re-querying the transactional tables.
• Public aggregates (anl_pub_*) are an entirely separate, anonymized, denormalized table populated by a single nightly worker from anl_mv_*, with suppression rules applied (see §11). The public dashboard reads only from anl_pub_*.

Heavy historical queries and Metabase ad-hoc reads run against a read replica once read replicas are introduced (see /specs/en/15-tech-architecture/ §5.6). Until then, Metabase is pointed at a low-priority connection pool with its own throttle so analyst reads cannot starve the request path.

3.2 Visualization stack

• Custom dashboards — ECharts/Recharts in the Next.js portal for the seven role dashboards, the GIS/district heatmap, and the public transparency dashboard. Tiles support filters (date range, department, category, district, channel, severity, locale).
• Metabase (embedded) — self-hosted; embedded via signed URLs for internal roles. Used for ad-hoc exploration, deep-dive operational reporting, and the self-serve report builder (see §15). Metabase connects read-only to the analytics schema; it can never write.
• WebSocket live push — selected tiles (open-ticket count, breaching-tickets, this-hour volume, officer active/idle) subscribe to the WebSocket gateway. Counts are pushed by BullMQ workers and the API on domain events; full re-renders are debounced (see §3.4).
• Server-side exports — PDF via Puppeteer (for letter-quality, letterhead-capable reports) and Excel via ExcelJS (for analyst-friendly multi-tab workbooks). CSV for raw extracts. All exports are generated by BullMQ workers and delivered via presigned MinIO URLs (see §12).

3.3 Public transparency separation

Public-facing dashboards read only from anl_pub_*. No live query path connects the public route to the transactional or even the internal aggregate tables. This guarantees that a bug in the public UI cannot leak a ticket row, a company name, or an officer name. The nightly worker that populates anl_pub_* applies the suppression rules in §11.3.

3.4 Live-push and staleness contract

Live tiles subscribe to channels scoped by RBAC; the gateway never trusts a client-asserted scope. Pushes are debounced (e.g., a count tile re-renders at most once every 5 s even under burst). Each tile carries a last_refreshed_at timestamp and a freshness SLA (see §17). If the worker falls behind, the tile is marked stale with a visible badge; stale data is never silently presented as current.

4. Analytics Data Flow (Diagram + Description)

The diagram shows how a domain event (a ticket state change, an AI call, a notification delivery, an audit write) flows through the analytics plane and surfaces on dashboards, digests, exports, and the public page.

Written description. Domain events from every stateful module — ticket transitions, org/RBAC changes, AI call audit rows, notification delivery receipts, audit-log writes, and comms activity — are published onto a Redis pub-sub fan-out. Three classes of BullMQ worker consume these events and maintain the analytics store: materialized-view refreshers keep anl_mv_* fresh at 5-minute or hourly cadence; cube refreshers rebuild anl_cube_* hourly or nightly; and the public anonymizer worker reads anl_mv_* once nightly and writes the fully-anonymized, suppression-applied anl_pub_* table that only the public dashboard ever reads. Configuration — targets, thresholds, digest schedules, anomaly rules — lives in anl_cfg_* and feeds both the surfaces (so tiles show target lines) and the anomaly/digest workers.

Six surfaces consume the analytics store: the role dashboards (custom ECharts/Recharts, fed by anl_mv_* plus WebSocket live push for count tiles); Metabase embedded for ad-hoc exploration over anl_cube_*; the scheduled digests rendered from anl_mv_*; the export workers producing PDF/Excel/CSV from anl_mv_*; the anomaly detector and SLA-breach predictor reading trends in anl_mv_* against thresholds in anl_cfg_*; and the public transparency dashboard reading only from anl_pub_*. Breach-prediction alerts flow back through the notifications pipeline (digests, in-app, WebSocket) and never expose raw ticket data to recipients outside their RBAC scope.

5. Conventions Used in the KPI Catalog

The KPI catalog (§6) and the master table (§18) use these conventions:

• KPI ID — KPI-<FAM>-<nnn> where <FAM> is the three-letter family code (VOL, SPD, SLA, QLT, PERF, AIM, COM, GOV, PUB). IDs are stable across EN/UR/SD and never renumbered.
• Unit — the canonical unit (count, ratio (0–1), percent, minutes, hours, days, PKR, tokens, events/day, score (0–5 or 0–100 as noted)).
• Target — the default V1 target. Targets are configurable per department via anl_cfg_*; the table shows the platform default.
• Source — the primary source table or event stream. tkt_* = ticketing; org_* = org/RBAC; aud_* = audit; ai_* = AI call audit; not_* = notifications; com_* = comms; int_* = integrations; fil_* = files. All KPIs are read from anl_mv_* rollups derived from these sources.
• Audience — role codes: SA Super Admin, DA Dept Admin, DG Director General, OF Officer, SEC Secretary, MIN Minister/SACM, CO Company, PUB Public. A KPI's audience is the set of roles whose dashboards show it (see §7).
• Refresh — the maximum staleness the tile will show before being marked stale: live (≤ 5 s via WebSocket), 5m, 15m, hourly, daily, weekly, monthly. Nightly historical completeness reconciliation is implied for all.
• All time-windowed KPIs are computable over any bounded date range and any of the standard grains (hour, day, ISO week, Gregorian month, Gregorian year). Hijri equivalents are derived at presentation only.

6. The Nine Metric Families — KPI Catalog

6.1 Family 1 — Volume & Throughput (VOL)

Volume and throughput measure how much demand the portal is absorbing and how quickly that demand is being closed out, by every meaningful cut (department, category, district, channel, severity, company-size tier).

6.2 Family 2 — Speed (SPD)

Speed measures latency across the ticket lifecycle: how fast the company hears back, how fast the issue is resolved, and where time accumulates inside the workflow.

6.3 Family 3 — SLA & Escalation (SLA)

SLA metrics measure conformance to the configurable response/resolution windows (default 2 / 5 / 10 days) and the behaviour of the escalation ladder.

6.4 Family 4 — Quality & Outcome (QLT)

Quality metrics measure whether resolutions actually satisfied the company, whether the proof-of-resolution gate held, and whether the first contact was enough.

6.5 Family 5 — Department & Staff Performance (PERF)

Department and staff performance metrics drive leaderboards, workload balancing, and bottleneck identification. All PERF KPIs are scoped by department unless the viewer is Super Admin (cross-department) or Public (anonymized department ranking only — see §11).

6.6 Family 6 — AI Module Metrics (AIM)

AI metrics measure both the quality of each AI capability and the cost of running it. Every quality KPI is paired with its engine and token/cost dimension so S&ITD can govern AI spend from the same dashboards that show AI quality.

6.7 Family 7 — Engagement & Communications (COM)

Engagement and comms metrics measure whether the portal's notification and chat channels are actually reaching and being used by their audiences.

6.8 Family 8 — Governance & Compliance (GOV)

Governance and compliance metrics give S&ITD assurance that access is reviewed, audit is complete, retention is honoured, and statutory categories (RTI) are handled on time.

6.9 Family 9 — Public Transparency (PUB)

The Public family is the only set of KPIs exposed on the public transparency dashboard (see §11). Every KPI here is sourced from anl_pub_* (nightly anonymized), never from a live transactional query, and obeys the suppression rules in §11.3.

7. The Seven Role Dashboards

Each role gets a dashboard tuned to its decisions. Every tile satisfies AP-1 (live + historical) and AP-2 (drill-down to the scoped ticket list). The role codes used here match /specs/en/04-roles-permissions/.

7.1 Super Admin Dashboard (SA)

Cross-department, cross-channel, system-wide view. The only role with infrastructure + AI-cost + governance tiles alongside operational KPIs.

Operational tiles: KPI-VOL-001..006, 013, 015 · KPI-SPD-001, 002, 008, 011 · KPI-SLA-001, 002, 003, 004 · KPI-QLT-001, 006, 012 · KPI-PERF-001, 009. Volume cuts: volume by channel, category, district, department, company-size tier (KPI-VOL-007..011). AI spend & quality: KPI-AIM-001, 004, 006, 008, 014, 015, 017, 018, 019, 020 (full AI family accessible). Engagement/comms: KPI-COM-001..004, 008, 010. Governance/compliance: full GOV family (KPI-GOV-001..013), including access-review completion, audit completeness, retention executions, step-up events, privileged-action count. Config surfaces: targets (anl_cfg_*), feature-flag status summary, digest schedule health, freshness/staleness monitor for all anl_mv_* workers (see §17). Special: system health badges (portal/API/docs/notifications uptime from the public status page), MariaDB/Redis/MinIO exporter summaries (read-only), Metabase launch link.

7.2 Department Admin Dashboard (DA)

Scoped to one department and its nested sections. Drives staffing and workload decisions.

Operational tiles: KPI-VOL-001..003, 005, 007, 008 (dept-scoped) · KPI-SPD-001, 003, 004, 007, 012 · KPI-SLA-001, 002, 003, 009 · KPI-QLT-001, 002, 005, 008. Workload & staff: KPI-PERF-002 (Gini), KPI-PERF-005, 006, 007, 008, 013, KPI-PERF-010 (bottleneck section), KPI-PERF-011, 012 (top/under performers). Section drill: every aggregate drillable to the section and to the individual officer's queue. Engagement: dept-scoped KPI-COM-008, 009, 010, 011. Exports: one-click daily dept pack (PDF) for circulation.

7.3 DG / Director Dashboard (DG)

Oversight of departments under the DG's purview, focused on SLA risk and escalation. Notify-only versus action powers are honoured per the configurable oversight matrix (/specs/en/04-roles-permissions/ §9).

At-risk focus: KPI-SLA-002, 003 (breach + at-risk, live), KPI-SLA-005 (escalation rung distribution), KPI-SPD-010 (time-in-escalation), KPI-SLA-011 (breach recovery). Outcome: KPI-QLT-001, 005, 006, 012, KPI-PERF-001 (leaderboard for purview). Department comparison: side-by-side dept tiles under purview, with KPI-SPD-011, 013 per dept. Action surface: approve sensitive/VIP closures, push tickets down the escalation ladder — both gated by oversight config and step-up auth.

7.4 Officer Dashboard (OF)

Personal productivity view: "my queue, my SLA clock, my CSAT."

My queue: open tickets assigned to me (live), sorted by SLA-due; aging buckets KPI-SPD-008 (mine); KPI-SLA-003 (my at-risk tickets). My speed: KPI-SPD-001, 005, 006 (my FRT, time-to-ack, handle time). My quality: KPI-PERF-003, 004, 005, 006 (my CSAT, resolution rate, throughput, handle time), KPI-QLT-008 (my FCR). Drafts & AI assist: my draft-adoption rate (KPI-AIM-006, personal view), AI suggestions pending my review (summary, routing, draft). Comms: my mentions/DMs (KPI-COM-010 for my responsiveness), my presence hours (KPI-COM-011).

7.5 Secretary / Minister Dashboard (SEC / MIN)

Executive-summary view for the political and administrative leadership (Secretary S&ITD, Minister/SACM). Numbers are platform-wide or purview-wide; detail is one click away but not in your face.

Headline tiles: KPI-VOL-001, 002, 005, KPI-SLA-001, 010, KPI-QLT-001, 012, KPI-PUB-010. Accountability: KPI-PERF-001 (department leaderboard), KPI-PERF-009 (bottleneck dept), KPI-SLA-005 (how many on each escalation rung, including rung 3 = SACM). Trend: KPI-VOL-013 (MoM/YoY growth), 90-day trend lines on SLA compliance and CSAT. AI & cost (MIN/SEC only): KPI-AIM-018 (per-engine cost rollup), KPI-AIM-008 (chatbot deflection), KPI-AIM-020 (on-prem/cloud share — data-residency posture). RTI: KPI-GOV-007, 008 (RTI volume + statutory compliance). Public transparency preview: a read-only mirror of what the public currently sees (§11), so leadership can compare internal vs published numbers. Delivery: the dashboard content is also pushed as the scheduled digest (§8).

7.6 Company Dashboard (CO)

The company representative's own analytics: my tickets, my response times, my satisfaction — scoped strictly to my company's tickets (RBAC-enforced; never another company's data).

My tickets: open/closed/resolved counts, aging buckets, current SLA status per ticket, at-risk flag. My responsiveness: KPI-SPD-009 (await-on-company duration — time the company itself added), inbound reply rate from the company side. My satisfaction: CSAT I have given, appeals I have filed, appeal status. My interactions: notifications I received and read, chat sessions with the desk, KB articles I found helpful. Action surface: file a ticket, respond to an await, request a TRI meeting, submit CSAT.

7.7 Public Transparency Dashboard (PUB)

The only dashboard visible without authentication. Detailed in §11. Sourced exclusively from anl_pub_*. Tiles: KPI-PUB-001..010, the GIS heatmap (§10), a plain-language FAQ explaining each metric, and a "data published on" timestamp.

8. Scheduled Digests

A cron-driven BullMQ job renders per-role, per-department digests on configurable cadences and pushes them through the notifications pipeline (email/SMS/WhatsApp/in-app, per recipient preference). All digests are multilingual (recipient's locale) and carry Gregorian + Hijri dates.

8.1 Default digest schedule

Every cadence above is configurable per recipient, per department, and per environment via anl_cfg_*. The preference center lets any user mute, switch to digest-only, or change channel per digest type.

8.2 Sample digest layout (Secretary, daily)

Sindh IT Portal — Facilitation Desk
Daily Digest · S&ITD Secretary
Gregorian: Mon 17 Jul 2026 · Hijri: 2 Safar 1448

1. HEADLINE  (yesterday / rolling 7-day)
   - Tickets created:        312   (7-day avg 298)
   - Tickets resolved:       287   (7-day avg 271)
   - Open backlog:          1,453
   - SLA compliance:         96.2% (target 95%) ▲
   - CSAT:                   4.3 / 5
   - At-risk (next 24h):      18   [drill]
   - Breaching:                6   [drill]

2. DEPARTMENT LEADERBOARD (top 5 / bottom 3)
   Top:    Labour (98.4%) · IT (97.9%) · Investment (97.1%)
   Bottom: Excise (89.2%) · Revenue (90.1%) · Works (91.4%)

3. ESCALATION RUNG
   Rung 1 (2d, DG):   42
   Rung 2 (5d, Sec):   9
   Rung 3 (10d, SACM): 2   [drill]

4. RTI  (statutory)
   RTI handled:           7
   RTI within deadline: 100%

5. AI & COST
   AI calls yesterday: 2,114   cost: PKR 41,320
   On-prem share: 38%  Chatbot deflection: 47%

6. ANOMALY ALERTS  (from §14)
   - Excise dept SLA down 6.1pts vs 7-day avg.
   - FBR intake volume +220% vs baseline (spike).

[View full dashboard]   [Drill at-risk]   [Manage preferences]

8.3 Digest controls

• Composability: each digest's sections map to KPI IDs in anl_cfg_*, so an admin can add/remove sections without code.
• Suppression: digests respect the same anonymization/suppression rules as the public dashboard where a section crosses into PUB-family KPIs.
• Failure handling: if a digest job fails, the failed-recipient list is retried with backoff and surfaced on the Super Admin freshness/staleness monitor.

9. Exports

9.1 Formats and engines

All exports are generated by BullMQ workers; the user is notified (in-app + email) when the file is ready and downloads via a presigned MinIO URL with a short TTL.

9.2 Export contract

• Filters preserved: every export records the exact filters and grain used (date range, department, category, district, channel, severity, locale) in both the file header and the aud_event row.
• RBAC-enforced: the export worker re-checks the requesting user's scope at generation time (defence in depth — a stale session cannot widen scope).
• Step-up for sensitive: exports containing confidential/VIP tickets or PII require step-up auth before the job is queued.
• Audit: KPI-GOV-009 (export events) captures who/what/when/filters for every export.
• Retention: export artifacts expire from MinIO per the data-class retention rule; the aud_event row is retained for the audit window.

10. GIS / District Heatmap

The GIS/district heatmap visualizes KPI-VOL-009, KPI-PUB-009, and KPI-SLA-010/KPI-PUB-007 on a map of Sindh's districts.

Specification:

• Layer: choropleth over Sindh district polygons (GeoJSON sourced from a versioned, government-approved boundary file in _diagrams/gis/).
• Metric selector: volume / SLA compliance / median TAT / CSAT — selectable by the viewer (internal) or fixed to volume + SLA compliance (public).
• Grain: district; optional drill to tehsil where data volume permits (suppression applies below district for the public layer).
• Time selector: any bounded range; defaults to last 30 days.
• Colour scale: sequential single-hue (Ajrak indigo ramp); colour-blind safe; threshold bands configurable in anl_cfg_*.
• Interactivity: hover → district name + value + sample size; click → drill-down list (internal roles) or district summary card (public).
• Anonymization (public): the public heatmap reads from anl_pub_* and obeys the suppression rules in §11.3 (no district with < n tickets is shown with a value; it is grouped into an "Other / insufficient data" bucket — n is configurable, default 5).
• Performance: rendered client-side with ECharts geo; geometry served pre-simplified; data payload kept under 50 KB.

Implementation note: no PostGIS dependency — the heatmap uses bounding-box math and a lightweight spatial index (see /specs/en/15-tech-architecture/ §5.1).

11. Public Transparency Dashboard

The public dashboard is the portal's accountability commitment: any citizen, journalist, or company can see, at a glance, how the Sindh IT Portal is performing for the IT industry — without logging in and without exposing any individually-identifiable data.

11.1 What is shown

• KPI-PUB-001 Total received, KPI-PUB-002 total resolved, KPI-PUB-003 currently open.
• KPI-PUB-004 overall SLA compliance, KPI-PUB-005 median resolution time, KPI-PUB-010 public CSAT.
• KPI-PUB-006/KPI-PUB-007 volume and SLA compliance by department (department names are public bodies and are shown).
• KPI-PUB-008 volume by category.
• KPI-PUB-009 GIS district heatmap (§10).
• A plain-language "what do these numbers mean?" FAQ (multilingual) and a "data published on" timestamp.

11.2 Anonymization rules

1. No PII, ever. No company name, no officer name, no requester name, no ticket ID, no free-text appears on the public dashboard.
2. Separate table. All public KPIs read from anl_pub_*, populated by the nightly anonymizer worker from anl_mv_*. No live query path connects the public route to transactional tables.
3. Aggregation only. Every public number is an aggregate over ≥ n tickets (default n = 5). Smaller cells are suppressed or rolled into "Other / insufficient data".
4. No small-cell leakage. Cross-tabbing two public dimensions (e.g., department × category) is suppressed where any cell falls below n, to prevent re-identification by subtraction.
5. Lag. Public data is published with a 24-hour lag (yesterday's anonymized rollup), so a filer cannot recognize their own just-filed ticket in the numbers.
6. No raw exports. The public dashboard offers no CSV/Excel export of underlying rows — only the published aggregates.
7. Audit. Every publish event (worker run, row counts before/after suppression) is written to aud_event and visible to Super Admin.

11.3 Suppression parameters (configurable)

11.4 Refresh

Nightly (01:00 PKT) via the anonymizer worker. The "data published on" timestamp on the page reflects the last successful publish; a failed publish leaves the previous day's data visible and raises a Super Admin alert (§17).

12. Saved Views, Favorites, and Embeddable Widgets

12.1 Saved views

Any internal user can save a dashboard state (tiles + filters + grain + date range) as a named view. Saved views are private by default and shareable within the user's department. Super Admin can promote a saved view to a department default.

12.2 Favorites

Any tile or KPI can be pinned as a favorite; favorites aggregate into a personalized "My view" tile strip at the top of the user's dashboard. Favorites persist across sessions and locales.

12.3 Embeddable widgets

Selected tiles can be exported as embeddable widgets (signed, time-limited iframe URLs) for embedding in:

• Departmental intranets and the S&ITD public site.
• The Minister/SACM briefing pages.
• Partner portals (PSEB, P@SHA) for cross-industry visibility — only PUB-family KPIs are embeddable externally.

Embeddable widgets are signed with a rotating key, scoped to a specific KPI + filter, and rate-limited. They never carry credentials; they only display anonymized or already-authorized aggregates.

13. Anomaly Detection & SLA-Breach Prediction

13.1 Anomaly detection

A scheduled worker scans anl_mv_* for statistically unusual changes and raises alerts:

• Threshold rules (configurable in anl_cfg_*): e.g., "department SLA compliance drops > 5 points vs 7-day average", "intake volume > 200% of baseline for a channel", "CSAT for a department < 3.5 for 3 days".
• Statistical anomalies: simple z-score / rolling-median-plus-MAD over a trailing window, per KPI per cut. No black-box ML at V1 — explainable rules first.
• Alert routing: anomalies flow into the notifications pipeline (in-app, WebSocket, and into the next relevant digest) and onto the Super Admin freshness/anomaly monitor.

13.2 SLA-breach prediction

KPI-SLA-003 (at-risk count) is computed by a lightweight predictor:

• For each open ticket, compute remaining SLA budget vs. remaining SLA clock, factoring the ticket's category-historical TAT distribution and the assignee's recent velocity.
• If projected resolution > SLA due with > p confidence, flag the ticket at-risk.
• p is configurable (default 0.70). The predictor is recalculated every refresh cycle for KPI-SLA-003 and on every relevant domain event for the live tile.
• Accuracy of the predictor is itself tracked (predicted_at_risk_that_breached ÷ predicted_at_risk) as a governance check; target ≥ 0.70 precision to limit alert fatigue.

13.3 Alert hygiene

• Every anomaly/breach alert is deduplicated within a window and rate-limited per recipient to avoid fatigue.
• Alerts carry a drill link into the scoped ticket list (AP-2) so the recipient can act immediately.
• Alert definitions are versioned; changes are audited like any other config change.

14. Data Freshness & Accuracy Controls

14.1 Freshness SLAs

Each anl_mv_* table has a published freshness SLA (the Refresh column in the KPI catalog). A monitor compares actual last-refresh to the SLA; breach raises a stale badge on affected tiles and a Super Admin alert.

14.2 Reconciliation

Every nightly run reconciles anl_mv_* against the transactional source totals (row counts and sum checks). Discrepancies above a threshold raise a Super Admin alert and a re-compute job; the affected tiles are marked stale until reconciled.

14.3 Accuracy controls

• One definition per KPI (AP-5) — see glossary §16.
• Sampled audits: Super Admin can trigger a sampled re-computation of any KPI against raw rows; results attached to the freshness monitor.
• Reproducibility: every export and every saved view records its filter set, so any number in a report can be reproduced from anl_mv_* + the filter set + the version of the definition.

15. Self-Serve Report Builder (Metabase)

Internal roles (primarily Super Admin, Dept Admin, DG, Secretary) get embedded Metabase for ad-hoc exploration and bespoke reports.

• Access: signed-URL embedding in the portal; users never see the Metabase login screen. RBAC scopes are passed through as embedding parameters so a Dept Admin's Metabase session is already scoped to their department.
• Data boundary: Metabase connects read-only to anl_cube_* (and selected anl_mv_*); never to transactional tables; never to anl_pub_* (the public writer is the only writer there).
• Saved questions & dashboards: Metabase questions/dashboards can be saved privately or shared within role; sharing is governed by the same RBAC.
• Exports from Metabase: produce CSV/Excel through the same audited export path (§9) so they appear in KPI-GOV-009.
• Sandboxing: row-level sandboxing is enforced via Metabase sandboxing on top of the DB-level scope, so a Dept Admin literally cannot select another department's rows.
• Public embedding: disabled for ad-hoc questions. Only curated PUB-family tiles (§12.3) are embeddable externally.

16. Definitions Glossary (Metrics)

This glossary is the canonical source for every metric term. It is mirrored (metric-key-only) into _glossary.md so the same definitions surface in UR/Sindhi dashboards. Where a definition is non-obvious, the formula is given.

17. Configuration Surface (summary)

All tunables live in anl_cfg_* and are editable by Super Admin (step-up auth). Changes are audited (aud_event) and versioned.

18. Master KPI Catalog

The complete catalog: 9 families, 120 KPIs. Counts per family: VOL 15 · SPD 13 · SLA 12 · QLT 12 · PERF 13 · AIM 20 · COM 12 · GOV 13 · PUB 10.

19. Open Questions / TBD

End of document.