Informatics Research Programme: A Real-Time Project

An informatics research programme should end with something that runs, something that was measured, and a student who can say honestly what the measurement proves. This one is built around a real-time project for a specific reason: the time constraint makes the work measurable.

Why "real-time" is the organising constraint

A script that processes a file once can be called finished whenever the student decides it is. A system that must respond within a stated time budget on live input cannot.

That constraint forces every question a researcher has to answer. How fast is it, under what load, and when does it stop meeting the target? Those are measurable, falsifiable questions — which is precisely what makes the project research rather than a build.

It also forces engineering honesty. A real-time system has to handle backpressure, failure and restart. A prototype that only works on a clean laptop with ideal input is a demonstration, and students usually discover the difference the first time their pipeline meets real data.

The baseline is not optional

If the programme teaches one thing that transfers everywhere, it is this: a number without a baseline is not evidence.

Every year, students present a model achieving 90 per cent accuracy as a success — without knowing that guessing the most common class scores 89 on the same data. The model learned almost nothing, and nobody checked.

So the baseline comes first, always, before the interesting approach is written. It is unglamorous and it is the difference between a result and a number.

Measuring a system properly

Students arrive believing performance measurement means timing something once. It does not.

Warm-up effects mean the first runs are unrepresentative. Repeated runs are needed because a single measurement cannot distinguish signal from noise. And latency must be reported as a distribution, not an average — the mean hides exactly the tail that determines whether a real-time system actually meets its budget.

A system with a 10 ms average and a 400 ms 99th percentile fails for one user in a hundred, and the average conceals it completely. Learning to report percentiles is a small technical habit with a large effect on honesty.

Narrow questions, finishable projects

"Using AI for healthcare" is a topic. It cannot be answered and no amount of effort turns it into a finding.

"Does this scheduling change reduce 99th-percentile latency on this workload compared with the default?" is a question. It can be answered in twenty weeks, the answer means something, and it could come out negative.

Narrowing takes the first fortnight. Students resist it because the narrow version sounds smaller — and anyone evaluating the work will prefer it decisively.

Reproducibility, as a research habit

Work nobody can reproduce is not much use, including to the student six months later when a university interviewer asks about it.

So the project is kept in version control from day one, dependencies are pinned, randomness is seeded, and there is a script that regenerates every figure in the report from the raw data.

That last requirement sounds fussy and repeatedly saves students, because it means a late correction to the data does not mean rebuilding the report by hand.

The write-up, and the section that matters most

The report states the question, the design, the measurements — and then, explicitly, what the result does not establish and where the system would fail.

Students assume acknowledging limitations weakens their work. The opposite holds. A reader who sees limitations stated clearly trusts everything else; a reader who sees them hidden distrusts all of it.

This section is assessed, because it is where judgement becomes visible.

What it does for an application

Selective admissions sees many applicants who list technologies. It sees far fewer who can explain what they measured, against which baseline, and where their system breaks under load.

That difference is judgement, and it is what the work actually certifies. We make no promise of publication or admission — and programmes that do are making a claim they cannot keep.

Practical details

About 20 weeks at five hours a week, one-to-one, from Class 10 upward. Comfort programming in any one language is the only prerequisite; the reasoning matters far more than the syntax.

Students who want to build that foundation first do well with our Python course with DSA or C and C++. Those preferring mathematics or physics should look at the mathematics research programme or the physics research programme.