The computational solution: overview

What the task asks you to do

The internal assessment in IB Computer Science is a single project called the computational solution. You choose a problem that interests you, specify it precisely, plan and design a solution, write the code, test it, and judge how well it works. The project is the same at SL and HL: the same task, the same five criteria and the same 30 marks.

The IB uses two words with exact meanings. The product is the finished software and nothing else. The solution is everything you submit about it: the written documentation and the video. Keeping the two apart helps when you read the criteria. Criterion D judges the product itself (does it work, how was it built, how was it tested), while A, B, C and E judge the process you followed to get there.

The topic can be any area of computer science that interests you, and it does not have to come from the course content. A program that schedules a sports league, a simulation of traffic at a crossroads or a tool that checks chemistry calculations are all valid, as long as the problem needs a coded solution with real algorithmic thinking. Choosing a problem and a client covers how to pick one.

The three files you submit

You hand in three separate files. Each has its own job and its own limits, set out in the IB's requirements for the task, so check all three against them before the final submission.

The documentation, the video and the appendices each answer a different question. The documentation explains what you did and why. The video proves that the product runs and that you tested it. The appendices hold the full code so that anyone can check that the excerpts in the documentation are real and complete.

What counts towards the 2,000 words

The word limit applies to the documentation only. Code excerpts, the comments inside them and diagrams are not counted, so a system model drawn as diagrams costs no words at all. The IB names only those three exclusions, so the safe approach is to count everything else you write: ordinary sentences, explanatory text in tables and captions that explain things. Your teacher can confirm how your school counts headings and labels. The IB's guidance recommends a split across the criteria, which also tells you roughly how much explanation each one needs.

Half of the words go to Criterion D. That reflects its weight: D carries 12 of the 30 marks, more than any other criterion, and it is where you explain and evaluate the choices you made in the code. B and C get only 150 words each because their evidence is mostly diagrams and tables.

Why the appendices still matter

The appendices are not used to award marks, and the marker does not have to read them. They still have one hard consequence: a solution without an appendix containing the full source code cannot receive full marks for the techniques in Criterion D. Every code excerpt in the documentation should also say where it sits in the full source ("Appendix A, booking.py, lines 40–72"), so that a reader can find its context.

The five criteria

The documentation has one section per criterion. The table gives each criterion's marks and what it rewards, with the command terms used in its top band. Those verbs matter: "describes" asks for more than "outlines", and "evaluates" asks for more than "explains".

How the marks are awarded

Each criterion has two to four markbands, and your teacher chooses the band whose description fits your work best. A piece of work does not have to meet every point of a band to be placed in it: if it matches some points of the 3–4 band and some of the 1–2 band, the teacher reads both and picks the one that describes the work more fairly. Within a band, the higher mark goes to work that shows the qualities strongly and is close to the next band up.

Two consequences follow. A single weak element is unlikely to drop you a whole band on its own, while a pattern of weak elements will. And because the bands are described with command terms, the depth of your writing moves you between bands as much as the product does. A choice that is only stated ("I used a dictionary") fits a lower band than the same choice explained and weighed against an alternative.

Process criteria and the product criterion

Criteria A, B, C and E are process criteria: they judge how well you specified, planned, designed and evaluated, whatever kind of product you built. Criterion D is the product criterion: it judges whether the software works, which techniques you used, how well you understand them, and how well you tested. The video is part of the evidence for D, so a feature that never appears working in the video is hard to credit.

Each criterion must also be consistent with the ones before it. The plan in B must follow from the specification in A; the system overview in C must fit A and B; the development in D must build what C designed; the evaluation in E must return to A's success criteria. An IA in which the success criteria change halfway, or the code does something the design never mentioned, loses marks in several places at once.

How computational thinking runs through the criteria

The IA is the course's computational thinking process applied to one real problem, from the first statement of the problem to the final judgement of the product. Subtopic B1.1, Approaches to computational thinking, describes the stages; the criteria follow them closely. The mapping shows which stage produces the evidence for each criterion.

