IA Guidelines and Requirements

This page covers the practical “how to approach this” decisions: choosing a language, researching alternative approaches, citing your sources, and picking a product that is ambitious enough without being unrealistic. It is aligned with the current syllabus.

For the five criterion-specific requirements and mark bands, see the individual Criterion A-E pages.

Choosing a problem

The IB guide gives you a lot of latitude. The problem you choose:

Should be of personal interest to you. Sustained motivation for 35 hours is hard if the topic is not.
Does not need to come from an external client. You may frame your own problem, or one drawn from another subject, a hobby, or an observation about a system you use.
Should be complex enough to demonstrate algorithmic thinking, organisational skills, and coding ability at DP level.
Should be innovative enough that the product is more than an off-the-shelf template.

The guide is explicit about what is not acceptable:

A program made of only copied code.
A website built on a template that predetermines its structure and layout, with no evidence of structural or functional modification.
A built-in exemplar (e.g. the Northwind database in Microsoft Access).
A copied game without significant, documented modification.
A product built with a drag-and-drop tool that required no code.

The guide lists products like these as “not appropriate”, and it says that whichever problem and form of solution a student chooses, “it is essential that they explicitly demonstrate and document their algorithmic thinking skills”.

Time commitment

35 hours of recommended class time, plus your own time outside class.
Plan time for every stage: designing, developing, testing, evaluating and writing the documentation. Start the planning (Criterion A) as soon as the component begins.

Teacher’s role and authentication

Your teacher is expected to support you. You will not be penalised for asking questions; in fact, you should initiate discussions.
The teacher will read one full draft of your documentation and give written or oral feedback. They cannot edit your work. The next version handed in is the final version.
Before submission, your teacher must authenticate the work as your own. The IB’s Academic integrity policy expects that “The teacher has seen the student develop the work over a period of time” and that “The student can explain their work sufficiently”, so share your progress and drafts with your teacher as you go.
The IB takes a moderation sample from your school. If yours is in the sample, an IB moderator will re-mark the work and may adjust your school’s marks (up or down) to align with the IB standard.
Authentication checks may include: discussion of the work with you, reviewing earlier drafts, checking citations, and plagiarism detection.

AI tools and acknowledgment

The IB’s general rule applies: any external source must be acknowledged, including AI tools. The IA section of the guide has no separate AI rule; the IB’s academic-integrity rules and your school’s policy cover it.

In practice for the IA:

If your teacher and school allow it, AI can be used like a textbook or tutor: explaining concepts, suggesting debugging approaches, clarifying syntax. Asking AI to mark your IA draft or code, or to tell you what to improve, is a separate case: the IB’s Scenario 10 labels it not acceptable for IB assessments, because the teacher gives one set of written feedback, though it can be useful outside assessment; see Common mistakes.
Code generated, adapted, or substantially edited by AI must be cited: credit the AI tool in the body of your documentation where you use it, list it in your bibliography, and give the prompt and the date the AI generated the response. A short note in your appendices on what you changed yourself is also a useful working record.
Write the documentation in your own words: it has to show your own thinking. Any AI-generated text you do use must be referenced like any other source.
When in doubt, acknowledge. Failure to acknowledge a source can be investigated by the IB as a breach of academic-integrity regulations.

Programming language and methodology

Object-oriented programming in Java is the recommendation on this site because it matches the teaching sequence here. The IB itself does not require or prefer any language for the IA; the guide even notes that Python’s built-in functions (sort, len, max and the rest) are encouraged in tasks such as the IA. Choose the language that fits your problem and your skills.

Whichever language you pick, it strengthens the IA to justify the choice in terms of the problem’s requirements (not personal preference). A sentence or two contrasting an alternative (suitability for the data model, available libraries, the kind of artefact you need to produce) fits naturally in Criterion A (when explaining the computational context) or Criterion D (when justifying the structure and techniques). The guide does not demand a language justification, but the computational-context strand rewards exactly this kind of reasoning.
The IB guide gives examples of the forms a solution can take (the list is open-ended): a new OOP program, an interactive web-based application using a database, a computer game, a mobile application, a simulation, a stand-alone application, or a web-based application. You may also extend an existing system (adding a function, a plug-in, or a new webpage backed by a database).
All solutions must be coded. Products that do not involve code development will not meet the requirements.

