WF-23 — Academic and Community Event Lifecycle

This is the cheapest five points in the framework and it should be running before anything else in this pilot. KPI 6.1 tops out at four qualifying academic events a year at programme level. KPI 6.2 is a binary at two community events a year, and a volunteering initiative qualifies with five participants and one hour. No curriculum change is needed, no governance approval is needed, and no improvement in educational quality is needed. What is needed is a register that an organiser fills in before the event, and a sign-in sheet at the door. IoL almost certainly clears both anchors already and cannot prove it, which scores the same as not doing it at all.

Two rules carry most of the risk. A faculty-only event does not count, so an event that is not at minimum open to student attendance is worth nothing under KPI 6.1 however substantial it was. And each event type has a minimum attendance, so an event below its minimum is excluded rather than rounded up. Both facts are knowable at planning time, which is the entire design idea below.

1. Purpose

To ensure that every academic and community event IoL organises, co-hosts or hosts is registered before it takes place with its type, duration, openness to student attendance and linked programme codes declared; that the attendance which determines whether it qualifies is counted at the event itself rather than estimated afterwards; and that the evidence pack the Ministry may demand without notice, being promotional material, proof of attendance with attendee names, hosting approvals and participant feedback, exists for every counted event on the day it finishes rather than being assembled under deadline months later.

2. Scope

Scope statement. This process manages academic and community events from the point at which an event is first proposed, through pre-event qualification against the OBEF type minima, delivery, attendance capture and evidence lodgement, to classification, programme attribution and the annual roll-up into Institute - Events.xlsx.

Applies to. Every event organised, co-hosted or hosted by IoL, whether led by staff, by learners or by a university club or society. On the academic side this includes conferences, seminars, workshops, lecture series, journal clubs, panel discussions, webinars, symposia, research days and skills competitions at local, regional and international level (Emirates Skills, Asia Skills, WorldSkills). On the community side it includes educational programmes for community groups, volunteering initiatives, free upskilling courses, cultural events and public lectures. It applies to events delivered jointly with Dubai Health entities, professional associations, schools, community organisations and international partners, where IoL holds an organiser, co-host or host role.

Does not apply to. Events at which IoL is only an attendee, a delegate or a sponsor without an organising role, because the CHEDS HEI's role value must be organiser, co-host or host. Faculty-only meetings, committee meetings, examination boards, staff away days and internal administrative briefings, which are excluded from KPI 6.1 by the open-to-students rule and are not community events either. The academic delivery lifecycle of CPD and CME activity, which is WF-21; this workflow receives event candidates from it and registers them, and the two must not both submit the same activity independently. The commercial and contractual side of a co-hosted event, which is WF-24. Research impact arising from an event, which is WF-19; this workflow supplies the public-reach evidence and WF-19 decides whether an impact unit exists.

A boundary IoL must set for itself, flagged as a judgement rather than a rule. The guide does not state that timetabled curriculum delivery is excluded from KPI 6.1. A scheduled class on a study plan is nevertheless not an "academic event" in any ordinary reading, and counting the teaching timetable as events would be indefensible on the first question asked. This workflow therefore excludes timetabled credit-bearing sessions from KPI 6.1 and records the exclusion as a documented IoL reading, so that the decision is visible rather than tacit. Where a session is genuinely open beyond the enrolled cohort, is advertised, and would run whether or not the cohort attended, it may be registered as an event on its own merits.

Applicable requirements. OBEF guide v11.5 KPI 6.1 and KPI 6.2, their Appendix A threshold anchors and their Appendix B evidence provisions; CHEDS Institute - Events.xlsx and the HEDB lookups EventType, Event Category, Event Size, Event Frequency, Event Role and Audience; CHEDS Master API specification 18 February 2026, submission fields OBF6.1.N, OBF6.1.D, OBF6.1.R, OBF6.1M, OBF6.2.N, OBF6.2.D, OBF6.2.R, OBF6.2M; MBRU events, branding and communications policy [IoL to confirm]; venue and public-event licensing requirements applicable in Dubai [IoL to confirm which authority and which event categories require an approval record]; MBRU data protection policy as it applies to attendee names and contact details.

The definitions that govern everything below. Three things decide whether an event scores, and all three are fixed before the event happens.

First, the role. The event must be organised, co-hosted or hosted by MBRU or the programme. Attendance at somebody else's event does not count, whatever IoL contributed to it.

Second, for KPI 6.1, the audience. The event must at minimum be open to student attendance. A faculty-only event is a hard exclusion. Note the wording carefully: the test is that students may attend, not that a stated number of students did. This is the single easiest condition in the framework to satisfy and the single easiest to fail by omission, because most faculty development activity is scheduled as faculty-only out of habit rather than by design.

