WF-26 — OBEF Data Assembly, Validation and Local Submission

This workflow receives from the other twenty-five and hands one pack to MBRU's institutional OBEF process. IoL does not submit to CHEDS. MBRU does. What IoL submits is a departmental pack, per programme code and per contributing institutional KPI, that the institutional Track A Lead can use without re-deriving anything and without asking anyone what a number means.

Three things make this workflow worth its own document rather than being a step at the end of the others. First, the null check: a null passes CHEDS schema validation silently and then scores nothing, so no Track A KPI is ever submitted null and every withheld KPI carries a documented decision. Second, the sign-off separation: the person who calculated a value does not sign its validation, which is the only structural protection this pilot has against a reporting process drifting into advocacy for a favourable number. Third, the twenty-four Mechanism of collecting the data free-text fields, which are the only place in the entire submission where IoL can state a methodological choice, and which are therefore the difference between a defensible decision and an audit finding.

The pilot's own success criterion runs through here. The charter says every programme-level KPI must have a value a second analyst can reproduce from records alone. This is the workflow that tests that claim, once a year, on all twenty-two of them.

1. Purpose

To ensure that every OBEF value IoL contributes, at programme level for PGDipHPE and MScHPE and as an input to MBRU's institutional submission, is calculated from a named source on a stated basis, validated independently of the person who calculated it, accompanied by a written statement of every methodological choice it rests on, evidenced to the standard Appendix B permits the Ministry to demand without notice, and released only after an explicit decision has been taken about anything that cannot meet those conditions, so that the score MBRU reports for IoL is one IoL can explain, defend and reproduce next year.

2. Scope

Scope statement. This process manages the annual OBEF data cycle for IoL from the opening of the assembly calendar, through collection from the twenty-five producing workflows, calculation, per-KPI validation, the fourteen cross-KPI assertions, KPI owner sign-off, waiver and withhold decisions, mechanism field population and pack release to MBRU's institutional process, to dashboard reconciliation and the handover of below-target KPIs to corrective action planning.

Applies to. All twenty-two programme-level KPIs for both IoL programme codes; every institutional KPI to which IoL contributes data, principally 2.5, 3.4, 4.5, 4.6, 6.1 and 6.2; the mechanism-field statements for every KPI IoL touches; the evidence register index for IoL's claims; and the departmental portion of any Ministry evidence request.

Does not apply to. The CHEDS submission itself, which is MBRU's institutional process and is out of IoL's scope by the charter. The Master API payload assembly, the schema check against OBF Self Report.xlsx and the CHEDS transmission, all of which sit with the institutional Track A Lead. The design or administration of any Ministry instrument. The production of any individual KPI value, which belongs to the workflow that owns it; this workflow validates, challenges and assembles but never recalculates a value in order to make it pass. Corrective action planning itself, which is WF-04; this workflow classifies and hands over.

Applicable requirements. OBEF guide v11.5 in full, including Appendix A anchors, Appendix B evidence provisions and Appendix C sampling rules; ../OBEF Pipeline/01_KPI_Specification_Register.md, which is the authoritative internal definition of every KPI and its validation rules; ../OBEF Pipeline/02_Workflow_Pack_ISO.md, which defines the institutional cycle this workflow docks into, its SOPs and its service standards; 00_Pilot_Charter_and_Architecture.md section 8, which draws the boundary this workflow enforces; HEDB Data Dictionary 2026 and the CHEDS Master API specification of 18 February 2026; ISO 9001 requirements on documented information, internal audit and management review as MBRU applies them [IoL to confirm the certification scope]; MBRU data governance and records retention policy.

Where this workflow sits in the institutional process. MBRU's OBEF process, as documented in the ISO workflow pack, runs two tracks, with a Process Owner, a Track A Lead, a Track B Lead, KPI Owners, Data Stewards and Quality and IQA. IoL is a contributor to that process, not a parallel one. This workflow's output is an input to institutional stages, and its calendar is derived from the institutional calendar rather than invented. Where the institutional process has an SOP, IoL follows it rather than writing its own: SOP-A-03 for validation and the assertion suite, SOP-B-03 for Appendix C sampling and grouping, SOP-R-03 for event registration, SOP-E-01 and SOP-E-02 for evidence.