Researching alternative approaches

Before committing to your solution, examine alternatives that already exist for the problem. This work goes into Criterion A (explaining the choice of computational context) and feeds back into Criterion B (the plan may include existing code libraries you intend to use).

Useful angles for comparing alternatives:

Integration. Does stitching together several disjoint tools create friction that a single purpose-built solution would eliminate?
Cost. Are existing options behind licensing fees or hardware requirements that are not sustainable for the use case?
Complexity vs. relevance. Does an existing product carry features that are irrelevant to the problem, overwhelming the end user?
Technical feasibility. Can existing alternatives be used given the constraints (device access, data format, data security, maintenance burden)?
Other factors. Scalability, ease of use, vendor lock-in, and upgrade paths.

Keep the comparison short: it supports a decision and does not need to be a full market review (Criterion A has a recommended 300 words). Use it to explain why your proposed solution fits the problem.

Source documentation and citation

Maintain a clean record of every external resource you draw on:

Research papers, articles and textbooks.
Tutorials, online courses and technical blog posts.
Libraries and packages your code imports.
Code snippets, algorithms or frameworks adapted from online sources.
API documentation or software manuals.
Any tool that materially shaped your design or implementation.

Cite these in your documentation and list them in a bibliography (reference list). The IB guide does not prescribe a minimum number of citations, but any adapted or inspired-by code needs to be attributed where it is used.

Full source code must be included as an appendix. Solutions without the full source code as an appendix cannot be awarded full marks for the techniques demonstrated in Criterion D.

Appendices

Appendices are submitted as a single PDF. They must contain:

The full source code of your product (not just the excerpts you showed in the documentation).
Any other resources you developed that the documentation refers to (for example notes from an adviser or user you consulted, interview transcripts or questionnaire data you collected). Published sources you used need a reference in your bibliography rather than a copy in the appendices.

Appendices are not used as evidence for awarding marks, and examiners are not required to read them, so put everything you want assessed in the documentation or the video. The full source code in the appendices is still required: without it, a solution “cannot be awarded full marks for the techniques demonstrated in criterion D”.

Suggestions for the product

Below are techniques and categories of project that tend to give a problem “sufficient complexity” (the guide’s phrase) and give Criterion D plenty to show. These are suggestions, not a shopping list; pick what serves the problem.

Your algorithmic thinking has to show somewhere. Before you commit to a project, list the algorithms, decisions and data handling you will design, code and explain yourself. A records app that only adds, edits, deletes and saves data may give you little to list; a feature that searches, sorts or processes the data with your own algorithm gives you more.

Several of these are topics in the course: file handling, databases, searching and sorting, OOP, and machine learning. The core features below are the foundation most projects need. The advanced algorithms tier (including the HL abstract-data-structures theme) is an optional stretch, not a requirement.

Example core features

Graphical user interface with multiple windows or views.
File import / export (CSV, JSON, text) through a file selector. File handling is a core topic in the course.
Database storage in SQLite: saving and loading data in a database instead of a flat file, the step up from file I/O. Databases are a core topic in the course.
Sorting and searching / filtering of collections of data. Both are core programming topics in the course.
Arrays, 2D arrays and ArrayLists for in-memory data.
Error handling that gracefully manages unexpected input.
Usability features: clear instructions, responsive feedback, accessibility considerations.
Modular code: multiple classes, generalised methods, encapsulation. OOP is a core topic in the course.
Complex data manipulation: multi-step transformations driven by user inputs.

Advanced algorithms (optional stretch)

This tier adds depth, but the guide does not require it: the top band of Criterion D asks for “a fully functional product” that uses “appropriate techniques”, not advanced ones. Choose these techniques when they help solve the problem, and explain how each one contributes to a required feature.

