The Rules Your Results Application Applies Keep Changing. Four Ways to Make a Change You Can Check, Weighed.

The academic council has approved a new course, counted in credits in a way the older courses are not. The examination application has to be changed to allow for it.

A developer makes the change and checks it against the new course. It works. The controller of examinations asks: has it altered anything for the other courses?

The developer says it should not have. The code for the older courses was not touched, as far as anyone can tell. Nobody can be certain, and nobody recorded what the application produced before the change.

What We Found

For this article we went through the public record on how the rules behind results are changing and how organisations treat changes to old software: the University Grants Commission’s degree regulations of March 2025, one developer’s account and one cross-sector survey.

First, what we did not find: no source that ties the regulations to any institution’s results application, no case of an institution whose results were affected by a change to its application, and no figure for what checking a change by hand costs.

In India, the UGC’s 2025 degree regulations provide for multiple entry and exit. The UGC’s regulations on minimum standards of instruction for undergraduate and postgraduate degrees, notified on 26 March 2025, apply, in their own words, to “every University established or incorporated by or under a Central Act, a Provincial Act, or a State Act, all institutions and colleges recognized by or affiliated to such Universities, and all institutions deemed to be universities under Section 3 of the UGC Act 1956”. They say that “HEIs shall provide multiple entry and exit options in the academic programmes.” A student who exits after earning 40 credits is awarded an undergraduate certificate, provided they have also done a skill-enhancement course of at least 4 credits over and above those 40 (regulation 11.1), and “Students shall be allowed to join back in the 2nd year at level 5 before the expiry of the credits earned, subject to a maximum duration of seven years.” The regulations also allow, and do not require, that “HEIs prepared to handle biannual admissions may admit students twice a year, in July/August and January/February.” They say nothing about any institution’s systems. What they mean for your institution is for your own registrar, controller of examinations and advisers.

Changing old code without checks is feared by the people who do it. One developer, writing about old code in several languages, put it plainly: “There’s nothing scarier than making changes to a critical legacy system with no tests.” It is one person’s account, not from education.

Organisations hold back from the large cure. In one cross-sector survey of 504 US IT professionals, which is not about education, 44% named budget limitations and 38% fear of disrupting operations among the reasons they had not upgraded their old systems.

We should be plain about our part. IOanyT does not say whether any rule or result is right, or what the UGC’s regulations require of any institution. Tests show that a change has altered what an application produces, not that the outcome was right before; which answer is correct is for your examination section.

What Waits While a Change Cannot Be Checked

The rules keep changing, so the application will be changed. The question is what each change costs while nobody can say what it altered.

Rules of a new kind arrive in old code. Our reading, and only that: credits earned and banked, an exit with a certificate and a return before a time limit, and admission twice a year where an institution chooses it, are the kind of rules an examination application has to apply. An application built when a programme ran its years in one line would have to change before it could apply them, and each change touches code few people follow. Whether any of this applies to your institution, and what it asks of it, is for your registrar, your controller of examinations and your advisers.

Every change is checked by hand. The new case is checked because someone thought of it. The older cases are assumed.

Changes are saved up. When every change is a risk, changes arrive together, and nobody can tell which one altered what.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Make Changes to a Results Application, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Keep the application, and add checks by hand at results time	Changes are rare and small, and the section has staff who know what to look for	A check by hand covers what someone thinks to look at, and is done again from nothing each time
Replace the whole application with a packaged examination product	The application is failing in many places, a product fits the institution’s regulations, and it can carry a long change	Every rule has to be set up again, and the next change to the rules still has to be checked. Right for some; choosing or installing a packaged product is not our kind of work
Have the rules written down and tests put around them, and let your own team carry on	Your own team can make changes, and will run the tests and keep them current	Nothing is rebuilt, so the slowest step stays, and the tests help only while someone runs them
Take it step by step: the rules confirmed by the section, then tests, then one module only if approved	The application is used every cycle, changes keep coming, and one step takes most of the time	It costs money and the section’s time before anything changes. Tests cover only the cases chosen, and they keep an old mistake as faithfully as an old rule until the section rules on it

