The Rules Inside a Results Application

1. At a Glance

Issue study · From the public record.

Organisation type	A public university in India described in one press report, set beside the position of a mid-size institution that runs an examination and results application it built or had built
Size band	The case: a large public university. Our reader: a college, an autonomous college, a mid-size university, a school group, a coaching institute or a training body with its own examination and results application
Region	The case: India. The reader: anywhere; the regulations in section 3 are Indian
The decision at stake	What to do about an examination application whose rules nobody can read, whose changes nobody can check, and whose slowest step everyone has agreed to sort out: keep checking by hand, replace the whole application, have the rules written down and tests put around them, or take it step by step to one rebuilt module
The public outcome	A press report described months-long results delays at the university; as reported, the official in charge of examinations gave the pandemic and repeated changes to the examination arrangements as causes. Nothing in the record shows that an old system caused any delay
Why it matters to a mid-size institution	Results are watched, and the rules behind them keep changing. The part of the issue that lies in an institution’s own application, its rules, its changes and its slowest step, can be written down, tested and, one step at a time, rebuilt

2. The Business Problem, in the Buyer’s Words

“Our examination application was built for us years ago. It gives the answers we expect, and nobody in the section can say exactly how. When a new course or an amended regulation comes in, a developer changes it and checks the new case; whether anything else moved, nobody can say. And one step, bringing the departments’ marks together, takes most of every results run. Every proposal we receive is to replace the whole application. I cannot approve that, and I cannot describe what we have.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The institution is caught between an application that works and a section that is asked about rules it cannot read. The cure it is offered, a new examination system, is larger than the problem it can describe.

3. What We Found

Method. We went through the public record on results processing and on how organisations treat old software that still works: one press report from India, the University Grants Commission’s degree regulations of March 2025, one cross-sector survey of IT professionals, one developer’s account and one survey of developers. The sector research behind this study holds no institution of our readers’ size on this issue, no figure for how long a results run takes or how often one is late or wrong, and nothing on how examinations are conducted or what any examination rule requires.

One press report, and its causes. A press report described months-long results delays at a public university in India, which it linked to the university’s own software; as reported, the official in charge of examinations gave the pandemic and repeated changes to the examination arrangements as causes. We use this for one point: results processing is watched, and a delay is reported. The report does not describe the system as old. None of this shows that an old system caused any delay, and we draw no such cause from it.

What the 2025 regulations say about entry, exit and credits. These are regulations, not a case, and we report them only in their own words.

Source	Public record	To whom it applies
UGC regulations on minimum standards of instruction for undergraduate and postgraduate degrees, notified 26 March 2025 (India)	“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.” Also a permission: “HEIs prepared to handle biannual admissions may admit students twice a year, in July/August and January/February."	"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”. What they mean for an institution is for its own registrar, controller of examinations and advisers

What is said about old software and change. In one cross-sector survey of 504 US IT professionals, the publisher reports that “62% of organizations still use legacy systems”; half of those asked said the biggest reason they had not upgraded was that “the current system still works”, 44% named budget limitations and 38% fear of disrupting operations among the reasons. One developer, writing about old code in several languages: “There’s nothing scarier than making changes to a critical legacy system with no tests.” In one global survey of 1,720 developers whose main language is PHP, “32% of developers still don’t write tests at all”. None of these is about education.

Our reading of where the trouble can lie in an institution’s own application. These three are our reasoning. They are not findings about the university above, and nothing says its delays came about for these reasons.

1. The rules are written down only in the application. The regulations say what the rules should be; the code holds what they are. The examination section cannot set one beside the other.
2. A change cannot be checked. The rules keep changing, and each change is checked against the new case only, because nothing records what the application produced before.
3. One step takes most of the time. It is done by hand, or by an old program that one person knows how to restart, and the only remedy proposed is to replace everything.

Our reading of the regulations, and only that: credits earned and banked, an exit with a certificate and a return before a time limit are the kind of rules an examination application has to apply, and an application built for programmes that ran their years in one line would have to change before it could apply them. The UGC does not say any institution’s application is old or must change. What the regulations ask of an institution is for its own registrar, controller of examinations and advisers.

4. The Options an Institution in This Position Had

Option	When it fits	What it risks	Our view
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, is done again from nothing each time, and leaves the slowest step as it is	Right only where changes are few and the step is not a burden
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, someone still has to say what the old application did, and the step that hurts most waits for the whole programme	The institution’s own decision, and right for some; choosing or installing a packaged product is not IOanyT’s kind of work. We would advise against this as the first answer for an application that works
Have the rules written down and tests put around them, and let the institution’s own team carry on	The institution’s own team can make changes, and will run the tests and keep them current	Nothing is rebuilt, so the slowest step stays; the tests help only while someone runs them	A good outcome where the team can carry on; it is the first two stages of our recommendation
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	Costs money and the section’s time before anything changes; tests cover only the cases chosen and keep an old mistake until the section rules on it; some checks made by eye are judgement	Our recommendation

