Every project answers a question. Before you can tell whether a project is innovative, you have to know which question it is trying to answer. This guide separates the three questions behind any technical project, defines the three kinds of innovation that answer them, and explains which kind these courses expect your project to deliver.
Naming the question you are answering is the first step. Each one is judged differently.
Asks whether something is possible at all, or whether a known result can be improved: higher accuracy, a new capability, a method that works where earlier ones failed. The answer is not known in advance, and that is what makes it research. Judged on: does it work, and is it better than what came before?
Given that something can be built, asks for the fastest, cheapest, or most reliable way to build it. The outcome is known to be achievable; the challenge is doing it well under real constraints of time, cost, compute, and robustness. Judged on: efficiency and reliability, not novelty.
Asks whether the thing is worth building at all: does it create value, will people actually use it, and would they pay for it? A technically impressive system that solves no real problem fails here. Judged on: adoption and value to real users, not on metrics.
Each question, answered well, produces a different kind of innovation.
Advancing what is known to be possible. A new method, a new capability, or a result that beats the state of the art. This is the innovation of research papers and benchmarks.
Advancing how well something can be built. A faster pipeline, a cheaper inference path, a more reliable system. The capability may already exist; the gain is in doing it better.
Advancing what people will actually use. A new application, a better fit to a real need, a use case nobody served before. The technology may be off the shelf; the gain is in the value delivered.
In the LLM and Generative AI courses, the three kinds are not weighted equally.
Your project is judged primarily on scientific innovation: a genuinely novel element in the problem, the method, or the result, something not solved before or not solved this way. Engineering innovation is welcome and often necessary, but it is not the point on its own.
Product value is a minimum requirement, not the goal. You do not need to build a business, but you must not build a model with no reasonable use case. A technically novel system that no one could ever use fails the floor. Pick problems where a real user or stakeholder would plausibly benefit, then push the scientific novelty as far as you can.
Engineering innovation serves the science. Use it wherever a faster, cheaper, or more reliable build is what makes the scientific question answerable at all, not as a substitute for a novel result.
In one line: aim for scientific innovation, clear the bar of product value, and use engineering innovation wherever it makes the science possible.