The IB does not set out this mapping itself; it is a way of seeing how the criteria fit together. In practice the stages overlap: while testing in D you may find that a requirement in A was unclear, or that an algorithm in C missed a case. That is normal, and it is fine to refine earlier work, as long as the final documentation is consistent from A to E.

What makes a solution acceptable

Every solution must be coded, and you must show and document your own algorithmic thinking. Products can be new systems (an object-oriented program, a web application with a database, a game, a mobile app, a simulation, a stand-alone application) or new functionality added to an existing system (connecting web pages to a database, a plug-in, a function for a learning platform such as Moodle). Some products are ruled out because they show no algorithmic thinking of your own.

Using libraries and frameworks is allowed and often sensible. The booking system uses the Flask web framework and the sqlite3 database module from Python's standard library; what matters is that the logic of the problem (the clash test, the weekly limit, the release of no-shows, the report) is designed and written by you, and that every library is acknowledged. Choosing a problem and a client covers complexity, feasibility and ethics in detail.

The teacher's role

Your teacher is involved from the first idea to the final mark, but the work must be entirely yours. The IB expects teachers to explain the task and the criteria, discuss the project with you as it develops, and check that the work is authentic. You are encouraged to ask for advice, and asking is never penalised.

The one-draft rule shapes the whole timeline. Feedback on a draft is most useful when the draft is complete, so a draft handed in with Criterion E missing wastes the only chance you have to hear what is weak in it. Once you submit the final version and confirm it is your own work, it cannot be withdrawn.

How authenticity is checked

The teacher must confirm that every student's work is authentic, not only the work sent to the IB as a sample. They can do this by talking to you about the content, and by comparing the final work with your initial proposal, your first draft, the references you cite and the style of writing they know is yours. Plagiarism-detection software can also be used. Any code you did not write yourself, whether it comes from a website, another person or an AI tool, must be acknowledged as someone else's work, and you must be able to explain every part of your product. Documentation and academic integrity covers citing sources and tools.

The same piece of work cannot be used for both the IA and the extended essay. If your extended essay is in computer science, its research question and the IA problem must be different pieces of work.

Planning your time

The IB recommends 35 hours of teaching time for the IA. That time includes your teacher explaining the task, class time to work and ask questions, one-to-one consultations, and time for your teacher to monitor progress and check authenticity. Most students also need time outside lessons for coding and testing, which is the part of the project that grows most when something goes wrong.

Your school sets its own internal deadlines, working back from the date on which marks and samples go to the IB. The table is an example of how the stages can be spread over a school year; adjust the months to your school's calendar, and keep the order.

Development takes the largest share of the calendar, but A, B and C come first for a reason. A product built before its success criteria exist tends to have criteria written afterwards to fit it, and those criteria are rarely measurable or complete.

Pitfalls that cost marks across the whole IA

Most lost marks come from a small set of repeated problems. Each one is covered in detail in the note for its criterion; the table gathers them so you can check your work against all of them at once.

Checklist

• To do:

  I can explain the difference between the product and the solution.

• To do:

  I know the three files, their formats and limits: documentation PDF (2,000 words, count on page 1), video (up to 5 minutes), appendices PDF (full source code).

• To do:

  I know what does not count towards the word limit: code excerpts, their comments and diagrams.

• To do:

  I can name the five criteria with their marks: A 4, B 4, C 6, D 12, E 4.

• To do:

  I know the recommended words per criterion and why D gets half of them.

• To do:

  I can explain best-fit marking and why the command terms in each band matter.

• To do:

  I can link each computational thinking stage to the criterion it feeds.

• To do:

  I have numbered my success criteria and will use the labels in every later criterion.

• To do:

  I know which kinds of product are not acceptable.

• To do:

  I know that my teacher reads one draft only, and I plan to hand in a complete one.

• To do:

  I know how authenticity is checked and that I must be able to explain every part of my product.

• To do:

  I have a timeline with my school's deadlines and a project log.