The honest costs. Tests show that a change altered an outcome; they do not show that the outcome was right before. They cover the cases chosen with the section, and a case nobody thought of can still be missed. They do nothing about a mark entered wrongly by hand, and they do not make results arrive sooner. Every difference they report is for your examination section to rule on, and every result stays with that section.

Where You Are Now, and Where You Should Be

Before anything is built, we would set a benchmark for the decision.

Measure	Typical starting point	Where it should be	How it is checked
Answers weighed	One: replace the application, or leave it alone	Four, each weighed against what the section needs	The cost comparison
The rules a change must respect	In the code only	Every rule written down and confirmed or queried by the section	The section’s sign-off on the specification
How a change is checked	Against the new case only	Every part that must change covered by tests that record what it produces today	The test report
What a change altered	Not known; “it should not have”	Listed by one run of the tests, each difference for the section to rule on	The test run
The size of one commitment	The whole application, or nothing	One stage at a time, with the freedom to pause after any accepted module	The staged plan

The starting points above are what we expect to find; in an engagement they are replaced by your own position, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for an education body, and none of them is a promise about any result or any date.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your examination and results application, the changes it has had to take, and how each one is checked. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is your institution’s own examination and results application, one it built or had built, and nothing else. Where a supplier holds the code, the institution arranges read-only access to the code with its supplier, as its contract allows; that step is the institution’s, and we do not obtain code from a supplier. It produces a map of the system as it stands, a written specification of what it does, with every rule the application applies written in plain language for your examination section to confirm, a risk register, a cost comparison between keeping and replacing the slowest or most manual step, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Here your own experts are your examination section, and whether a rule is what was intended is its decision. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. Here that means two stages at most, each approved on its own. First, we put tests around the parts that must change: tests that record what the application produces today, so that a change which alters an outcome is reported by the tests, and we hand them back to your own team (tests included). Then, only if you approve it, the slowest or most manual step: we replace a system one module at a time while the old one keeps running, and here that is one module only. We never do a single cutover. A traceability matrix links each old function of that step to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

What you need to bring: the assessment, bought in whatever way your own rules require; time from your examination section to choose the cases the tests cover, awkward ones above all, and to rule on every difference the tests report; a named person in the section to do that; and your own team running the application and the tests throughout.

What we do not do: we work only on your institution’s own examination and results application. We do not handle, correct, re-issue or vouch for any result, and we do not say that any rule or result is right. We do not look back at past results or investigate past errors. We do not run or monitor results processing, and we are not on call at results time; your own team runs the tests. We promise no results on time. We do not say what the UGC’s regulations or any examination rule require, and we offer no legal or compliance advice. We do not ask for student records; any we see in the course of reading the code are not copied or kept. We do not say we are empanelled with any university, board or government, and how each stage is bought is the institution’s own decision. We have no published case of this work for an education body.

What changes for the business:

Role	What they gain
Head of institution	A change that alters an outcome the tests cover is reported by the tests to the institution’s own team, and is not left to be found by chance.
Controller of examinations	After a change, the section is given a list of what it altered in the cases the tests cover, and rules on each difference itself.
Registrar	Transcripts and certificates come from an application whose last change was run through the tests, and not assumed.
Head of IT	Tests record what the application produces today, so the team can make a change the rules require and see what else it altered.
Head of finance	The cost of finding out what a change did is paid once, in tests the institution keeps, and not again in checking by hand after every change.

None of these means any result will be right or on time.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
This article names no institution as a case of the problem. Its figures come from the UGC’s 2025 degree regulations, one developer’s account and one vendor’s survey.	For an institution’s own examination and results application, we write down the rules it applies and put tests around the parts that must change, and hand them to the institution’s own team. Whether a rule applies, what it requires, and every judgement on a result stay with the institution.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. When the rules keep changing, we would make each change one your own team can check.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →