OBF Compliance Monitoring Platform

Al Ain University · MoHESR OBF Guidebook v11.5 · Version 9.5.1

Detailed case study of the BRASS Digital Lab OBF Compliance Monitoring Platform — 10,000+ lines of R Shiny, 100% MoHESR compliance, RBAC, MFA, bilingual EN/AR interface.
Author

BRASS Digital Lab

Published

3 April 2026

Case Study # OBF Compliance Monitoring Platform

Al Ain University · UAE Higher Education · MoHESR OBF Guidebook v11.5

✓ 100% MoHESR Certified ✓ v9.5.1 Deployed ✓ 10,000+ Lines R Shiny ✓ RBAC + MFA ✓ Bilingual EN/AR

Platform at a Glance

100% MoHESR OBF Compliance

10K+ Lines of Production R Shiny

6 OBF Pillars with 24 KPIs Managed

9.5.1 Current Platform Version

9 User Roles (RBAC)

30 Seeded Users across 8 Colleges

∞ Audit Trail — Full History

1. Problem Statement

Al Ain University, in common with all UAE higher education institutions, is subject to MoHESR Outcome-Based Framework (OBF) requirements. The OBF framework ties institutional licensing and accreditation to demonstrated performance across six weighted KPI pillars: Employment Outcomes (25%), Learning Outcomes (25%), Collaboration with Partners (20%), Scientific Research Outcomes (15%), Reputation (10%), and Community Engagement (5%). Its latest update V11.5 (23 March 2026) introduces an additional, voluntary assessment for HEIs that evaluates future skills alignment, and AI-enabled teaching and learning. These latest changes are presented as forward-looking, non-compliance elements designed to support institutional innovation beyond the core OBF metrics.

Prior to the BRASS platform, Al Ain University managed OBF compliance through a combination of:

  • Disconnected Excel workbooks maintained by multiple departments
  • Manual data consolidation processes taking 40–60 hours per reporting cycle
  • Email-based evidence collection with no audit trail
  • Word document report assembly requiring extensive reformatting before MoHESR submission

Institutionally, material audit risk was a clear potential: no single system held the authoritative compliance record, evidence was scattered across departmental drives, and there was no real-time visibility into compliance status ahead of formal reporting cycles.

The core requirement was unambiguous: build a system that achieves and demonstrably achieves 100% OBF compliance — with the evidence to prove it.

2. Solution Architecture

The OBF Compliance Monitoring Platform is a modular R Shiny enterprise application with an embedded SQLite database, deployed on shinyapps.io with RBAC and MFA authentication, and available at the following weblink: https://brassbe1982.shinyapps.io/AAU-OBF-Platform-V9/

2.1 Architectural Approach

┌─────────────────────────────────────────────────────────┐
│                  OBF Compliance Platform                │
│                                                         │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌────────┐   │
│  │  Auth    │  │  Data    │  │  KPI     │  │  Rpt   │   │
│  │  Module  │  │  Entry   │  │ Dashboard│  │  Gen   │   │
│  │(RBAC/MFA)│  │  Module  │  │  Module  │  │ Module │   │
│  └─────┬────┘  └────┬─────┘  └─────┬────┘  └───┬────┘   │
│        └────────────┴──────────────┴────────────┘       │
│                         │                               │
│              ┌──────────▼──────────┐                    │
│              │     SQLite DB       │                    │
│              │  (Connection Pool)  │                    │
│              └─────────────────────┘                    │
└─────────────────────────────────────────────────────────┘

The application is structured into four primary Shiny modules:

  1. Authentication Module — Login, MFA verification, RBAC role assignment, session management
  2. Data Entry Module — KPI data input, evidence upload, validation rules, submission workflows
  3. KPI Dashboard Module — Real-time compliance dashboards, trend charts, pillar-level drill-down
  4. Report Generation Module — MoHESR-format PDF outputs via LaTeX, compliance certificates

2.2 Technology Stack

Component Technology Version Purpose
Application Language R 4.x Core application logic
Web Framework R Shiny 1.8+ Reactive UI and server
UI Theming bslib 0.7+ Bootstrap 5 components
Database SQLite 3.x Embedded data persistence
DB Interface DBI / RSQLite 2.3+ Parameterised queries
Connection Management pool 1.0+ Connection pooling
Data Tables DT 0.31+ Interactive table rendering
Visualisation plotly, ggplot2 — KPI charts and gauges
Forecasting forecast 8.21+ auto.arima KPI projections
Document Generation LaTeX + R Markdown — PDF report generation
Security Custom RBAC + TOTP — Access control and MFA
Package Management renv 1.x Reproducible environments
Deployment shinyapps.io — Production hosting

2.3 Database Schema