3. Trigger, boundary and endpoint

4. SIPOC

5. Accountability

Process owner. IoL Pilot Lead, or the role accountable for the integrity of IoL's OBEF contribution and able to withhold a value against operational pressure to submit it.

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

The separation that matters, stated plainly. The person who calculated a value does not sign its validation, and does not sign the value. In a department of IoL's size the same individual will frequently be the natural candidate for both roles, and the answer is not to relax the rule but to route the second role to Quality and IQA or to a programme director outside the producing workflow. The institutional pack's risk 13 names the underlying hazard: a process whose success is measured by score improvement will, over time, select for favourable interpretations. This separation, the waiver log and the boundary check in section 9 are the three counterweights, and they only work if they are structural rather than voluntary.

Escalation.

6. Process steps

1. Open the cycle file and confirm ownership. For every KPI in scope, confirm a named KPI Owner and a named Data Steward, and confirm that the two are not the same person for any KPI. [CAPTURE] the ownership matrix, dated. Decision point. Where ownership is unassigned, the cycle does not proceed for that KPI. The institutional pack's first immediate action is exactly this, and it is the precondition for everything downstream.

2. Publish the handover schedule to the twenty-five producing workflows. Each workflow's section 7 names what it produces, at which capture point and to which destination. This step converts those into dated obligations for the cycle. [CAPTURE] the schedule and the acknowledgements.

3. Collect values, with their sources and extract dates. For every KPI: numerator, denominator, result, the source system or register, the extract date, and the evidence register pointer. [CAPTURE] the collection record. Serves every KPI, and the mechanism-field requirement to record the source system and extract date for each Track A KPI. Reject a value that arrives without its source and extract date. A number without a provenance is not a KPI value; it is an assertion, and it cannot be reproduced next year by anyone.

4. Calculate and construct the rolling averages. Three-year rolling averages for most KPIs, five-year cumulative windows for 4.3, 4.5, 4.6 and 5.4. [CAPTURE] the calculation working paper. Decision point, and it recurs every cycle. A rolling average requires three distinct cohorts on a constant denominator basis, which is assertion C13. Where a basis has changed, the series is not simply averaged; the change is documented, its effect is stated, and the mechanism field records it. Where a five-year cumulative window is used, confirm against the launch-year register that no project is counted twice, which is assertion C6.

5. Run every per-KPI validation rule from the KPI Specification Register. Record pass, fail or not-applicable per rule per KPI per level. [CAPTURE] the rule-level results. The register is the authoritative internal definition, and any dashboard, extract or submission that disagrees with it is wrong until the register is changed. That includes IoL's own values.

6. Run the fourteen cross-KPI assertions. These catch the errors no single-KPI validation finds. Section 8 sets them out with their IoL-specific readings. [CAPTURE] the assertion results. No pack is released with an unresolved assertion failure. It is either corrected, or explicitly waived with a written reason and the Pilot Lead's approval, and the waiver is counted.

7. Classify every failure into one of three categories, and route it. [CAPTURE] the classification and the routing decision.

   • (a) Data defect, correctable by re-extraction. Routed to the Data Steward, target three working days, per the institutional service standard.
   • (b) Definition ambiguity, requiring a documented methodological decision. Routed to the Pilot Lead, decided with Quality and IQA, and recorded in the mechanism field. This is the category that most often gets resolved informally and then forgotten, which is exactly how a defensible decision becomes an audit finding.
   • (c) Genuine absence of data. Routed to the Pilot Lead for a withhold-or-submit decision, and a corrective action item is opened regardless of which way the decision goes.

8. Obtain KPI owner sign-off on the value, the mechanism statement and the evidence pointer. [CAPTURE] the signature, its date, and what was signed. The KPI Owner is signing three things, not one: that the value is right, that the mechanism statement describes what was actually done, and that the evidence behind it exists and is retrievable. A KPI Owner declining to sign stops the value being submitted until it is resolved, and that is the control working rather than failing.

