Understanding the MoHESR OBF Framework: A Developer’s Guide

What the OBF Guidebook v11.5 (23 March 2026) actually requires — and what that means in code

Compliance
OBF
MoHESR
UAE Higher Education
A technical walkthrough of the OBF Guidebook v11.5 structure, KPI pillar architecture, and what ‘compliance’ actually means when you’re building the platform. From the team that built the first comprehensive OBF monitoring platform.
Author

BRASS Digital Lab

Published

3 April 2026

Introduction

If you are building compliance software for a UAE higher education institution, the MoHESR Outcome‑Based Evaluation Framework (OBF) is the most important regulatory document you will read. And it is genuinely complex — structured around 6 performance pillars and 24 KPI indicators, with specific evidence requirements, rolling‑average timeframes, survey sampling protocols, and a clear separation between institutional and programmatic scoring.

This post is written for R developers and institutional data teams who need to understand what the OBF framework actually requires — technically, structurally, and in terms of the data you must capture. It draws directly on our experience building and certifying the OBF Compliance Monitoring Platform for Al Ain University.

Tip

Prerequisite: This post assumes familiarity with the MoHESR OBEF Guidebook v11.5 (23 March 2026). Everything described here reflects the current v11.5 requirements.

1. What the OBF Framework Is (and Isn’t)

Designed to support UAE Vision 2031 and a knowledge-based economy, the Outcomes-Based Evaluation Framework (OBEF),launched by the Ministry of Higher Education and Scientific Research (MoHESR) in 2024, marks a fundamental reorientation from input-focused metrics—such as infrastructure and resources—to measurable outputs including graduate employability, research impact, and societal value. Indeed, in addition to emphasizing 24 KPIs, multi-year rolling averages, and risk-based licensing and accreditation, the MoHESR’s OBEF organizes institutional performance across six weighted 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. While these latest requirements are excluded from the official OBEF score and do not affect the 24-KPI institutional or programmatic scorecard, they are presented as forward-looking, non-compliance elements designed to support institutional innovation beyond the core OBF metrics.

What OBF is: - A KPI performance scoring system across 6 pillars - A continuous, periodic reporting obligation - An evidence-based framework — every KPI value must be supported by documented proof (surveys, master API extracts, Scopus/SciVal data) - A relative comparison mechanism (scores are normalised against KPI‑specific thresholds)

What OBF is not: - A simple checklist - A one-time certification - A system you can satisfy with spreadsheets at submission time (if you want to sleep)

2. The Six KPI Pillars (V11.5)

The OBF framework organises all performance requirements into six pillars. From a platform architecture perspective, these pillars map naturally to data domains — each requiring its own collection forms, validation logic, and reporting outputs.

OBF v11.5 — Six KPI Pillars, weights, and KPI counts
OBF v11.5 Pillar Summary
Pillar KPI Count (v11.5) Typical Data Sources
Employment Outcomes ~2 Graduate Destination Survey (GDS), MoHRE data
Learning Outcomes ~6 Assessment quality reviews, retention rates, employer surveys, micro‑credentials, student satisfaction
Industry Collaboration ~4 Work placement records, joint industry courses, industry contributions (AED)
Research Outcomes ~6 Scopus/SciVal publications, FWCI, joint industry research, student research participation, impact, IP
Reputation ~4 Global rankings, international accreditation, dual/joint degrees, international research collaboration
Community Engagement ~2 Academic events, community initiatives

3. What “Compliance” Actually Means in Code

This is where most developers get confused. The OBF framework doesn’t just require you to store data — it requires you to:

  1. Calculate KPI values correctly according to specified formulae, respecting rolling‑average timeframes (3‑year, 5‑year, or cumulative sums)
  2. Evidence each claim with supporting documentation (surveys, API extracts, certificates)
  3. Workflow each submission through defined approval stages
  4. Reporting in a specific MoHESR‑specified format (via the future master API or HEDB portal)
  5. Audit — every value, every change, every approval must be traceable

3.1 KPI Calculation Logic

Each KPI has a defined timeframe: - Rolling 3‑year average (e.g., Employment Rate, Retention Rate, Work placement KPIs) - Rolling 5‑year average (most Research KPIs: Publication Ratio, FWCI, Joint Industry Research) - Last year’s performance (Assessment Quality Review, Global Rankings, International Accreditation) - Cumulative sum over 5 years (Joint Industry Research total, IP awarded)

For example, KPI 1.1 Employment Rate (%) is calculated as:

# KPI 1.1 Employment Rate (%)
# Formula: (Employed or in further education 12 months after graduation) / (Total graduates in same cohort)
# Timeframe: Rolling 3‑year average across academic years

calculate_employment_rate <- function(employed_numer, total_grads_denom) {
  if (total_grads_denom == 0) return(NA_real_)
  round((employed_numer / total_grads_denom) * 100, 2)
}

# Rolling 3‑year average logic in R
kpi_data %>%
  group_by(institution_id, academic_year) %>%
  arrange(academic_year) %>%
  mutate(
    employment_rate_3yr_avg = zoo::rollapplyr(
      employment_rate_raw, width = 3, FUN = mean, fill = NA, align = "right"
    )
  )

The critical point: KPI formulae, denominator definitions, and timeframes are defined in the Guidebook V11.5, and you must implement them exactly. Special cases exist, e.g., for health professions where compulsory post‑graduation internships extend the employment calculation period.

