Common IA mistakes (and how to avoid them)
A blunt list of the mistakes that pull marks down most often, with what to do instead. Most of them cascade: a weak Criterion A undermines B, C, D, and E.
Watch out for “generic”
If a paragraph in your IA would still make sense pasted into a totally different project, it’s generic. This is the most common reason an otherwise strong IA misses the top band. The usual suspects:
- A computational context that names the language (“It’s a Java program”) instead of explaining why the language fits this problem.
- A decomposition that reads as “input, process, output” with no terms from your scenario.
- A plan that lists stages without referencing your success criteria.
- A testing-effectiveness claim that asserts success without specifics.
Self-test. Substitute your project name with “any project”. If the sentence still works, sharpen it.
Criterion A pitfalls
“Easy to use” is not measurable
Words like “easy to use”, “fast”, “intuitive”, “user-friendly” are opinions, not requirements. A scenario without measurable requirements scores in the lower band.
Fix. Rephrase as something the product must do, with behaviour an examiner can test. “The system shall reject negative quantities” is measurable. “The system should feel responsive” is not.
Success criteria listed but never built
An SC in Criterion A that never appears in your video or evaluation costs marks twice: in A (it doesn’t describe what you built) and in E (you can’t evaluate what isn’t there).
Fix. Halfway through development, re-read your SC list. If a feature was dropped, either re-add it or rewrite the SC. No phantom SC.
The problem itself is too trivial
Replicating a freely-available product (a basic currency converter, a clone of a well-known game) or skinning a website template is judged “barely more than an academic exercise”. Polish does not rescue this.
Fix. Ask: could a non-CS student build a working version with a no-code tool? If yes, add a constraint, data model, algorithm, or integration that makes the problem actually require code.
Criterion B pitfalls
Decomposition and plan as one artefact
Decomposition is the blueprint of the product (what to build). The plan is the blueprint of the work (when to build it). They do different jobs.
Fix. Present them separately. Decomposition first (hierarchy or component diagram), plan second (Gantt, table, or milestone list).
The plan ignores the success criteria
A clean Gantt with no SC tagging on its rows scores in the lower band.
Fix. Tag every row of your plan with the SC it addresses. If a task maps to no SC, reconsider whether you should be doing it.
Missing the Evaluate (or Design) stage
All five stages must appear: Plan, Design, Develop, Test, Evaluate. Evaluate is the most commonly skipped; Design is second.
Fix. Block out real time for Design (before Develop) and Evaluate (after Test). Both deserve tasks tied to specific success criteria.
Diary instead of plan
A week-by-week log of what you actually did is not a plan. The criterion asks for a proposed chronology, written at the start.
Fix. Write the plan early. If it changes mid-project, update it and date the revision.
Criterion C pitfalls
One-diagram system model
A single diagram scores in the lowest band, no matter how clean. The model needs to cover components, relationships, data flow, and UI; that takes two or three diagrams.
Fix. Include at least a class diagram or structure chart, an ERD if you have structured data, and UI wireframes.
No UI design
Wireframes are part of the system model. Skipping them is the single most common cause of an “incomplete” verdict on this strand.
Fix. Sketch every screen the user interacts with, label the controls, and include them. Hand-drawn counts.
Algorithms missing for persistence
Save and load logic is often skipped. If your product persists data, persistence needs at least one algorithm.
Fix. For each major capability (input, validation, processing, storage, output), check there is at least one algorithm. Two to four total is typical.
Testing strategy with happy-path inputs only
A strategy that aligns with every SC but only uses typical inputs sits in the middle band. You need normal, boundary, and abnormal inputs for any SC that admits them.
Fix. For each SC, write three tests: typical, boundary (empty, max, zero), abnormal (invalid type, malformed file, out-of-range). Tag each row with its SC and input category.
Criterion D pitfalls
“States” or “outlines” when the rubric expects “evaluates”
The implementation-choices strand uses a four-rung command-term ladder. Most IAs sit at “outlines” or “explains” and never reach “evaluates”.
| Rung | Example |
|---|---|
| States | “I used a HashMap to store the recipes.” |
| Outlines | “I used a HashMap because it gives fast lookup by name.” |
| Explains | “I used a HashMap because lookup-by-name dominates; an ArrayList would force linear search per lookup.” |
| Evaluates | “I used a HashMap because lookup-by-name dominates. An ArrayList would force linear search, which would slow noticeably above 100 recipes (test 4). The trade-off is losing free ordering, addressed by sorting on display.” |
Fix. For each non-trivial technique, name the alternative, why you chose this one, the trade-off, and (where possible) what your testing showed.
Code with no comments
Comments aren’t directly graded, but uncommented excerpts make the technique choices impossible to evaluate. That caps the techniques strand below the top band.
Fix. Annotate non-trivial blocks in every excerpt: what the block is doing, and where non-obvious, why this is the right way. One short comment per logical block.
“All tests passed” is not effective testing
A report that only says “all tests passed” sits in the middle band, even if the tests are good.
Fix. Say what the tests revealed: which failed first, what defects they uncovered, what you changed, and which risks the strategy does not cover. Fixed failures are evidence of effectiveness, not weakness.
Functionality demonstrated only for some SC
If the product technically supports a feature but the video only shows part of it, the strand is “partial”, not “full”. The video is the evidence.
Fix. Walk through every SC in the video, narrated. Five minutes is enough if you skip the intro animation.
Data or configuration outside the product
A product that requires the user to hand-edit a JSON config, CSV seed data, or a separate questions file is not “fully integrated”. Functionality drops from full to partial.
Fix. Move user-editable data behind the product’s own UI. Even a basic admin screen counts. Static config (e.g. API keys) can stay external.
Inefficient choices that “work”
Patterns like “retype the entire record to change one field” or “reload the whole file every keystroke” run. But the implementation-choices strand drops because the choice isn’t defensible.
Fix. Before locking in a technique, ask: what would a maintainer change first if they saw this? If the answer is the obvious quick fix, you should make it.
Using AI to write your code
The IB’s two-principle test. Did you use AI to help you learn? Acceptable. Did you use AI to pretend you did something you did not? Not acceptable. If AI did the algorithmic thinking, decomposition, or design, the IA has nothing left to assess.
Where the line is
| ✓ Acceptable (helps you learn) | ✗ Not acceptable (replaces your thinking) |
|---|---|
| AI explains a concept (how a HashMap works) | AI designs your data structures and you copy the design |
| AI debugs an error in code you wrote | AI writes the algorithm and you paste it in |
| AI suggests improvements to your own code | AI generates a whole feature, you tweak the indentation, you submit |
| AI clarifies what a library function does | AI builds the integration and you cannot explain how it works |
“Vibe-coding” the IA fails on four counts
Submitting AI-built work as your own (even with some manual edits) triggers all of these at once:
- Academic misconduct. The IB does not consider AI-produced work to be the student’s own, even in part.
- Authentication failure. Your teacher cannot authenticate work they did not see you develop. Authentication requires them to have watched the algorithmic thinking happen across the 35 hours, and to be satisfied that you can explain the code in your own words.
- Nothing for the rubric to credit. Every criterion (problem decomposition, technique justification, evaluation) is about your thinking. If the thinking was not yours, there is nothing the rubric can credit you for.
- Investigation risk if it is submitted. If the IB later suspects the work is not yours, the case becomes a student academic-misconduct investigation. Under the IB’s penalty matrix, the typical outcome for serious cases is a Level 3a penalty (no grade for this subject), which means an “N” on your transcript and no IB Diploma if Computer Science is a required subject. The IB’s “Additional sanctions” can go further still: permanent disqualification means no grade in any subject and no retake.
When you do use AI, the citation must include
- The AI tool’s name, cited in the body of your work at the point of use, not just in the bibliography.
- The exact prompt you gave.
- The date the AI generated the response.
- A note in the appendix saying what the AI produced and what you changed.
Fix. Treat AI as a tutor, not a ghostwriter. Document every prompt at the point of use, and only submit code you can explain when asked.
Sources (the exact text from the IB)
IB, “Evaluating 13 scenarios of Artificial Intelligence (AI) in student coursework” (2024). “There are no hard rules when dealing with AI. Educators should use their discretion with each student. If in doubt, refer to the following key principles:
- Did the student use AI to help them learn, if so then it is acceptable.
- Did the student use AI to pretend they did something they did not? Then this is not acceptable.
It is the school’s responsibility to authenticate any student work submitted to the IB as wholly created by the student.”
Scenario 5 (NOT acceptable): “A student uses AI to write an example of this particular essay for them and uses this as an example or a model answer for their response (translating it into their own words). […] This is like a student finding an essay online or borrowing an essay from a former student to inspire all the ideas for their essay.”
Scenario 6 (mixed): “A student uses AI to generate a paragraph or two for the essay, such as the introduction or summary of an argument and then uses this as a model for their own content. Acceptable. If the student has used AI to provide references and examples. Not acceptable. If the student has used AI to replace their own thinking.”
Scenario 12 (NOT acceptable): “A student tries to hide their use of AI. […] Ethical use of AI involves being clear and transparent about its use.”
IB Academic Integrity Policy (Appendix 6: Guidance on the use of artificial intelligence tools, pp. 53-55). “Students need to be aware that the IB does not regard any work produced—even only in part—by such tools to be their own. Therefore, as with any quote or material from another source, it must be clear that any AI-generated text, image or graph included in a piece of work has been copied from such software. The software must be credited in the body of the text and appropriately referenced in the bibliography. If this is not done, the student would be misrepresenting content—as it was not originally written by them—which is a form of academic misconduct.”
“If they use the text (or any other product) produced by an AI tool—be that by copying or paraphrasing that text or modifying an image—they must clearly reference the AI tool in the body of their work and add it to the bibliography. The in-text citation should contain quotation marks using the referencing style already in use by the school and the citation should also contain the prompt given to the AI tool and the date the AI generated the text.”
IB Exchange, Gilma L. Bermúdez Lafont, “Guiding Students Through the Internal Assessment” (DP Computer Science teacher resource). “Using generative AI for code improvement is now allowed but requires clear documentation, justification, and proper referencing to comply with IB Academic Integrity rules. Like any other coding technique, a clear rationale for selecting the AI must be provided. Explain how the AI functions within the problem, how it integrates with other system parts, and its role in processing data. Simply using AI without understanding it is insufficient. While AI can simplify tasks, demonstrating algorithmic thinking in other areas of the solution and in strategically using AI to achieve success remains essential for the Internal Assessment.”
IB Computer Science Guide 2027 (Academic Integrity section). “Coordinators and teachers are reminded that students must acknowledge all sources used in work submitted for assessment. […] A student’s failure to acknowledge a source will be investigated by the IB as a potential breach of regulations that may result in a penalty imposed by the IB Final Award Committee.”
Criterion E pitfalls
“SC met” instead of evaluated
A two-column table marking each SC met / partial / not met is fine as a summary, but on its own scores in the lower band. The upper band needs prose doing the analytical work.
Fix. After the table, write a paragraph explaining how partially something was met, which inputs caused the partial result, and what the user impact would be. Cite test cases and video timestamps as evidence.
“Make the UI prettier”, the trivial improvement
“Add more features”, “make the interface prettier”, “improve user experience” are flagged as trivial. One trivial improvement pulls the strand down even when the others are good.
Fix. Every improvement should name a specific change, cite the evidence (test failure, video timestamp, real user feedback), and explain the trade-off. Two well-justified beat five generic.
Re-promising an SC that was never built
If an SC was listed in A but never built, promising to add it now isn’t a forward-looking suggestion; it’s a re-statement of the gap. It doesn’t count.
Fix. Improvements should extend a working product or fix a partial-success behaviour your testing revealed, not recover SC you dropped.
Skipping an SC in the evaluation
One SC the evaluation skips, or treats with a single sentence, keeps the strand below the upper band.
Fix. Use the SC list as a checklist. If you have nothing to say about an SC, that’s a signal it was vague to begin with, but write something specific anyway.
Pre-submission checklist
A 10-minute pass once your draft is complete:
- Specificity. Pick three sentences at random. Would they make sense for a different IA? If yes, sharpen them.
- SC consistency. The SC list from A appears (by number or name) in B, C, D, and E. None missing, none added late.
- Video coverage. Every SC demonstrated; at least one boundary and one abnormal test shown.
- Annotations. Every code excerpt in the documentation has comments where useful.
- Improvements. Each is specific, motivated by evidence, and not a re-statement of a dropped SC.
- Word count on the first page of the documentation PDF.
- Video under five minutes.
- Full source code in the appendix PDF.