9. Run the null check as a release gate. For every Track A KPI in scope, confirm that N, D and R are non-null. [CAPTURE] the null-check result and any withhold decision. This is the gate that exists because of a specific technical fact: all KPI fields in the CHEDS dictionary accept null, so an unsubmitted KPI passes schema validation silently and then scores nothing. There is no error, no rejection and no warning. No Track A KPI is ever submitted null. Where a value genuinely cannot be computed, the Pilot Lead records a formal decision to withhold, with the reason, and it becomes a corrective action item. The decision is visible; the null is not. Note the acceptable-range check alongside it, which is assertion C12: percentage KPIs are constrained to 0 to 100, and 2.3.R, 2.4.R and 2.6.R to 0 to 5. A value outside its declared range is a calculation error, not a remarkable result.

10. Write the twenty-four Mechanism of collecting the data statements. [CAPTURE] the statement per KPI, with its author and date. Section 8 sets out what each must contain. These fields are not decoration and they are not optional. They are the only place in the entire submission where IoL can state a methodological choice, and the register's formulation is the one to hold onto: a methodological choice recorded here is defensible under review; the same choice unrecorded is a finding.

11. Assemble and release the IoL pack to the institutional Track A Lead. The pack contains: values per KPI per programme code and per contributing institutional KPI; the validation report; the assertion results; the waiver log; withhold decisions; the mechanism statements; the evidence register index; and the list of confirmed source-material defects for onward transmission to CHEDS. [CAPTURE] the released pack, its version and the acknowledgement. IoL releases a pack; it does not submit to CHEDS. Where the institutional process changes a value IoL supplied, that change is recorded and returned to IoL, because a difference between what IoL supplied and what MBRU submitted is something IoL must be able to explain during dashboard reconciliation.

12. Reconcile the published dashboard against the internal expectation, KPI by KPI. [CAPTURE] the reconciliation, the variance per KPI, and the explanation or escalation for each. Decision point. An unexplained variance is escalated to the institutional Process Owner and, where it appears to originate in CHEDS processing rather than in IoL's data, onward to CHEDS. Do not rationalise a variance. A variance IoL cannot explain is a finding about IoL's own understanding of its data, and it is the most useful thing the dashboard produces. Note the standing caveat: the band-to-score mapping is not published, so any comparison between an internally forecast score and a published score rests on an assumption. Reconcile on the raw KPI values first, where the comparison is exact, and only then on scores, where it is not.

13. Classify every below-target KPI and hand it to WF-04. [CAPTURE] the classification and the handover. Using the institutional pack's three categories:

    • Reporting gap: the KPI was unreported or under-reported. The fix is the register or the capture process, and it belongs to a workflow in this pilot.
    • Data-quality gap: the KPI was reported but wrong. The fix is the source, the extraction or the application of the definition.
    • Performance gap: the KPI was reported accurately and IoL genuinely underperforms. The fix is a real improvement project with an owner outside the reporting function. Classifying honestly is the whole point. MBRU's movement from 45.0 to 63.9 in August 2026 was almost entirely the first category. Treating a reporting gap as a performance gap credits IoL with an improvement it did not make and leaves the capture defect in place for another year.

14. Close the cycle and feed management review. [CAPTURE] the waiver count and its trend, the assertion pass rate, coverage against the twenty-two programme KPIs, evidence-request outcomes, register build progress, and the reproducibility test result. The waiver count trend is a management-review input in its own right. A rising OBEF score with a rising waiver count is a warning, not a success, and this is the workflow that has to say so.

7. OBEF data generated

This workflow produces no KPI value. What it produces is the apparatus that makes every other workflow's values submittable, and that apparatus is itself demandable under Appendix B.

Capture rule. Four things must be recorded at the moment of the decision and cannot be reconstructed credibly afterwards: the methodological decision and its date, because a decision recorded after the result is known is indistinguishable from a decision made after the result is known; the KPI owner signature and what was signed; the waiver, its written reason and its approver; and the withhold decision for any KPI not submitted. The rest of this workflow's output is derived and can be regenerated. These four are the audit trail, and an audit trail written afterwards is not one.

Reproducibility test. The test this workflow applies to every other workflow is also the test it must pass itself: can a second analyst, given the cycle file alone, reconstruct what was decided, by whom, on what basis, and why? Where the answer is no, the defect is in this workflow rather than in the KPI. The practical form of the test is the annual reproducibility measure in section 13, run on a sample of KPIs by someone who did not work on the cycle.

8. Max-score design

