IB DP IA Mastery: How to Document Changes After Feedback (So Nothing Is Lost)

IB DP IA Mastery: How to Document Changes After Feedback (So Nothing Is Lost)

Feedback arrives like a spotlight: it highlights what works and exposes what needs attention. For IB students juggling rigorous IAs, EEs and TOK essays, that spotlight can be a blessing — and a source of anxiety when edits, rewrites and helpful comments start to pile up. The real skill isn’t just responding to feedback; it’s documenting what you changed, why you changed it, and how that change affects your assessment. This keeps your project honest, makes moderation straightforward, and preserves marks that might otherwise be lost to confusion.

Why careful documentation matters (for you and your assessor)

Think of documentation as the audit trail for your thinking. Examiners and supervisors want to see a clear, logical development from question to method to conclusion. When feedback arrives — from your supervisor, a teacher, a peer, or an online tutor — showing the steps you took afterwards does three things:

• Protects academic integrity: transparent records demonstrate that substantial edits were considered, attributed and justified rather than hidden or invented.
• Clarifies intent for assessors: a note that explains why a research question was refined helps examiners follow your rationale instead of guessing.
• Makes moderation fair and efficient: when external moderators check work, a clear change log speeds decisions and reduces risk of lost marks.

How this applies across IA, EE and TOK

Although this guide focuses on IAs, the same principles apply to Extended Essay and Theory of Knowledge writing. For the EE, documentation of methodology shifts, source additions, or re-scoped topics is crucial. For TOK, recording how feedback reshaped your knowledge question or real-life examples shows intellectual maturity. The methods below are flexible and intentionally evergreen — they remain useful through the latest updates to IB processes and in future cycles.

Core principles for documenting changes after feedback

Before we jump into templates and step-by-step routines, keep three guiding principles in mind:

• Be brief but precise: Each entry in your log should explain the change, the author of the feedback, and the reason in one or two sentences.
• Time-stamp everything: A date and time (or simple relative marker like “Week 2, draft 3”) are essential—moderators want to see the sequence.
• Connect changes to criteria: Note which IA criterion or EE expectation the change aims to address (e.g., “Criterion C: Methods” or “EE: Literature review clarity”).

Quick mindset adjustment

View every piece of feedback as data. You are not just “fixing” prose; you are improving evidence, argument, or method. Documenting is simply recording that data and what you did with it.

A practical, student-friendly change-log system

Below is a lean, reproducible change-log structure you can copy into a single document or spreadsheet. Use it for every draft and keep it alongside your main IA file. Prefer simple tools: a spreadsheet, a Google Doc, or a version-controlled folder work fine — the method, not the software, matters most.

Example change-log entries (short and copy-ready)

Below are real-feeling, compact entries you can paste and adapt.

• Draft_v1.1 — Week 2 — Supervisor (Ms. K): Clarified independent variable from “light intensity” to “lux measured at sample surface”. Rationale: measureability. Impact: stronger Criterion C.
• Draft_v2 — Week 4 — Peer review (J): Rewrote analysis paragraph to include percent difference and error propagation. Rationale: adds quantitative rigor. Impact: improves Criterion D evidence.
• Draft_v2.2 — Week 5 — External tutor: Reordered literature review to group studies by methodology rather than year. Rationale: highlights methodological trends. Impact: better EE synthesis.

Step-by-step routine to follow after every feedback session

Adopt a repeatable routine so documenting doesn’t become another source of stress. Treat it like an experiment protocol that you always follow.

1. Capture feedback immediately. Right after a meeting, write a 1–3 sentence summary in your change-log. If the feedback was verbal, record the speaker and a timestamp.
2. Prioritize edits. Decide which feedback is urgent (method errors, ethical issues), high-impact (affects criterion scores), or optional (stylistic suggestions).
3. Make targeted changes in a new version. Save a copy of the draft (Draft_vX+1). Implement changes only in that copy so earlier drafts remain available.
4. Record the change. Fill the change-log for that draft with the fields in the table above. Keep entries concise but specific.
5. Reflect briefly. Add a one-sentence reflection on whether the change worked and whether more follow-up is needed.
6. Keep objective evidence. If you re-ran an experiment or re-analysed data, keep the raw files or screenshots and reference them in the log.