Third, the type-specific minimum attendance and duration. Every event type requires at least one hour, and each carries its own participant minimum.

Fourth, and it is a rule about the register rather than about the event: an event counts under either 6.1 or 6.2, never both. The classification is made once, by rule, at Event Main category level, and is enforced as a mutual exclusion. This is cross-KPI assertion C5.

A multi-programme event may be counted by every programme it is linked to. An event tagged to both PGDipHPE and MScHPE counts once for each at programme level, and once at institution level. This is not a loophole; it is stated in the guide and it doubles the effective yield of every event IoL runs for both cohorts.

3. Trigger, boundary and endpoint

4. SIPOC

5. Accountability

Process owner. IoL Director of Engagement, or the role able to commit IoL to hosting an event, to require pre-event registration as a condition of using IoL's name and budget, and to resolve a classification dispute between the academic and community categories.

R responsible · A accountable · C consulted · I informed. One A per row.

Escalation.

6. Process steps

1. Register the event before it happens. No event may use IoL's name, budget or venue booking without a register row. The row is opened at proposal, not at completion. [CAPTURE] proposed Event Name, Event Description, organiser, proposed Start Date and End Date, Venue, City, Country, HEI's role. Serves 6.1 and 6.2. This step is the workflow. Everything else is detail. An event registered afterwards can usually be evidenced only by memory, and memory is not evidence.

2. Classify the event type and run the qualification check. The register selects a type from the HEDB EventType and Event Category vocabularies and immediately displays the minimum attendance and the minimum duration for that type. [CAPTURE] Event Main category, Event SubCategory, Event Type, planned Event duration, Frequency. Serves 6.1 and 6.2. Decision point. If the expected attendance is below the type minimum, the organiser sees it now and has three options: increase the reach, change the type (a gathering of eighteen people is not a seminar at 50 but is a workshop at 15), or accept that the event will not count and proceed anyway because it is worth running. All three are legitimate. What is not acceptable is discovering the shortfall at submission time, when nothing can be done.

3. Confirm the event is open to student attendance, and record it honestly. [CAPTURE] Open_to_students as Y or N, Targeted Audience, Audience Type from the HEDB Audience lookup. Serves 6.1. Decision point. If the answer is N, ask why. For most academic events at IoL there is no substantive reason a learner could not attend, and the default of faculty-only is habit rather than design. Changing the default converts existing invisible activity into a qualifying event at no cost. Where the answer is genuinely N, for example a closed examiner meeting, the event is registered with Open_to_students = N and is never counted under 6.1. Do not set the flag to Y for an event that was in fact closed. The Ministry may demand attendee names, and a faculty-only attendee list against an open-to-students flag is the fastest way to lose credibility on a pillar MBRU currently scores well in.

4. Confirm the linked programme codes. Tag every programme for which the event is relevant. [CAPTURE] Program codes, Department, College. Serves 6.1 and 6.2 at programme level. A multi-programme event may be counted by all relevant programmes. For IoL this means an event relevant to both PGDipHPE and MScHPE is tagged to both and counts for both. Untagged events count at institution level only, and the 5.0 percentage points at stake here are programme-level points. An untagged event is half an event.

5. Obtain and file the venue booking and any hosting or licensing approval. [CAPTURE] approval reference and issuing body. Serves the Appendix B evidence requirement, which names official approval records for hosting from the venue or the licensing authority. IoL should establish once, with MBRU Events, which categories of event require a formal approval record in Dubai and which do not [IoL to confirm]. Where none is required, record that finding rather than leaving the field empty, so a future evidence request meets an answer instead of a gap.

6. Promote the event and retain the promotional material. [CAPTURE] copies of the announcement, poster, invitation, web page or social post, lodged in the evidence register at the time of publication. Serves the Appendix B evidence requirement for media material and publications promoting the event. Promotional material is trivially available on the day and surprisingly hard to recover eighteen months later after a website refresh. Lodge it when it is published.

7. Open registration and record the registration and pricing basis. [CAPTURE] Registration, Ticket Price, Scope. Serves 6.2, where a free upskilling course requires a Ticket Price of zero.

8. Deliver the event and record the actual duration. [CAPTURE] actual Start Date, End Date and Event duration. Serves 6.1 and 6.2. Duration is a qualification criterion, not a descriptive field. An event of fifty minutes does not meet the one-hour minimum for any type.

