Harsha Koorimannil Valiyamannil discusses the factors that influenced her love of computer science, the leap of faith that brought her from India to Belfast and what the future holds for her.

“I wasn’t one of the kids who grew up coding, but I have always loved a good puzzle”, said Harsha Koorimannil Valiyamannil, a recent computer science graduate who left Ulster University with first class honours and a lengthy list of achievements. 

Koorimannil Valiyamannil told SiliconRepublic.com, “I enjoy spotting patterns and figuring out how things work, so when it came to choosing a path, computing science felt like a natural fit for how my brain works. I knew I would enjoy the logical side of it, but what surprised me most was how much room there is for creativity.”

She previously studied animation and graphic design in her native Kerala, India and had always shown an aptitude for maths, so with all of that combined, it made sense to her that she would look to develop a lifestyle and career that merged her skills and interests.  

She believes her artistic background has greatly shaped the way she approaches problems, enabling her to experiment, look at things from multiple different perspectives and communicate ideas in ways that resonate with people. 

“I loved that computing gave me a highly practical toolkit to merge problem-solving with creative design and build tangible things people can actually experience. 

“That is what continues to drive my career path. I want to build accessible technology that goes beyond just being functional. I believe the best solutions are the ones that understand the people using them, consider their needs and make their everyday experiences genuinely better.”

Leap of faith

Perhaps surprisingly, Koorimannil Valiyamannil noted, making the career switch – despite the significant personal and professional commitment it took to achieve – did not feel like a drastic move. Having spent some time working with design software, eventually she began to ask herself, ‘If I built this, what would I add?’ or, ‘How could I make this better?’ 

A background in graphic design and design theory had trained her to consider viewpoints from the user’s perspective, and she found herself constantly analysing what was missing from an experience and how small decisions completely transform the way someone interacts with a product. 

“After a while, I realised I wanted to do more than just create the visuals. I wanted to understand the technology behind them and have the technical skills to build the software itself. Computer science gave me the tools to turn my ideas into working products and I knew pretty quickly that this was the exact direction I wanted to take my career.”

A whole new world

To realise her goals, Koorimannil Valiyamannil made the decision to relocate from Kerala to Belfast, in a move that, while bittersweet at points, was exactly the experience she felt was needed. She explained that circumstances at home did not allow for much independence and she wanted the opportunity to build a life entirely on her own terms. 

“Here, I have learned how to chase opportunities without having to worry or hold back. Even something as simple as spending late nights studying in the library felt like an entirely new kind of freedom,” she said. “The initial isolation was the hardest part, but it pushed me to step out of my comfort zone and reach out. 

“Over time, I became much more confident putting myself forward and started having the courage to try things I would never have considered before. Now, the people I have met have become a massive part of my journey. Building that solid foundation of friendships is what helped me turn a completely unfamiliar place into my own.”

As her confidence grew, so too did her desire to have a genuine impact on the world around her. She had noticed that the Women in STEM Society was no longer active at Ulster University in Belfast – an issue she remedied alongside three like-minded peers.  

“We wanted to rebuild a community where students could connect and feel supported throughout their journey in STEM,” she said. “While we started with smaller events to bring people together, we also wanted to create something that would have a wider impact, which led us to making the Hack4Health Hackathon our main goal. “

As the society secretary, she used her design background to create branding and promotional materials for both Women in STEM and the hackathon, supported outreach efforts, and worked with the wider team to contact organisations and secure sponsorship.

“Rebuilding the society and pulling off an event of that scale was a massive amount of work. It was a crash course in the logistics of community building. It also proved that we could actually execute ambitious ideas from the ground up just by stepping up and trying.”

Eyes on the prize

If Koorimannil Valiyamannil’s experiences have taught her anything, it is that often you have to be the architect of your own dreams, but sometimes, you need to be the person helping to lift up others alongside you. 

“Throughout my journey, I have benefited from people who encouraged me, and I want to do the same for others,” she said. “I am incredibly excited about this opportunity to learn from the people around me, share what I have learned and use my skills to build up my community.”