Tools and naming conventions that make life easier

Your toolset should be simple and replicable. Here are pragmatic options:

• Cloud drive folder per project: /IA_Project_Name/ with subfolders Drafts, Data, Feedback, ChangeLog.
• File naming: IA_ProjectName_Draft_v1.pdf (or .docx). Add date if you wish: Draft_v1_Week3.
• ChangeLog as a spreadsheet: columns should match the table above; use filters to view entries by section or criterion.
• Version control: if you use Google Docs, use explicit copies rather than relying only on revision history — copy names are easier to reference during moderation.

What to record: practical examples and templates

When writing the description of a change, stick to this micro-template: What → Why → Effect. Keep each entry one to two sentences.

How to show you didn’t just “copy” feedback

There’s a difference between following a suggestion and adopting it without thought. In the change-log, include a short reflection sentence like “I tried this and the p-value increased; I therefore adjusted the interpretation to X.” That sentence demonstrates active engagement and academic honesty.

Working with different feedback sources (supervisor, peers, tutors)

Feedback comes in flavors. Supervisors offer assessment-focused advice; peers provide readability checks; tutors or online services can offer methodological suggestions. Treat each source slightly differently in your log:

• Supervisor feedback: Always timestamp and link to the supervisor’s comment (copy the short quote) so moderators can trace why a major change was made.
• Peer feedback: Summarize and note the peer’s initials; peer suggestions are valuable for clarity but usually don’t require as formal an attribution as supervisor edits.
• External tutoring: If you use paid or structured tutoring, record the tutor’s name and the session date. If you use AI or platform-based support, describe the advice and how you applied it.

For example, if you work with Sparkl‘s personalized tutoring, note the session date, the tutor’s suggested changes, and which criterion the tutor helped clarify. That way, the guidance is transparent and tied to tangible edits.

Common pitfalls and how to avoid them

Students often make similar mistakes when documenting changes. Here are the top pitfalls and simple fixes.

• Pitfall: Vague entries like “made edits per supervisor”. Fix: Quote the supervisor’s core point and describe the technical change.
• Pitfall: Over-documenting trivial style edits (typos, commas). Fix: Focus on substantive edits that affect method, analysis, argument, or evidence; still keep a simple record of final proofreading.
• Pitfall: Deleting earlier drafts. Fix: Keep copies; if storage is an issue, compress and archive earlier versions.
• Pitfall: Not connecting changes to assessment criteria. Fix: Always note which criterion you intended to improve and why.

Handling major changes late in the process

Sometimes feedback suggests a substantive rework — a shift in method or a new dataset — late in your timeline. If that happens:

• Log the feedback and your decision to accept or decline it.
• If you accept, document the scope of the rework, new time estimates, and any ethical approvals required.
• If you decline, explain briefly why (e.g., “change would compromise data already collected and is outside the IA’s permitted scope”). That explanation is important for moderators who may wonder why significant feedback was not acted upon.

Sample workflow timeline (practical example)

Here’s a compact timeline you can adapt. Replace “Week X” with your own distance-from-submission markers.

Final polishing: checklist before submission

Run through this short checklist during your last pass:

• Every substantial change has a ChangeLog entry (What → Why → Effect).
• Draft versions are preserved and clearly named.
• Raw data files referenced in the log are included or archived with clear paths.
• Attributions for feedback are complete (supervisor, peer, external support).
• Citation and academic honesty checks are done — no unattributed content.
• Final reflection links changes to assessment criteria where relevant.

Closing thought

Documenting changes after feedback is not busywork; it’s a disciplined record of your intellectual journey. The clarity you build for yourself becomes clarity for your assessors. Use concise, consistent logs, keep earlier drafts, and always link edits to the criterion they improve. These practices protect your work, showcase your thinking, and make the evaluation process fair and transparent.

The end.

Vrinda Bhandari Member since March 30, 2026

Loading + Follow Following