5. Our Recommendation, and the Decision It Asks of the Board

For an institution’s own examination and results application, one it built or had built, and nothing else: take it step by step. First have the application read once, every rule it applies written down in plain language and traced to its place in the code, and each one confirmed or queried by the examination section. The section decides whether a rule is what was intended. Then 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 hand them to the institution’s own team, which runs them. Only then, and only if the institution approves it, rebuild the slowest or most manual step as one module while the old application keeps running, with a traceability matrix, accepted by the section. How each stage is bought is the institution’s own decision under its own rules.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the institution’s own figures, taken in the first review. None of them is a promise about any result or any date.

Measure	Typical starting point	Where it should be	How it is checked
Share of the application’s rules written down and confirmed by the section	None; the rules are in the code and in a few people’s memory	Every rule the application applies, in plain language, each confirmed or queried by the section	The section’s sign-off on the specification
Share of the results logic covered by tests that record today’s outputs	None, or a check of the new case only	Every part that must change, covered by tests that record what it produces today	The test report
How long it takes to list what a change altered	It cannot be listed; “it should not have”	The time of one run of the tests	The test run
How long the slowest step takes	Not measured; known as “most of the time”	A target agreed with the section, measured before and after the step is rebuilt	The institution’s own timing

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about your examination and results application, the questions about its rules nobody can answer, how a change is checked, and the step that takes the longest. 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 study 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.
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.

8. What the Client Would Own

• The specification: every rule the examination application applies, in plain language, traced to its place in the code, with the section’s own verdict beside each one.
• The map and the risk register: the application as it stands, and the parts most likely to be disturbed by a change, listed before any price is set.
• The tests and their report: tests that record what the application produces today, handed to the institution’s own team, which runs them.
• The traceability matrix: if the slowest step is rebuilt, every old function of that step linked to its replacement, with how it was checked.
• The code: the rebuilt module, if one is approved, is the institution’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

Running the application, the tests and any rebuilt module, every result, every ruling on a difference the tests report, and every decision about what a regulation requires stay with the institution and its advisers.

9. What This Approach Does Not Cover

• IOanyT works only on the institution’s own examination and results application, one it built or had built. It does not work inside a packaged examination or student product, and does not choose, install or move one.
• IOanyT does not handle, correct, re-issue or vouch for any student’s result, and does not say that any result or any rule is right. It writes down what the application does; the examination section decides whether that is what was intended. IOanyT does not ask for student records; any it sees in the course of reading the code are not copied or kept.
• IOanyT does not look back at past results or investigate past errors, and takes no part in any dispute about one.
• IOanyT does not run or monitor results processing and is not on call at results time. The institution’s own team runs the application, the tests and any rebuilt module.
• Tests show that a change has altered an outcome. They do not show that the outcome was right before, they cover only the cases chosen with the section, they keep an old mistake as faithfully as an old rule until the section rules on it, and they do nothing about a mark entered wrongly by hand.
• IOanyT promises no results on time and does not say that results will come out sooner. Once one step is quicker, another becomes the slowest.
• IOanyT does not say what any examination rule, the UGC’s regulations or any other rule requires of a particular institution, and offers no compliance, audit or legal advice.
• IOanyT does not say it is empanelled, registered or approved as a supplier to any university, board or government, or that it meets the conditions of any tender. It gives no advice on procurement rules, and does not say an institution’s budget year, governing-body approval or tender will fit any of its terms.
• IOanyT reads the old technologies it names (VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP), not COBOL, RPG, FoxPro or mainframe systems.
• This study does not say IOanyT would have prevented anything at the university described. IOanyT has no published case of this work for a college, a university or any education body.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
A press report from India (cited without link)	A public university’s results delays, and the causes given as reported
UGC regulations on minimum standards of instruction for undergraduate and postgraduate degrees, 26 March 2025 (Gazette of India text, from the UGC’s website)	Multiple entry and exit; joining back, subject to a maximum duration of seven years; twice-yearly admission as a permission; to whom the regulations apply
A vendor’s survey, 2025	Old systems in use, and the reasons for not upgrading
A developer’s post, 2025	Changing old code with no tests
A tool maker’s developer survey, 2025	Developers who do not write tests

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We write down what your examination application does, and your own section decides whether it is right.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →