Documentation and academic integrity

The internal assessment is marked only from the files you hand in, so the product counts for as much as those files show. A product that works perfectly can still lose marks if the documentation is hard to follow, runs over the word limit, or leaves the reader unable to find the code it describes. The same submission also has to show that the work is yours and that every borrowed idea, library and line of code is acknowledged. Clear files and honest acknowledgement both serve one purpose, which is to let your teacher and the moderator check the work.

The three files you submit

The IA submission is three separate files. Each has a fixed job, and nothing in one file can stand in for something missing from another.

The diagram of the three files shows how they depend on each other. The documentation is where the marks are earned; the video is the evidence that the product works and was tested; the appendices let anyone check that each code excerpt in the documentation comes from a real, complete program.

The appendix rule matters most for Criterion D. A submission without the full source code in an appendix cannot receive full marks for the techniques shown in that criterion, however good the excerpts are. Generate the code listing from the final version of the product, after the last bug fix, so the line numbers your excerpts cite are the real ones.

Laying out the documentation

Five sections, in criterion order

Give the documentation one heading per criterion, using the criterion names: "Criterion A: Problem specification", "Criterion B: Planning", "Criterion C: System overview", "Criterion D: Development", "Criterion E: Evaluation". Each criterion is marked against its own descriptors, so a clear boundary between sections means nothing is missed or credited to the wrong criterion. Inside each section, short subheadings help (in D, one per technique and one for testing).

The first page carries the title of the project, your candidate details as your school instructs, and the total word count, which the IB requires on that page rather than at the end.

The word budget

The 2,000-word limit applies to the whole documentation. The IB recommends a split across the criteria, and the split shows where the marks are: Criterion D has 12 of the 30 marks and half of the words.

Source: IB Computer science guide (first assessment 2027), internal assessment criteria.

The recommendations are guidance for each criterion, but the 2,000-word total is a firm limit. B and C have few words because most of their content is diagrams, tables and algorithms, which do not count. D has the most words because it is where you explain and evaluate your choices and justify your testing, which can only be done in prose.

What counts towards the limit

The guide excludes three things from the count: code excerpts, comments and diagrams. Everything else written in sentences counts, including the prose that introduces a figure, the explanation after a code excerpt, and the evaluation in E. Headings and captions are short; check with your teacher how your school counts them, and be consistent.

Tables are a grey area. A test table of planned inputs and expected outcomes reads much like a diagram, but a table full of sentences of explanation is prose in a grid. The safe course is to keep tables to short entries (values, outcomes, "pass") and put any reasoning in the counted text around them. Moving arguments into tables, screenshots of text or code comments to dodge the limit defeats the purpose of the limit, and a teacher or moderator is likely to count it as prose.

Presenting code excerpts

Code in the documentation is evidence for Criterion D, so it has to be easy to read and easy to find in the full program. The guide asks for excerpts that are commented, consistent and readable, and that are referenced to the full source code in the appendix. A good excerpt is short (usually 5 to 25 lines), shows one technique, keeps the original indentation and identifiers, and carries a label that says where it lives.

The Python excerpt shows the format: a caption line naming the file and the lines, comments on the lines that matter, and nothing else.

# Excerpt 3: bookings.py, lines 41-49 (Appendix A, p. 6)
# Times are minutes after midnight, so 10:30 is 630.
# Returns True if the new booking overlaps any booking already in the list.
def clashes(new_start, new_end, bookings):
    for start, end in bookings:
        # Two intervals overlap when each starts before the other ends
        if new_start < end and start < new_end:
            return True
    return False

print(clashes(600, 630, [(570, 600), (630, 660)]))
print(clashes(600, 630, [(570, 600), (615, 660)]))

// Excerpt 3 written in Java for comparison (the product itself is in Python)
public class ClashCheck {
    // Times are minutes after midnight, so 10:30 is 630.
    // Returns true if the new booking overlaps any booking already in the list.
    static boolean clashes(int newStart, int newEnd, int[][] bookings) {
        for (int[] b : bookings) {
            // Two intervals overlap when each starts before the other ends
            if (newStart < b[1] && b[0] < newEnd) {
                return true;
            }
        }
        return false;
    }

    public static void main(String[] args) {
        System.out.println(clashes(600, 630, new int[][] {{570, 600}, {630, 660}}));
        System.out.println(clashes(600, 630, new int[][] {{570, 600}, {615, 660}}));
    }
}

Run with the two sample calls (Java prints false and true in lower case), the function reports no clash for a 10:00–10:30 request between bookings that end at 10:00 and start at 10:30, and a clash when an existing booking starts at 10:15.

False
True

In the real documentation the two print calls would not appear: they are there to show the excerpt runs. What the moderator needs is the function, the reference to Appendix A, and, in the counted text after it, why the comparison is written as new_start < end and start < new_end (it allows back-to-back bookings, as success criterion SC2 requires) and what you considered instead.

Figures and screenshots

Number every diagram and screenshot ("Figure 4: booking form after an invalid date") and refer to it by number in the text. Crop screenshots to the part that matters and make sure text in them is readable at normal zoom in the PDF. A screenshot of the running product can support Criterion D, but it does not replace the video: functionality and testing have to be shown in the video.

Academic integrity

The IB expects all coursework to be authentic: based on your own ideas, with the ideas and work of others fully acknowledged. For a programming project that covers far more than essays. Code, libraries, tutorials, images, icons, data sets, sample databases and help from AI tools are all the work of someone else, and all need acknowledging.

Citing your sources

The IB does not prescribe a referencing style. Your school chooses one (APA, MLA, Harvard and others are common), and you use it consistently. Whatever the style, each reference gives at least the author, the date of publication, the title of the source and page numbers where they apply, and for an online source, the date you accessed it.

Programming projects need citations in two places. In the documentation, cite a source where you use it (for example, when you explain that a library handles password hashing). In the source code, put a comment above any block you copied or adapted, naming the source and saying what you changed. Both point to the same entry in the bibliography at the end of the documentation.

The citation trail diagram follows one adapted function from the code comment to the bibliography.

What needs a citation in an IA:

Plagiarism and collusion

Most academic misconduct in programming projects starts as a shortcut: a block of code copied from a tutorial to get past a bug, a friend's working solution borrowed "just to see how it works", a generated function pasted in without a note. Once submitted without acknowledgement, each of these is presented as your own work.

Collaboration and collusion are different. Discussing ideas with classmates, testing each other's products and helping someone understand an error message are normal parts of learning, unless your teacher has said otherwise. Writing part of someone else's product, or submitting code that another student wrote for you, is collusion. Where your teacher allows collaboration, ask exactly where the line is before you start.

The guide is also clear on what kind of product is acceptable. A product built only from copied code, a website from a template that fixes its structure and layout, an exemplar database shipped with software (such as the Northwind database in Microsoft Access), a copied game without major documented changes, or an app made with a drag-and-drop builder and no code development is not appropriate for the IA, even if every source is cited.

Using AI tools

Output from an AI tool such as a chatbot or code assistant is not your own work, so the general rule for sources applies to it. If you use any AI output in your IA (code, text, an image, a test data set), acknowledge it in the same way as any other source, with a citation where it is used and an entry in the bibliography. Presenting AI output as your own work is plagiarism, like presenting any other unacknowledged source as your own.

Beyond that general principle, each school sets its own rules, and they can change. A school might forbid AI tools for the IA altogether, or allow them only for some uses, such as explaining an error message, with a record of each use. Follow your school's policy and your teacher's instructions, and ask before you use a tool if you are not sure. Where use is allowed, a sensible record is the name and version of the tool, the date, what you asked, and which part of the output you used and how you changed it.

The draft, authenticity and submission

One draft, one round of advice

Your teacher reads and gives advice on one draft of the work. The advice can be spoken or written, and it says how the work could be improved; the teacher does not edit the draft. The next version you hand in is the final version for submission. There is no second round of comments, so the draft you give your teacher should be complete: every criterion written, the product working, testing done and the video at least planned.

The timeline of the sample booking-system project (the practice-room booking system for a school music department used on every IA page) shows where the draft sits.

How authenticity is checked

You confirm that the work is your own and that it is the final version, and your teacher authenticates it before submission. Once the final version is submitted, it cannot be withdrawn. Teachers can check authenticity by discussing the content of the work with you and by comparing it with your initial proposal, your first draft, the references you cite and your usual style of writing, and by running it through a plagiarism-detection service.

For a programming project, a discussion is the most direct check. A teacher can ask you to explain why a loop ends where it does, to change a feature on the spot, or to say what would happen with a different input. Keeping a development log (dated notes of what you built, what broke and how you fixed it), and committing your code regularly to version control, gives you evidence of how the product grew.

Ethics in the documentation

Ethical requirements are part of what makes a product acceptable at all, and the documentation should show you met them. If people were involved (a client, testers, people whose data the product holds), you need their consent before the investigation begins. If you work with someone's existing system, you need the owner's written consent. Collected data must be stored securely and used only for the product, and the IB encourages original data wherever possible. A short statement in Criterion A, and the consent forms kept by your teacher or in the appendices (as your teacher instructs), covers this.

Final self-assessment

The check below is built from the criterion descriptors. Go through it with the final PDF open, not your notes, and fix anything that is missing before you submit.

Then the format checks:

• The documentation is one PDF with five sections and the word count on page 1, at most 2,000 words.

• The video is one file in a common format, at most five minutes, showing the running product and examples of testing.

• The appendices are one PDF containing the full, final source code and the other resources the documentation refers to.

• Every library, tutorial, image, data set and AI use is cited where it is used and listed in the bibliography.

• Every excerpt's file name and line numbers match the appendix.

Checklist

• To do:

  I know what goes in each of the three files and the limits on each.

• To do:

  My documentation has five sections, one per criterion, and the word count on page 1.

• To do:

  I am within 2,000 words, with D at about 1,000, and I have not hidden prose in comments or tables.

• To do:

  Every code excerpt is short, commented and labelled with its file, lines and appendix page.

• To do:

  The appendix holds the full source code of the final version.

• To do:

  I have cited every library, tutorial, forum answer, image, data set and AI tool I used, in the code and in the bibliography, in one consistent style with access dates.

• To do:

  I know and follow my school's rules on AI tools, and I can explain every line of my product.

• To do:

  I have handed my teacher a complete draft for the one round of advice.

• To do:

  I have consent for everyone involved and written consent for any existing system I used.

• To do:

  I have gone through the final self-assessment with the finished PDF.