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 2027 syllabus (first assessment May 2027).

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

Choosing a problem

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

Must be of genuine 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.

If the bulk of the work was done by a tool, wizard or template, the submission will not score well regardless of documentation quality.

Time commitment

35 hours of recommended class time, plus your own time outside class.
Poor time management is the single biggest predictor of a weak IA. 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. They can only do this if they have seen the work develop across the 35 hours – not if they only see a finished product the day before submission.
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. There is no separate IA-specific AI rule – the existing academic-integrity rules cover it.

In practice for the IA:

AI may be used like a textbook or tutor: explaining concepts, suggesting debugging approaches, clarifying syntax, reviewing your code for issues.
Code generated, adapted, or substantially edited by AI must be cited at the point of use, with an entry in your appendices listing the AI tool, the prompt or task, and what you changed yourself.
AI must not be used to generate the substance of your documentation prose.
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 for this course because it aligns with the DP Computer Science programming teaching sequence. You are free to choose another language, but:

Whichever language you pick, you must justify the choice in terms of the problem’s requirements (not personal preference). Contrast at least two alternatives on criteria like suitability for the data model, availability of relevant libraries, or the ability to produce the target artefact. The justification belongs in Criterion A (when explaining the computational context) or Criterion D (when justifying the structure and techniques) – not somewhere in between.
The 2027 guide lists acceptable forms of solution explicitly: 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.

The point is not to produce an exhaustive market review; it is to explain, briefly and honestly, why your specific computational solution is the right answer for 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 the appendices. The 2027 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 reference in the documentation (client/advisor notes if you used one, interview transcripts, questionnaire data, research sources).

Appendices are not used as evidence for awarding marks, and examiners are not required to read them. Everything that earns you marks must be visible in the documentation or the video. The appendix’s main job is to make the claims you make in Criteria D and E verifiable.

Suggestions for the product

Below are techniques and categories of project that tend to give you enough surface area to demonstrate complexity and ingenuity in Criterion D. These are suggestions, not a shopping list – pick what serves the problem.

Example core features

Graphical user interface with multiple windows or views.
File import / export (CSV, JSON, text) through a file selector.
Sorting and searching / filtering of collections of data.
Arrays, 2D arrays and ArrayLists for in-memory data.
Advanced data structures – linked lists, stacks, queues, binary search trees, hash maps.
Error handling that gracefully manages unexpected input.
Usability features – clear instructions, responsive feedback, accessibility considerations.
Modular code – multiple classes, generalised methods, encapsulation.
Complex data manipulation – multi-step transformations driven by user inputs.

Research-based algorithms

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, quick sort).
Backtracking (Sudoku, N-Queens).

Ambitious – only attempt if you have prior experience with the technique:

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

Students often start one of the ambitious algorithms because it sounds impressive, then run out of hours and submit a half-implemented product. A simpler algorithm done well scores higher than a sophisticated algorithm done badly.

Extensions

Timer or scheduler components.
Calendar integration.
2D graphing or data visualisation.
Database integration for persistence (SQLite, MySQL).
Encryption / decryption of sensitive data (use established libraries – e.g. Java’s javax.crypto – never roll your own cryptographic primitives; home-rolled crypto is broken crypto and loses marks under “appropriate techniques”).
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). Heavily attempted, frequently underestimated – 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 – examiners will see the mismatch immediately.
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 the examiner can tell – whether the product actually meets them.

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