Mabrok Lab

Philosophy

The hardest problems in AI are often not problems of intelligence. They are problems of abstraction.

One question has followed me through four countries and what look, from the outside, like four different fields: how do we build systems that do not merely produce answers, but understand behaviour, learn from interaction, and improve through feedback?

The route ran from Suez Canal University to Queensland, to a doctorate at UNSW, to a robotics lab at KAUST, to Kuwait, to Qatar. Robust control, then medical imaging, then agents. Four changes of subject, or one subject, depending on where you stand.

It has been one subject. Because in almost every hard problem I have worked on, the difficulty was not a shortage of data or of computing power. The difficulty was that we were looking at the problem at the wrong level of abstraction. A good abstraction hides what does not matter and exposes what does. Choosing it is most of the work. What comes afterwards is engineering.

Think in systems

A system is not a collection of things. It is the relationships between them: the interactions, the feedback, the dynamics.

So I tend not to ask what is happening. I ask what the underlying state is, how it evolves, what information it is receiving, what it does with that information, and then the question that actually matters: what intervention would change its trajectory.

I ask that about a resonant structure, a neural network, a student stuck on a problem set at eleven at night, a clinician reading a scan, a department deciding whether to adopt a tool it does not yet trust. The surfaces have nothing in common. The structure underneath is more alike than anyone expects.

That is not a metaphor I reach for afterwards, to tidy up the story. It is the shape the questions arrive in.

Find the right abstraction

My research is driven less by a particular algorithm than by a particular way of thinking. The interesting territory is between mathematical structure and learned intelligence.

Machine learning has become extraordinarily good at learning representations from data. But learning everything from data is not always the best strategy, because the problem often already contains structure that took a century of work to find. Physics has dynamics. Medicine has anatomy and physiology. Control has state and feedback. Learning has trajectories. Discarding all of that and asking a model to rediscover it from examples is not humility. It is waste.

My doctoral work, with Ian Petersen at UNSW, was on negative imaginary systems theory: the conditions under which two systems can be connected and the whole thing will still be stable, however uncertain each part is. It came out of flexible structures that ring and nano-positioning stages that have to settle without overshoot. It looks a long way from deep learning, and it turned out not to be. More recent work asks when a Koopman approximation preserves those same conditions, and whether the state space models now used in vision are controllable in the sense that control theory means the word. In HamVision the structure handed to the model is Hamiltonian: a medical image model built on the mathematics of how physical systems hold and exchange energy.

The question is the same every time. How much structure can be encoded without restricting what the system is still free to learn?

PREDICTION model x y A function. It is asked once, and it answers once. BEHAVIOUR state observation decision action A system. It is never asked once, and its own answers change the question. Same components. Different abstraction. Almost everything about the design follows from which one you choose.
FigureThe shift underneath most of my work. Prediction asks a model once. Behaviour puts the same model inside a loop it is also changing.

Underneath all of it is one move. Much of contemporary AI is built around prediction: given an input, produce an output. But a patient changes over time. A student learns over time. A robot acts on an environment that acts back. A factory evolves through the decisions taken inside it. These are behavioural systems, and prediction is only one of the things you need from them.

So I think of intelligence less as the ability to produce the next output, and more as the ability to model, influence and adapt to something that is evolving. Can a system learn not only what a thing looks like, but how it behaves?

Teach the behaviour, not the equation

I do not teach content. I teach people.

That is not a sentiment about being kind to students. It is a claim about where the difficulty actually is. Content is the settled half. It has been written down for two centuries, it is correct, and a student can find it in a hundred videos in an afternoon. The unsettled half is the person reading it, who is stuck for a reason the content cannot tell you and often cannot tell you either.

So the subject of the lesson is never really the topic. It is what is happening in the head of the person trying to learn it, and everything below follows from taking that seriously.

I teach differential equations. I do not think of them primarily as equations.

A differential equation is a description of behaviour. The derivative says how something is changing. The equation says how the present state determines that change. The solution says how the whole thing unfolds. So I try not to open with "how do I solve this", which is a question about technique, and to open instead with "what is this system doing", which is a question about the world.

Once a student can see the behaviour, the mathematics becomes a language for describing something they already believe in. Taken in the other order it is a procedure to be memorised, and then forgotten on schedule.

This is also why AI in education interests me, and why I think most of it is aimed at the wrong thing. Faster answers were never scarce. What has never been available at scale is someone who will look at your work, find the line where it went wrong, and ask you a question instead of telling you the answer.

Which means the system should model the learner, not the question: where they repeatedly slip, what they actually understand, which misconception is generating the errors, how their reasoning is changing, and what explanation might land better next time. That is a state estimation problem wearing different clothes.

I built the platform my students use, and I pay for it, which is a decision about honesty as much as about anything else. Software for teaching that has never survived a real semester is a prototype with a marketing page. In an anonymous evaluation last spring a student wrote something I think about more than the scores: that the AI tool is remarkable in answering from the course content itself, without the padding you get from other tools. She had noticed the constraint. The constraint was the point.

Build the system, not the model

Two things have hardened in the last few years.

The first is that intelligence does not have to replace expertise, and is usually worth more when it amplifies it. In healthcare, engineering and science the missing piece is rarely a better model. It is a better feedback loop between the model and the people who carry the responsibility. A model can read more than any person and find patterns nobody was looking for. An expert brings context, judgement and accountability, which are not the same thing as accuracy. So the interesting arrangement is not human against machine. It is human, machine and environment, and the quality of the whole is the quality of the traffic between them.

The second is that a model can be excellent and still fail as a system. Deployment brings people, workflows, uncertainty, incentives, regulation, institutional memory, and an environment that will not hold still. The question stops being how accurate the model is, and becomes what happens when this model is placed inside something that is alive. That is where most of the opportunity sits, and most of the difficulty.

Which puts the strands back together, because they were never really apart. Understand the system. Find the right abstraction. Make the abstraction teachable. Then build something real around it.

Not bigger models. The kind of intelligence the problem in front of you actually requires, and a system around it that can learn, adapt, and survive contact with the world.