With that in mind, she plans to build a career in technology that creates a positive social impact. Her biggest focus right now, she explained, is on ethical technology and digital accessibility. “I want to build solutions that actively break down digital barriers and ensure no one gets left behind.” 

She added, “I am excited to explore the different directions my career could take, but my core goal remains exactly the same. I want to keep learning, keep building, and use my skills to create inclusive and human-centred tech.”

Don’t miss out on the knowledge you need to succeed. Sign up for the Daily Brief, Silicon Republic’s digest of need-to-know sci-tech news.

A team routing queries across a coding specialist, a logic specialist, and a generalist model assumes each will cover the others’ blind spots. A new study evaluating 67 frontier models from 21 providers shows that assumption is mathematically flawed — and the flaw has a name: the co-failure ceiling.

The assumption works like this: as long as two models don’t usually fail on the exact same prompts, combining them is supposed to create a safety net against failures.

The real limit on orchestration is not how often models disagree, but the percentage of prompts where every model in the pool gives the wrong answer at once. By ignoring the co-failure ceiling, enterprises are building complex, expensive routing infrastructure to chase performance gains that do not exist. Fortunately, developers can use this same math to build a cost-free test that determines exactly when multi-model orchestration will actually pay off.

The hidden costs of the multi-model strategy

To orchestrate multiple language models, developers typically rely on three architectures. Model routers act as traffic cops, sending complex queries to expensive models and simple queries to cheaper ones. Cascades send every prompt to a cheap model first, only escalating to a premium model if the initial system signals low confidence. Finally, approaches like Mixture-of-Agents (MoA) fuse multiple models by asking them the same question and generating a synthesized answer from their combined outputs.

These architectures introduce a “shadow price” to inference costs. Every time a development team implements a router or a cascade, they pay a premium in added system latency, complex infrastructure maintenance, and increased governance risks across multiple API providers.

To justify these operational costs, engineers rely on “pairwise error correlation” to select their model pool. Imagine a developer has Model A, which writes excellent Python but fails at SQL, and Model B, which writes excellent SQL but fails at Python. Because they fail on different types of prompts, their pairwise error correlation is low. The developer assumes that by placing a routing layer in front of them, they have created a composite system that rarely fails at coding.

According to the study, throwing diverse models together based on low correlation can actually hurt performance if the models are not equally capable — when you vote across diverse but unequal models, the weaker ones often gang up and outvote the smartest one.

Josef Chen, author of the paper, told VentureBeat that in their experiments, “Naive majority voting across unequal models had negative mean gain (minus 10 points on our hard mix): diverse-but-weaker members outvote the strong one.” The actionable advice for developers is to “combine only models within a matched quality band.” If you cannot match quality, take the single-model baseline and spend your budget on the best model available.

The paper provides one bright spot for this approach regarding MoA architectures. When building ensembles, teams often use “Self-MoA,” where they query the same premium model multiple times to generate a synthesized answer. The researchers found that at matched quality, building a diverse ensemble of models with low pairwise correlation beats a high-correlation Self-MoA setup.

However, when teams use that same pairwise correlation metric to predict the absolute accuracy of their overall system, the math breaks down.

“So teams pay the orchestration overhead up front (latency, complexity, multi-provider operations) on the assumption that a diversity dividend arrives later,” Chen said. “Usually it doesn’t, because today’s best models agree, and, worse, they fail on the same queries … the prompt simply carries little signal about which model will be the one that’s right when the frontier disagrees.”

Why the math fails: the co-failure ceiling

The core finding of the study centers on a metric called the “co-failure rate” — the formal name for the all-wrong scenario described above. No router, voting system, or cascade can ever achieve an accuracy higher than the ceiling it imposes.

The coding, logic, and generalist pool shows low pairwise correlation on routine prompts — they rarely fail together. But the co-failure ceiling represents the obscure, highly complex edge case that pushes past the limits of current AI architectures. If a prompt is so difficult that all three models hallucinate or fail, it does not matter how intelligently the router distributes the task. The entire pool wipes out at once.