Achievable in 35 hours by most DP students:

Greedy algorithms (locally optimal choices).
Shortest-path algorithms such as Dijkstra or A*.
Dynamic programming (knapsack, longest common subsequence).
Divide and conquer (merge sort, quicksort: sorting algorithms from the course).
Backtracking (Sudoku, N-Queens).
Advanced data structures (HL): linked lists, stacks, queues, binary search trees, hash maps. This is the HL abstract-data-structures theme (B4), encouraged for HL students and open to any student whose problem genuinely needs one.
Machine learning: a trained model for prediction or classification. This is a syllabus topic (A4), usually built in Python and harder to finish in 35 hours, so we suggest agreeing the scope with your teacher first and planning how they will see the work develop.

More ambitious, but a legitimate choice when the problem genuinely needs one. These are harder to scope and finish in 35 hours, so decide based on what your problem actually requires, your current skill level, and a plan your teacher has approved:

Genetic algorithms (evolving candidate solutions).
Simulated annealing (probabilistic optimisation).
Branch and bound (combinatorial optimisation).
Gale-Shapley (stable matching problems).

Choose an advanced technique when the problem requires it and you have time to implement, test and explain it. Avoid picking one because it sounds impressive: if the hours run out, the product is left half-implemented. Criterion D’s descriptors look at how much of the product works (“a fully functional product” in the top band, “partial functionality” in the 7-9 band) and whether the techniques are “appropriate”, so algorithm complexity alone does not establish a mark band. Consider a simpler approach if it meets the same requirements.

Extensions

Timer or scheduler components.
Calendar integration.
2D graphing or data visualisation.
Background threading to keep the interface responsive during slow work (a save, a download, a heavy calculation), using a background thread or javafx.concurrent.Task. An IA-depth technique, not examined.
Encryption / decryption of sensitive data (use established libraries, e.g. Java’s javax.crypto, rather than writing your own encryption algorithms: home-made encryption is very hard to make secure, and an established library is much easier to justify as an appropriate technique).
Automated email notifications.

Project ideas

Inventory control system with file persistence, search, and low-stock alerts.
Academic or revision game with scoring and adaptive difficulty.
Task / project management tool with scheduling and priorities.
Grouping or scheduling application subject to multiple constraints.
Data processing and reporting tool with formatting and export.
Simulation or analysis platform for a well-bounded scenario.
Turn-based strategy game with rules-driven logic and a pathfinding or AI component.
Hotel reservation or booking system with inheritance hierarchies (room types, account types). Harder than it looks: multi-table data, time-window logic, and conflict detection are easy to get wrong; scope tightly.
Financial tracking system with categorisation, reports and data export.

Emphasis should be on a genuine problem, original algorithmic work, and robust software design, not on copying a template and dressing it up.

If your IA needs to change mid-process

It happens. The technology you picked does not actually do what you needed; the dataset is unworkable; the original problem turns out to be too small or too big.

You can change the IA, but the change has to be disciplined:

Re-state your problem specification. The Criterion A scenario, success criteria, and computational context all need to be updated to reflect the new direction. Do not leave the original Criterion A in place if you are now solving a different problem: every section needs to describe the same project.
Re-plan. The chronology in Criterion B needs to reflect the time you have left, not the time you started with.
Talk to your teacher. Authentication depends on the teacher seeing the work develop. A silent pivot looks like a different student handed in the second half.
Decide early. Pivoting in the first month is normal; pivoting in the last two weeks rarely produces a good IA. If you are losing confidence in your topic, raise it at your next teacher discussion, not in week 7.

Final thoughts

The IA rewards thinking about a real problem, choosing appropriate techniques, building something that works, documenting why each choice was made, and then honestly evaluating the result. Pick a problem you find interesting, scope it down until it fits in 35 hours, and write the success criteria specifically enough that you can tell (and so your teacher can tell) whether the product actually meets them.

Once you have a direction, move on to Criterion A: Problem specification.