Before you run a single experiment, decide what kind of project you are building. ISEF work generally takes one of three shapes: a scientific study that tests a hypothesis, an engineering project that designs and tests a solution, and a computational or data study. Each answers a different question and is judged by different standards. Choosing the shape early keeps your whole year coherent — and prevents a painful pivot in month eight.
Decide the shape of your project first
Students often obsess over the subject area — biology, physics, environmental science — before settling the more fundamental question: is this a study or a build? The distinction matters because it changes everything downstream. A hypothesis-driven study needs controls and statistics; an engineering project needs requirements and testing against them; a computational project needs a defensible pipeline and reproducibility. Pick the wrong shape and your methods, your board, and your judging conversation will pull in different directions all year.
This is different from picking your ISEF category (the subject bin you compete in) and different from choosing a research topic. It is the architecture of the project — the engine that drives your method. Get it right early and every later decision becomes easier, because you know what “done” looks like. Get it wrong and you may find, late in the year, that you have been running an engineering build with a scientist’s expectations, or a data study with no honest baseline.
A simple way to force the decision is to write your project’s success sentence before you start: “This project will succeed if I can show ______.” If the blank fills with “whether A changes B,” you are building a scientific study. If it fills with “that my design meets requirement C,” you are building an engineering project. If it fills with “what pattern the data hold,” you are building a computational one. The sentence you cannot yet write honestly is the decision you have not yet made — and it is worth making on paper before you touch any equipment.
Two engines: the scientific method vs the engineering design process
The clearest fork is between a scientific study and an engineering project. A scientific project asks why or what happens — it poses a hypothesis and tests it. An engineering project asks can I build something that meets a need — it defines requirements, designs a solution, and tests whether the solution meets its specifications. Both are rigorous; they simply run on different engines.
A quick self-test: if your success looks like “I found out whether X affects Y,” you are doing science. If it looks like “I built something that meets need Z, and here is how well it performs,” you are doing engineering. Some projects legitimately blend the two — you might engineer a device in order to test a scientific hypothesis — but you should still know which engine is primary, because that is the story your board and your judging conversation must tell.
Notice that the engineering engine loops where the scientific one concludes. A scientist reaches a conclusion and stops; an engineer reaches a test result and iterates, feeding what failed back into the next design. That loop is not a detail — it is the heart of what engineering judges reward, and a build shown without at least one honest round of test-and-improve rarely reads as a finished engineering project.
The third path: computational and data projects
A large and growing share of pre-college research is neither bench science nor a physical build — it is computational. This includes machine-learning models, simulations of physical or biological systems, and statistical analyses of existing datasets. A computational project can still be shaped as science (testing a hypothesis with data) or as engineering (building and evaluating an algorithm against requirements), but it carries its own rigor standards worth naming separately.
A concrete example clarifies the shape. A student who trains a model to predict a property, then honestly reports how it performs on data it never saw during training, is doing computational science. A student who builds and benchmarks a faster algorithm against a clear performance target is doing computational engineering. The engine is the same laptop; the framing decides which questions the judges will ask and which claims you are allowed to make. Name the framing early, and your evaluation section almost writes itself.
The computational path is especially valuable for international students without lab access, because it needs only a laptop, public data, and free tools. But the freedom is conditional. Reviewers who know the field will ask whether you split data honestly, chose a fair baseline, avoided leaking test information into training, and reported uncertainty rather than a single lucky number. A computational project that skips these is as weak as a bench experiment with no controls. Treated seriously, though, it can be as original and defensible as any project on the floor.
Scientific, engineering, and computational, side by side
The three shapes differ not just in method but in what “good” means and where students most often stumble. Use this to locate your own idea before you commit a year to it.
| Dimension | Scientific | Engineering | Computational / data |
|---|---|---|---|
| Core question | Why or what happens? | Can I build something that meets a need? | What does the data or model reveal? |
| You start with | A testable hypothesis | A defined problem and requirements | A dataset, model, or algorithm |
| Success looks like | A supported or refuted hypothesis | A solution tested against its specs | A valid, reproducible result or model |
| What earns credit | Controls, valid analysis, honest interpretation | Clear problem, iteration, testing against requirements | Sound methods, fair baselines, reproducibility |
| Common pitfall | No controls; over-claiming from small data | A cool build with no real testing | Data leakage; a single unrepeatable number |
Which type fits your idea?
Most students already lean toward one shape without naming it. The point is to name it deliberately, so your methods and your narrative align from day one.
Note that ISEF organizes entries into subject categories, and the way project type interacts with those categories can affect where you compete. That is a separate decision from the one here — and the current category list and rules should be confirmed on societyforscience.org — but the two decisions are related, so make them together rather than in isolation.
How judging expectations differ (an Embark coach view)
The reason project type matters so much is that judges bring type-appropriate expectations to the booth. A judge evaluating a scientific study will look for controls, a fair test, and honest interpretation of the data. A judge evaluating an engineering project will look for a clearly defined need, evidence of iteration, and testing against real requirements — not just a working prototype. A judge evaluating a computational project will probe your data handling and whether your result would hold if someone else ran it. Our breakdown of what ISEF judges look for goes deeper on the conversation itself.
The mismatch to avoid is subtle. An engineering project presented like a science-fair experiment — heavy on hypothesis language, light on requirements and testing — reads as confused, even when the build is impressive. The reverse happens too: a genuine scientific study dressed up as a product pitch loses the credit its controls deserve. Aligning your vocabulary, your board, and your booth answers to your project’s true engine is not cosmetic; it is what lets a judge evaluate you by the standard your work was actually built to meet.
Per Embark, the projects that stumble are rarely the ones with modest results; they are the ones that never decided what they were. A student presents a build and is asked, “how did you test it against your requirements?” — and has no answer, because they were quietly thinking like a scientist. We are a research school, not a prep shop: early in coaching we help students name their engine, then design methods, board, and story to match it. If you want to see how project type fits into the larger arc, our overview of every path to the ISEF finals puts it in context. Decide the shape first, and the rest of the year has a spine.
Frequently asked questions
Is my project science or engineering?
If you test a hypothesis, it is scientific; if you design and test a solution to a need, it is engineering. Some projects blend both.
Can a computational project win at ISEF?
Yes. Data and computational studies compete strongly when the methods are rigorous and reproducible. Check current categories on the official site.
Does project type change how I am judged?
Judges apply criteria suited to your project type — controls for science, testing against requirements for engineering. See what judges look for.
Can I switch types midway?
It is costly. Choosing the shape early keeps your question, methods, and board consistent all year.
Work with Embark
Embark is the international competition team of Youfang Education — a research school, not a prep shop. Our coaches are working researchers who help students name the shape of their project early and design methods, board, and story to match it. We do not sell shortcuts or guarantee outcomes; we teach the craft.
Embark is an independent research-coaching organization, the international competition team of Youfang Education. We are not affiliated with, endorsed by, or sponsored by the Society for Science or Regeneron ISEF. Any results cited reflect Embark's own published record (per Embark). Please confirm all competition details on societyforscience.org; we correct any errors within 7 working days.