The researchers tested their 67-model pool, which included GPT-5.5, Claude Opus 4.8, and Gemini 3.1 Pro, on the open-ended MATH-500 math benchmark. Based on standard pairwise correlation, statistical models predicted that the entire pool would wipe out simultaneously on only 2.3% of the questions. In reality, the co-failure rate was 5.2%.

Standard correlation metrics underestimated the failure rate by roughly 2.25 times. The culprit is not just independent difficulty, but a shared failure point.

“The driver is what we call a common-mode atom: a slice of queries on which the entire market fails together, which no pairwise statistic can see,” Chen said. “Adding a 20th model to your pool doesn’t buy tail coverage. The tail is shared.”

The researchers also found that task format directly triggers co-failure. When they took graduate-level science questions from the GPQA benchmark and changed them from multiple-choice to free-response formats, the all-wrong tail expanded to 12.7%.

Developers can engineer around the ceiling, though. “The engineering implication is uncomfortable: multi-model setups buy the least exactly where teams want them most, on open-ended generation,” Chen said. “Anywhere you can convert generation into verification or constrained selection (structured outputs, checkable answers, execution tests), you reopen the ceiling.”

Ultimately, the researchers found this ceiling limits AI applications in two distinct ways, depending on the domain:

• Ceiling-bound environments (e.g., open-ended math): The co-failure rate is high. The task is too hard, and all models fail simultaneously. No amount of routing can bypass the lack of underlying capability.

• Realizability-bound environments (e.g., graduate-level science): The co-failure rate is near zero, meaning at least one model in the pool usually knows the answer. However, the models disagree so subtly that a routing layer cannot reliably pick the correct answer without an omniscient oracle.

The $0 pre-deployment sanity check

Before dedicating engineering hours to building a router, teams can calculate their absolute performance ceiling for free using a mathematical formula called a Clopper-Pearson bound.

The Clopper-Pearson bound operates as a worst-case scenario calculator. If you flip a coin ten times and get eight heads, you cannot guarantee the coin will land on heads 80% of the time forever. The bound takes a small sample of test questions and outputs a mathematically guaranteed ceiling.

Applied to language models, suppose a team tests a pool of five agents on 50 sample queries and finds they all fail together on just two questions. A developer might assume their multi-agent system will achieve 96% accuracy in production. The Clopper-Pearson formula corrects this optimism. It analyzes the small sample size and provides a mathematical guarantee that the true co-failure rate could actually be as high as 12%.

To use this in practice, enterprises must build a held-out dataset. A fintech company, for example, could take 200 complex customer support tickets from the previous quarter and have human agents write perfect resolutions to serve as a benchmark. While this sounds like a heavy manual project, mature engineering teams can automate the entire ceiling calculation.

“Integration is trivial: it’s a counting job over eval logs teams already produce,” Chen notes, “so it runs in the same CI stage as the eval suite and re-triggers whenever the model pool or the workload changes.”

The engineering team then runs its candidate models against these 200 tickets once and records the results. When they want to evaluate multi-model configurations, they can use the co-failure rate measure to predict the maximum accuracy they can get from the system without running extra queries.

One important conclusion the study draws is that on tasks where answers can be definitively checked, combining models rarely beats using the single best model on the market, unless the team possesses an exceptionally strong query-level routing signal.

In an enterprise environment, a definitively checked task has an objective, zero-tolerance answer. This includes generating a SQL query that must execute without error, extracting a specific invoice total from a 50-page PDF, or formatting a JSON payload that perfectly matches a strict schema. For these tasks, enterprises are usually better off paying a premium for the smartest frontier model rather than weaving together three cheaper models and hoping a router picks the correct output. The study didn’t test subjective, ungraded tasks like drafting marketing copy — the authors note that whether these findings hold outside their verifiable benchmarks remains an open question.

Because this mathematical check is free, enterprise teams can track their own co-failure rates as new models drop.

“The measurement costs nothing, so any team can track its own co-failure rate across model generations and watch whether the tail is closing,” says Chen. Ultimately, “the lever buyers hold is failure-mode heterogeneity and market churn, not model count.”