This workflow has no KPI and therefore no anchor. Its design target is different in kind: not to lose points that other workflows earned, and to make every methodological choice visible enough to survive review. Three things it does have a target for are stated in the table below, because they are the ways a correctly produced value still fails to score.

The fourteen cross-KPI assertions, with what each means for IoL. These are run every cycle, at both levels, and no pack is released with an unresolved failure.

The twenty-four mechanism-field statements, and what each must contain. The register names five categories of content as the minimum. This workflow expands that into the specific statements IoL must write, because a generic statement satisfies the field and fails the purpose.

The three confirmed defects in the source material, which IoL should raise with CHEDS. These are not IoL's errors and IoL cannot fix them, but IoL is exposed to all three and must carry them forward every cycle until they are resolved.

A fourth item, which is a gap rather than a defect. Appendix C is truncated in the source PDF at "1 of 4". Further small-sample rules exist and are unavailable, and IoL's cohorts are small enough that they matter. Request the complete appendix alongside D3, and treat every sampling determination made before it arrives as provisional and dated.

And a fifth, which is an absence with a planning consequence. No submission deadline appears anywhere in OBEF v11.5. The institutional calendar is constructed from the CHEDS semester and annual submission structure and from the lead times the work requires. Confirm the real dates with CHEDS and replace the assumed calendar, and until then treat IoL's internal dates as derived from an assumption rather than from a published deadline.

The IoL assembly calendar, docked into the institutional cycle. Months are relative to the institutional submission month, which is assumed to be in spring and must be confirmed. IoL's dates sit ahead of the institutional dates by design, because IoL is a supplier to that process rather than a parallel one.

Two things in that table are continuous rather than annual, and the distinction is not administrative. Event attendance and research impact cannot be reconstructed after the fact, and alumni contactability decays. A workflow that treats them as annual tasks will find, each year, that the year is already gone.

What this workflow must do to protect the target.

1. Never release a pack with an unresolved assertion failure. Correct it, or waive it with a written reason and an approval, and count the waiver.
2. Never submit a Track A KPI null. Compute it, or withhold it with a documented decision.
3. Never let a value be signed by the person who calculated it.
4. Write all twenty-four mechanism statements, specifically. A generic statement fills the field and leaves the choice undocumented, which is the outcome the field exists to prevent.
5. Confirm the KPI 2.6 field labelling with CHEDS before the first submission, or KPI 2.6 is submitted into a field that discards it.
6. Reconcile the dashboard on raw values before scores, because the score comparison rests on an unpublished mapping.
7. Classify below-target KPIs honestly into reporting, data-quality and performance gaps, and route performance gaps to an owner outside the reporting function.
8. Report the waiver count and its trend to management review every cycle, whether or not anyone asks.

[REDESIGN] actions.

9. Indirect strategy where data cannot be collected

This workflow has no data of its own to collect, and no category of its own. Its role is to make every other workflow's indirect strategy visible and documented at submission, and to refuse to release anything that cannot be.

The five categories, and what this workflow does about each.

Category 1, the Ministry holds the instrument (2.1, 4.2, 5.1). IoL cannot collect the data. This workflow's job is to ensure the inputs are complete and the claims are recorded: the single-discipline clause claim for 5.1 written into OBF5.1M, the affiliation and ORCID hygiene position for 4.1 and 4.2, and the review-readiness position for 2.1. Where a Track B KPI depends on a claim, the claim is a mechanism statement, not a conversation.

Category 2, the population is too small (1.1, 1.2, 2.3, 2.4, 2.6, 3.1). This workflow enforces the sequencing rule that makes the category legitimate: the Appendix C route and any grouping is signed and dated before any instrument is released, and the substitute-data decision is pre-committed before fieldwork. At validation, this workflow checks the dates, not just the documents. A grouping decision dated after the survey closed is a failure regardless of how reasonable the grouping is, and it is this workflow that has to say so.

Category 3, the activity genuinely does not exist (3.4, 5.2, 5.3, 6.2 at programme level). The guide provides redistribution in exactly four programme-level cases and this workflow verifies that each claimed redistribution is (a) one of those four, (b) accurate, and (c) countersigned by Quality and IQA. The asymmetry at 5.2 gets a specific check every cycle: eligible-but-unaccredited scores zero while not-eligible redistributes, so an eligibility misclassification is a self-inflicted three-point loss and it is invisible in the submitted value.