3.2 Evidence Requirements

Every KPI value submission must link to supporting documentation. MoHESR distinguishes between centrally collected data (GDS, SES, Scopus) and institution‑submitted evidence (master API, surveys, certificates). In a compliant platform, evidence is mandatory for all self‑reported KPIs.

In the OBF platform, we implemented evidence as a separate relational entity:

# Evidence linked to KPI submissions (R Shiny / pool example)
observeEvent(input$evidence_upload, {
  req(input$evidence_upload)
  req(input$selected_kpi_submission_id)
  
  file_info <- input$evidence_upload
  
  pool::dbExecute(conn,
    "INSERT INTO evidence_files 
     (submission_id, original_filename, file_type, file_size_kb, uploaded_by, uploaded_at)
     VALUES (?, ?, ?, ?, ?, datetime('now'))",
    params = list(
      input$selected_kpi_submission_id,
      file_info$name,
      tools::file_ext(file_info$name),
      round(file_info$size / 1024, 1),
      session$userData$user_id
    )
  )
})

3.3 The Audit Trail Requirement

Every OBF platform must maintain a complete audit trail. In practice this means:

  • Every KPI value change is logged with previous value, new value, changed_by, and changed_at
  • Every workflow stage transition is timestamped and attributed
  • Evidence uploads are non‑deletable (only superseded)
  • Report generation runs are logged with the data snapshot used

We implemented this as a single audit_log table with JSON-encoded before/after snapshots:

log_audit_event <- function(conn, user_id, action, entity_type, entity_id,
                             before_json = NULL, after_json = NULL) {
  pool::dbExecute(conn,
    "INSERT INTO audit_log 
     (user_id, action, entity_type, entity_id, before_state, after_state, logged_at)
     VALUES (?, ?, ?, ?, ?, ?, datetime('now'))",
    params = list(user_id, action, entity_type, entity_id,
                  before_json, after_json)
  )
}

4. Database Design for OBF Compliance (V11.5)

A well‑designed OBF database schema must accommodate 24 KPIs, both institutional and programmatic levels, and the various data collection methods (surveys, master API, Scopus/SciVal). From experience, these are the essential tables:

kpi_pillars          — 6 pillars (Employment, Learning, Industry, Research, Reputation, Community)
kpi_indicators       — All 24 KPI definitions, with formulae, timeframes, weights, and level (institution/program)
kpi_submissions      — Term‑level submissions (one per indicator per institution/program per period)
kpi_values           — Calculated values and raw inputs (e.g., numerator, denominator)
evidence_submissions — Evidence package per KPI submission
evidence_files       — Individual files (PDF, CSV, certificates, survey exports)
workflow_stages      — Stage definitions (Draft → Under Review → Approved → Certified)
workflow_audit       — Stage transitions with timestamps and actors
survey_responses     — Raw survey data (GDS, ESS, SES, EWS) for auditability
report_runs          — Record of every generated report (including data snapshot)
audit_log            — Full change history for all mutable records

The relationship between kpi_submissions and evidence_submissions is one-to-one. The relationship between evidence_submissions and evidence_files is one-to-many. This design allows for the replacement of an entire evidence package without deleting file records. For KPIs collected centrally by MoHESR (e.g., Employment Rate via GDS, FWCI via SciVal), your platform must still be able to ingest the official scores and link them to local evidence for cross‑validation.

5. Common Implementation Mistakes

After building and certifying OBF platforms against v11.5, these are the most frequent errors we see:

Mistake 1: Ignoring rolling‑average logic Several KPIs require 3‑year or 5‑year rolling averages. Storing only the current year’s value without historical cohort data will break compliance. Always store the underlying annual numerators and denominators.

Mistake 2: Mis‑handling program‑level vs institution‑level Some KPIs (Impact of Research, Awarded IP) are institution‑only. For others, programmatic weights are redistributed (see Guidebook page 7). Your schema must support both aggregation levels and weight redistribution rules.

Mistake 3: Not supporting small‑population sampling guidelines For programs with fewer than 70 students, MoHESR allows merging of similar programs or a 50% sample. Your platform must implement the sampling logic described in Appendix C (pages 73–77) and flag when samples are used.

Mistake 4: Overlooking evidence for “centrally collected” KPIs Even when MoHESR administers a survey (e.g., GDS, ESS), the institution must ensure adequate response rates. Your platform should track response rates and allow upload of follow‑up evidence (e.g., student contact lists, reminder logs).

Mistake 5: No support for the “Future Readiness” label (optional but strategic) Although excluded from the OBF score, the separate Future Readiness assessment (Future Skills Alignment + AI‑Enabled Teaching & Learning) is increasingly important. Build modular extensions to accommodate it.

Conclusion

The MoHESR OBF framework v11.5 is demanding precisely because it requires that compliance be demonstrated rather than asserted — with 24 KPIs, six pillars, rolling averages, evidence trails, and distinct institutional/programmatic weights. Certified platforms are those built around the framework’s data structures, calculation rules, and audit requirements from the first sprint — not the ones that try to retrofit compliance to an existing data tool.

If you are building an OBF compliance platform for v11.5 and want to discuss the architecture, get in touch.

📧 brassbe1982@gmail.com · 🤝 Request a consultation

Back to top