9. Capture attendance at the event, by registration or sign-in. [CAPTURE] Number of Attendees and the attendee list with names. Serves 6.1 and 6.2, and the Appendix B evidence requirement, which names proof of attendance including the number of attendees and their names. This is the step that separates five points from nothing. "About sixty people came" is not evidence. Use whatever mechanism suits the event, being a registration platform, a QR sign-in, a paper sheet photographed at the end, or the attendance export from the webinar platform, but capture it at the event and capture names, because the Ministry is entitled to ask for them. Attendee names are personal data and are held under the retention and access rules in section 11. Exception route. For an event where names genuinely cannot be captured, such as a public health-awareness stand in a mall, record the counting method used, the counter's name and the count, and treat the weaker evidence as a known limitation of that event rather than pretending it is a sign-in sheet.

10. Collect participant feedback. [CAPTURE] the feedback instrument, the responses and the satisfaction summary. Serves the Appendix B evidence requirement, which names documentation of event feedback and participant satisfaction. A three-question form at the close of the event is sufficient. The requirement is that documentation exists, not that it is elaborate.

11. Close the register row within ten working days and lodge the evidence pack. [CAPTURE] the completed row plus pointers to promotional material, approval record, attendance record and feedback documentation. Serves assertion C14, which requires every Y flag driving a numerator to have a retrievable evidence artefact. Decision point. If actual attendance is below the type minimum, mark the row non-qualifying with the reason. It stays in the register. Deleting it is a data-integrity failure and it also destroys the denominator IoL needs in order to know its own qualification rate.

12. Classify the event as KPI 6.1 or KPI 6.2, once, by rule. The classification is made at Event Main category level against a written rule, not case by case. [CAPTURE] the classification and its basis. Serves assertion C5, the mutual exclusion. The rule IoL should adopt: an event whose primary audience is the academic community, including students, and whose primary purpose is scholarly or educational exchange on a research or professional topic, is 6.1. An event whose primary audience is a community beyond MBRU staff and students, and whose primary purpose is social benefit, is 6.2. Where an event is genuinely both, for example a public research symposium open to a patient community, the classification is made once and recorded, and it does not change between years.

13. Attribute to programme codes and expand multi-programme events at roll-up. [CAPTURE] one register row per event, expanded into per-programme attributions for the programme-level count. Serves 6.1 and 6.2 at programme level.

14. Roll up annually and reconcile to Institute - Events.xlsx. Produce the institutional count, the programme-level counts, and the KPI 6.2 programme binary. Hand to WF-26 with the classification rule and the reading applied to the "at least two" question recorded for OBF6.2M. Reconcile the register against three independent sources: the venue booking log, the marketing and communications activity log, and IoL's own budget expenditure on catering and materials. Each of these three catches events the register missed, and the gap between them and the register is the workflow's own completeness measure.

7. OBEF data generated

Capture rule. Five things cannot be reconstructed after the event and must be recorded while it is happening or before it starts: the attendance count with attendee names, the actual duration, the promotional material as published, the hosting or venue approval record, and the open-to-students status as it actually was. Everything else in this table can be recovered from a diary, an invoice or a website. These five cannot, and four of the five are exactly what Appendix B names.

Reproducibility test. A second analyst can reproduce the KPI 6.1 count by filtering the event register on HEI's role in organiser, co-host or host; Open_to_students = Y; Event duration of at least one hour; and Number of Attendees at or above the minimum for the recorded Event Type. The KPI 6.2 count uses the same filter with the community categories and their own minima, and the programme binary is a count of two per Program code per year. The test is passed only if the register exists. Today IoL has no single register that every organiser posts to [IoL to confirm], which means the current answer is no, and the capture defect is the absence of the register itself rather than any defect in the fields.

8. Max-score design

Two features of the anchors that change how the target should be set.

Both KPIs are three-year rolling averages of a count. Four qualifying academic events in one year does not score 100 if the preceding two years produced one each. The average is what is scored, so the target is four a year sustained, and a strong single year cannot rescue a weak series. This is an argument for starting now rather than starting in the submission year, and it is the only respect in which this otherwise cheap KPI punishes delay.

The KPI 6.2 programme binary interacts with 6.1. If a programme does not achieve its community events, the 2% weight is reassigned to KPI 6.1, so all 5% of Pillar 6 rests on academic events for that programme. That is designed protection rather than a penalty, but note what it means in practice: a programme that achieves 6.2 gains 2.0 points and simultaneously reduces the weight sitting on 6.1. The score maximisation plan models exactly this and shows KPI 6.1 apparently "losing" 2.0 points between scenarios for that reason. Redistribution is reallocation, not free money, and a programme with genuine community activity is always better off claiming it directly.

What this workflow must do to reach the target.