Category 4, the activity exists but is invisible (3.3, 4.3, 4.4, 4.5, 5.4, 6.1, 6.2). This is where most of IoL's uncounted score sits and the response is capture rather than tactics. This workflow's contribution is the register health check at month -9: for each of the nine registers the institutional pack names, does it exist, is it current, and is it being written to at the point of occurrence rather than at the point of reporting? A register that is populated retrospectively each year is a reporting exercise wearing a register's name, and this workflow is the one positioned to notice.

Category 5, performance is genuinely low. Report it accurately and open a corrective action plan using the MoHESR CAP template. This workflow's contribution is the honest classification at step 13, and the specific discipline of not misclassifying a reporting gap as a performance gap or the reverse. The first overstates IoL's improvement; the second overstates IoL's problem and sends real resource at a data defect.

The one thing this workflow contributes that no other workflow can. Every other workflow in the pack argues for its own KPI. This is the only one whose interest is in the number being right rather than high, and it is the only one positioned to see all twenty-two at once. That is why the sign-off separation, the waiver log and the boundary check below sit here rather than being distributed. A pilot measured by score improvement will, over time, select for favourable interpretations unless something in it is measured by something else. This workflow's performance measures in section 13 are about accuracy, completeness and reproducibility, and deliberately not about the score.

Boundary check. This is the most important boundary check in the pack, because every other workflow's claims pass through here, and it is the last point at which any of them can be stopped.

This workflow must never:

• submit a value it cannot evidence, whatever the pressure and whatever the deadline;
• populate a Mechanism of collecting the data field with a description of a method that was not followed, which is the most consequential single line in this document: a mechanism statement is a representation to a regulator about what IoL actually did;
• let a favourable classification pass without the second signature the charter requires, at 5.2 eligibility, at 3.4 redistribution, at 6.2 redistribution, at 5.3 redistribution, at any Appendix C grouping, and at any substitute-data decision;
• submit a Track A KPI null in place of computing it or withholding it explicitly;
• allow a value to be signed by the person who calculated it;
• waive a validation rule or an assertion without a written reason and a recorded approver;
• release a pack with an unresolved cross-KPI assertion failure;
• recalculate a value on a different basis in order to make it pass a validation rule;
• change a denominator basis, a grouping, a classification or an attribution rule mid-series without recording the change and stating its effect on the rolling average;
• accept a value that arrives without its source and extract date;
• accept an evidence pointer that does not resolve to a retrievable artefact;
• rationalise a dashboard variance it cannot explain;
• classify a reporting gap as a performance gap, or a performance gap as a reporting gap;
• present an internally computed score forecast as anything other than an estimate, while the band-to-score mapping remains unpublished;
• carry forward a defect (D1, D2, D3) as resolved on the basis of an informal assurance rather than a written answer;
• report a rising score to management review without reporting the waiver count alongside it.

And one positive obligation, which belongs here rather than in the prohibitions. Where a KPI cannot be evidenced, this workflow says so, in writing, to the institutional Process Owner, and opens a corrective action item. An honest statement of absence with a remediation plan is a professional output. A number that cannot be defended is not.

10. Service standards

11. Records and evidence

Appendix B readiness. This workflow is the one that answers the Appendix B question for every other workflow, so its own readiness is the pack's readiness. Today, IoL could not answer an evidence request on most of its claims, not because the evidence has been lost but because most of it has never been created [IoL to confirm]. Each producing workflow's section 11 states its own position. This workflow's job in year one is to hold an honest consolidated view of that gap, publish it, and refuse to let it be described as smaller than it is. The institutional service standard is fifteen working days, or a dated plan within fifteen. A dated plan is an acceptable answer. An improvised one is not.

12. Risks and controls

13. Performance measures

These measure the pipeline, not the department. A rising OBEF score with a rising waiver count is a warning, not a success, and this table is deliberately built so that it says so.

The reproducibility measure is the one to watch first, and it is also the pilot's own success criterion. If a KPI can only be produced by one person, IoL has a dependency rather than a process, and the pilot has not demonstrated the thing it set out to demonstrate: that the OBEF data is a by-product of doing the work.

14. Change control