The platform uses 18 normalised SQLite tables across five functional domains:

  • Authentication: users, roles, user_roles, mfa_tokens, session_log
  • KPI Data: kpi_pillars, kpi_indicators, kpi_submissions, kpi_values, kpi_targets
  • Evidence: evidence_files, evidence_submissions, evidence_status
  • Workflows: workflow_stages, workflow_assignments, workflow_audit
  • Reports: report_runs, report_outputs

All tables implement: - Parameterised queries only (no string interpolation in SQL) - created_at / updated_at timestamps on all mutable records - created_by / updated_by user references for audit trail - Indexed foreign keys for query performance

2.4 Security Implementation

🔒 Role-Based Access Control

Three access tiers: - Admin — Full platform access, user management, system configuration - Data Officer — Data entry, evidence upload, draft submission - Viewer — Read-only dashboard access, report download

Module visibility and data write permissions are enforced at the server level, not just UI level.

🛡️ Multi-Factor Authentication

TOTP-based MFA on all accounts: - QR code enrollment on first login - 6-digit time-based token required on every session - TOTP secret stored hashed in database - Failed attempt lockout after 5 tries

3. KPI Compliance Dashboard

OBEF Platform — Compliance score across all six KPI pillars over six academic terms

T3 2025 — Final compliance scores across all 24 OBEF performance indicators

4. Outcomes & Impact

✅ Regulatory Outcomes

  • 100% MoHESR OBF Guidebook v11.5 compliance achieved during T3 2025
  • Real-time compliance visibility eliminating end-of-cycle surprises
  • Automated MoHESR-format report generation replacing 40+ hours of manual assembly per cycle
  • Full audit trail satisfying MoHESR review requirements

⚡ Operational Outcomes

  • Manual reporting effort reduced by 80%+ per compliance cycle
  • Evidence documented and timestamped at point of submission
  • Single authoritative data source across all departments and colleges
  • Role-appropriate access for 9 distinct user tiers, each with a defined role in the compliance cycle.
User roles and their primary purpose in the OBF compliance platform
Role Primary_Purpose
System Administrator Manages all users, settings, and system health. The technical and administrative owner of the platform.
MoHESR Officer Read‑only oversight of AAU’s institutional data; validates compliance for ministry purposes.
University Admin Institutional‑level coordination; oversees data completeness and generates institution‑wide reports.
University QA Chair Final approver in the workflow; responsible for data accuracy before HEDB submission.
College Dean Reviews and countersigns college‑level KPI data; second‑stage workflow approver.
College QA Chair Primary quality gatekeeper at college level; first‑stage workflow approver.
Program Director Submits programme‑level performance data and monitors programme outcomes.
Data Entry Officer Performs data entry of KPI values against reporting periods as directed.
Viewer Read‑only access to approved dashboard data for board members and observers.
  • This role hierarchy mirrors the actual approval chain in UAE HEIs: data flows from Program Directors → College QA Chair → College Dean → University QA Chair → (finally) University Admin for submission to MoHESR.
  • The System Administrator configures the workflow but never approves data, and MoHESR Officers have read‑only visibility for independent verification.
  • Every action — from data entry to final approval — is recorded in the audit_log table, ensuring full traceability for certification audits.

“The BRASS OBF platform transformed our compliance process from a quarterly scramble into a continuous, managed workflow with complete audit transparency.” — Al Ain University compliance team

5. Lessons Learned

Modular architecture is essential at this scale. The platform grew from an initial brief of ~3,000 lines to 10,000+ over nine sprint cycles. Without Shiny module isolation from Sprint 1, the codebase would have become unmanageable. Every major feature area has its own module namespace.

Connection pooling is non-negotiable in multi-user Shiny. SQLite without pool would produce connection exhaustion errors under concurrent institutional use. The pool package with a minimum pool size of 2 and maximum of 10 connections resolved all stability issues.

Security must be in the architecture, not the afterthought. Parameterised queries, environment-variable secrets, and RBAC were designed in from Sprint 1. Retrofitting these after build would have required a complete rewrite.

Bilingual UIs require deliberate CSS strategy. Mixing RTL Arabic text with LTR English content requires explicit direction: rtl / dir attribute management and careful font loading. Cairo and Noto Sans Arabic were selected after testing five Arabic web fonts for rendering quality in bslib Shiny.

6. Technical Specification Summary

Attribute Value
Primary Language R 4.x
Framework R Shiny 1.8+ with bslib
Database SQLite 3.x via DBI / RSQLite
Authentication Custom RBAC + TOTP-based MFA
Deployment shinyapps.io
Report Output LaTeX → PDF (via R Markdown)
Localisation English + Arabic (Cairo / Noto Sans Arabic)
Lines of Code 10,000+ (R Shiny, R Markdown, SQL, LaTeX)
Platform Version v9.5.1
Compliance Standard MoHESR OBF Guidebook v11.5 (23 March, 2026)
Compliance Result 100% — Certified

Interested in a Platform Like This?

🤝 Request a Consultation 🔧 View Services

Back to top