1. Stand up a single IoL event register that every organiser posts to before the event, with the type minima enforced at the point of planning. This is register R8 in the institutional pack and it is the whole workflow. Until it exists, every other action here is theoretical.
2. Enforce the qualification check at planning. The organiser must see, before promotion opens, whether the event will qualify at the expected attendance, and must be able to change the type or the reach while there is still time to do either.
3. Capture attendance at the event, with names, by registration or sign-in. Never estimate. Never reconstruct. The number and the names are both demandable under Appendix B.
4. Change the default on faculty development from closed to open. Most of IoL's faculty-facing academic activity has no substantive reason to exclude learners, and opening it converts existing invisible activity into qualifying events at zero cost.
5. Tag every event to every programme code it is relevant to. An untagged event scores at institution level only and forfeits the programme-level points that are the object of this pilot.
6. Set the 6.1 versus 6.2 classification rule once, in writing, and hold it. Assertion C5 is a mutual exclusion and a shifting classification produces a series that cannot be explained.
7. Reconcile the register annually against venue bookings, the communications activity log and catering expenditure, and treat the difference as the register's own completeness measure rather than as an administrative irritation.
8. Plan the annual event calendar against the anchors at the start of the year, not against them at the end. Four academic and two community events per programme code is a planning input, and it is a modest one for a department of IoL's activity level.

[REDESIGN] actions.

The event-shape rule, which is R4 and which is worth stating on its own. A lecture series counts as one event, requires at least six lectures in the academic year, and needs an average of 20 attendees per lecture. Six individually registered seminars count as six events but each needs 50 attendees. The decision therefore turns entirely on expected per-session attendance:

• Expect 50 or more per session: register each session as an individual seminar. Six sessions become six countable events and clear the programme anchor of four on their own.
• Expect 20 to 49 per session: bundle six or more sessions into a formally constituted lecture series. It counts as one event, which is far better than six events that each fail the seminar minimum and count as nothing.
• Expect 15 to 19 per session with a practical, participatory format: register as workshops, whose minimum is 15, and each session counts individually.
• Expect fewer than 15: the event will not qualify under any academic type. Run it if it is worth running, register it, and flag it non-qualifying. Do not reclassify it into a type it does not fit.

This is a design choice about how activity is packaged and labelled, made honestly and in advance, on the basis of what the event actually is. It is not a reclassification of an event after the fact to reach a threshold it missed, which section 9 rules out explicitly.

Sequencing note. R1, R2 and R3 together cost approximately one month of one coordinator's attention and are worth the full 5.0 points at programme level. Nothing else in this pilot has that ratio. They require no curriculum governance decision, no CAA involvement and no budget. They should be running before the [REDESIGN] actions in WF-13 and WF-22 have even reached committee.

9. Indirect strategy where data cannot be collected

Category 4 overwhelmingly, with a narrow and honest Category 3 case at the KPI 6.2 programme binary.

Category 4, the activity exists but is invisible. This is the dominant case and it is most of the opportunity here. IoL sits inside Dubai Health, an academic health system whose staff run clinical outreach, health-awareness days, school visits, screening camps, patient education sessions, public health talks, world-day awareness campaigns and volunteering drives as a matter of routine. A large proportion of this activity already satisfies the KPI 6.2 definition on its face: it is organised by, or in partnership with, the institution; it targets a community beyond MBRU staff and students; it aims at social benefit; and it comfortably exceeds five participants and one hour. It counts for nothing, because nobody registers it anywhere that reaches Institute - Events.xlsx.

The same is true on the academic side. Journal clubs, research seminars, faculty development sessions, guest lectures by visiting clinicians and educators, dissertation showcases and teaching-improvement workshops happen continuously and are recorded, if at all, in a calendar invitation. Two things stop them counting: no register row, and, for the faculty development strand, a faculty-only default that has no substantive justification.

The response to Category 4 is capture, not tactics. There is no clever reading to find here. R1, R2 and R3 are the entire strategy, and they are process changes rather than interpretive ones. The specific instruction to IoL is to run a one-off retrospective sweep of the last twelve months across the diary, the venue booking log, the communications activity log and catering expenditure, to establish how many qualifying events actually occurred. That sweep will not produce submittable numbers, because the attendance evidence does not exist, and it must not be used to populate a submission. Its purpose is to size the gap and to make the case for R1 with a number rather than an assertion.

Category 3, the activity genuinely does not exist, applies only to the KPI 6.2 programme binary. If a programme genuinely organises fewer than two community events in a year, the guide reassigns the 2% weight to KPI 6.1 so the programme is not penalised. That is the designed outcome and using it correctly is not avoidance. For IoL it should be a temporary state at most, because R6 makes two qualifying volunteering initiatives a year an afternoon's work rather than a programme of activity, and because a programme with genuine community activity always scores better claiming it directly than triggering redistribution.

