Documenting a STEM project

A student finishes a project, opens an application months later and discovers that the hardest part is remembering what happened. Which decisions were theirs? What did the first version do? Why did they change the method? A polished final screenshot cannot answer those questions.

A small working record can. We suggest keeping documentation alongside the project so it supports the learning itself and makes later descriptions more accurate. This is a working method, not an admissions requirement or a claim that universities will review an external portfolio.

Start with a question small enough to investigate

Write down what the student is trying to understand or build, and what would count as a useful result. Include the constraints: available time, equipment, knowledge and access to suitable information.

For a hypothetical project, a student might ask how two route-finding methods behave on small, artificial maps. That question is narrower and more testable than “use computing to solve transport”. A useful first note would define the maps, what the methods are meant to optimise and how the student plans to compare them.

Save this initial version even if the question changes. Changes can explain how the student's understanding developed.

Keep a brief decision log

After a work session, record the date, what was attempted, what happened and the next question. Add the reason for a significant decision: why a method was selected, a feature removed or a test repeated.

The record does not need to be a diary of every minute. A few clear sentences beside a saved result are often enough. Screenshots, calculations and file versions are useful when they show something the student will later need to inspect.

For code, a version history can help trace changes. For a physical model or mathematical investigation, dated photographs or notebook pages may serve the same purpose. Choose a system the student will maintain.

Make the method understandable

Write the steps another person would need to follow to inspect or repeat the work. Record the tools, important settings, input data and any assumptions that affect the result. A software project should explain how to run it; an experiment should identify the conditions under which measurements were taken.

Keep an inventory of borrowed material. Name the source of a dataset, tutorial, library, design or method and describe how it was used. Check permission and licence terms before sharing material. If the student followed a tutorial, identify what they followed and what they independently changed or investigated.

This makes the boundary of the student's contribution clear without diminishing the learning involved.

Separate results from interpretation

A result is what the work produced. An interpretation is what the student thinks it means. Keep both, and connect them carefully.

In the hypothetical route-finding project, one method might run faster on the student's chosen maps. The record should identify those maps and the testing conditions. It should not conclude that the method is always faster or better for every transport problem.

Include unsuccessful tests and inconvenient findings. They can reveal limits in the method or suggest the next question. Do not remove a result merely because it complicates the story, and do not present a test on artificial inputs as evidence from real-world deployment.

Attribute help and team contributions

Record who did what while the work is fresh. Distinguish the student's design, implementation, testing and writing from a collaborator's contribution. Describe a mentor's advice accurately. If a tool generated material that was used, keep a record and follow the relevant school, competition or submission rules.

A student should be able to explain the central work in their own words. Documentation is not a way to make work they do not understand appear to be theirs.

Keep personal information out of a public record. A demonstration can use artificial data, and a screenshot can be prepared without exposing private messages or identifiers.

Create a short final explanation

At a milestone, write a one-page summary: question, approach, contribution, main result, limitations and next step. Link it to the underlying working record. This makes a useful starting point for a conversation, activity description or subject-focused reflection.

Only submit project material where an application explicitly permits it, using the requested format. A well-documented project still has value if no admissions reader opens a link: the student can revisit the work, explain it accurately and choose a better next question.