Category 2 does not apply. Both KPIs are Track A counts computed from records rather than surveys, so there is no Appendix C sampling question and no small-population threshold. Cohort size is irrelevant here, which is unusual in this pilot and is part of why these five points are so cheap.

Category 1 does not apply. MBRU submits both KPIs itself.

Category 5, performance genuinely low, is not a plausible reading for IoL before R1 has run for a year. A count of zero today measures the absence of a register, not the absence of events. Reporting it as a performance gap would be a misdiagnosis of exactly the kind the institutional pack's corrective-action loop is designed to prevent.

Three ambiguities in the guide, flagged rather than resolved.

First, "at least two" against "more than two" at KPI 6.2. The scorecard says a programme organising at least two community events per year scores 100. The note at Appendix A says more than two. Appendix A's own threshold value is 2. Two of the three readings agree on a threshold of two, and the threshold value is the operative number. This workflow uses "at least two", targets three or four so the distinction cannot bite, and records the reading in OBF6.2M. Raise the inconsistency with MoHESR in writing. Targeting above the ambiguity is cheaper than resolving it.

Second, whether the three-year rolling average applies to the KPI 6.2 programme binary, and if so how. The KPI is described as a three-year rolling average and simultaneously as a Yes or No on organising at least two community events per year. Whether the binary is evaluated per year and then averaged, evaluated on the three-year average count, or evaluated on the latest year alone is not stated. The safe design is to achieve two or more in every year, which satisfies all three readings, and that is what R5 sets. Record the point in OBF6.2M.

Third, whether the open-to-students exclusion extends to KPI 6.2. The exclusion is stated for KPI 6.1, where the audience test is central. KPI 6.2 events by definition target communities beyond MBRU, and a volunteering initiative or a public lecture for a community group may have no student attendance at all. Do not assume the 6.1 exclusion transfers. Populate Open_to_students truthfully for every event regardless of category, so that whichever reading the Ministry applies, the register supports it. This costs nothing and removes a risk.

Boundary check. This workflow must never:

• record an estimated attendance figure, or a number recalled after the event, as Number of Attendees;
• set Open_to_students = Y for an event that was in fact closed to students;
• count an event under both KPI 6.1 and KPI 6.2;
• reclassify an event's type after the event in order to bring its actual attendance above a minimum it missed, which is distinct from choosing the right type honestly in advance under R4;
• count each lecture of a lecture series as a separate event;
• count an event at which IoL was an attendee, a delegate or a sponsor rather than an organiser, co-host or host;
• count a timetabled credit-bearing teaching session as an academic event under the reading recorded in section 2;
• count a faculty-only event under KPI 6.1;
• count an event of less than one hour under either KPI;
• delete a non-qualifying event from the register instead of flagging it, since the register's own qualification rate is a performance measure and deletion destroys it;
• describe an event as organised in partnership with a community organisation where no agreement or documented arrangement exists, which WF-24 owns;
• claim a community-benefit purpose that the event's own description and promotional material do not support;
• change the 6.1 against 6.2 classification of a recurring event between years without recording the change and its effect on both three-year series;
• treat the retrospective sweep described above as a source of submittable attendance figures.

10. Service standards

11. Records and evidence

Appendix B readiness. Today, IoL could probably produce promotional material for its larger events and could reconstruct approximate dates and topics from calendars. It could not produce, for any past event, an attendance record with names, a duration record, a hosting approval reference and a feedback summary as a coherent pack within 15 working days [IoL to confirm]. KPI 6.1 and 6.2 are the pillar MBRU currently scores best in, at 4.1 of 5, which makes this the most exposed position in the whole pilot: a claimed number with thin evidence behind it is a worse position than an unclaimed one, because it invites a restatement rather than a gap. R1 and R2 close it, and they are the two cheapest actions in the pack.

A data protection note that is easy to skip and should not be. Attendee names, and in most cases attendee emails and organisations, are personal data about people who are frequently not MBRU staff or students, including members of the public at community events. Collect the minimum necessary, tell attendees at sign-in what the data is used for and that it may be provided to the regulator, apply role-based access to the attendee lists, and retain them under the MBRU retention schedule rather than indefinitely. The Ministry's entitlement to demand names is a reason to hold them properly, not a reason to hold them loosely.

12. Risks and controls

13. Performance measures

The first two measures are the ones that decide the score. Every other measure in this table describes an event programme that could be excellent and score nothing.

14. Change control