Guide A — The Guide¶
Recording the Work as It Happens¶
Why This Guide Exists¶
Most final-year projects fail to document how the work happened.
Not because students do not work hard — but because the thinking, the decisions, the revisions, and the failures are rarely captured while they occur. By the time reports are written and reflections submitted, the real story has already been flattened into something tidier, safer, and less true.
Vestigia Guide A exists to help you:
◆ record your project as a living process
◇ preserve the thinking behind your decisions
◆ reduce the pressure at report-writing and reflection time
◇ build a body of honest, usable material for your professional showcase
This guide is not about writing more. It is about writing earlier, lighter, and honestly.
Who This Guide Is For¶
Guide A is written with these students primarily in mind:
◆ Computer Science and Information Technology
◆ Engineering — software, electrical, mechanical, systems
◆ Applied computing, data science, and AI projects
The practices described here also apply to:
◇ research-led and interdisciplinary projects
◇ applied business, marketing, and industry projects
◇ education, design, and UX-centred work
If your project involves thinking, deciding, building, and iterating — this guide applies to you.
What You Are Expected to Record¶
You are not recording everything.
You are recording meaningful moments in the work — moments where something was decided, discovered, challenged, or clarified.
The five categories below define what is worth capturing. Think of them as lenses, not a checklist. A single entry might touch two or three of them at once. That is fine. What matters is that the moment is recorded, not that it is filed under the correct heading.
Category 1 — Direction and Intention¶
Record moments where you decide or revise what you are trying to do.
This includes:
◆ defining or refining your problem statement
◇ clarifying goals with a client, supervisor, or teammate
◆ narrowing scope or adjusting ambitions
◇ deciding what is explicitly out of scope
For each entry, write briefly:
- what you are aiming for at this point
- why this direction matters
- what assumptions you are currently making
These entries become important when your direction changes later. They establish that you made deliberate choices at the time — not random ones, and not choices made in hindsight.
Category 2 — Decisions and Trade-offs¶
Every project involves choosing one path over others. These choices are often invisible in final reports. Vestigia makes them visible.
Record decisions involving:
◆ technical choices — frameworks, tools, languages, architectures
◇ design choices — interfaces, data structures, system components
◆ methodology — research approaches, testing strategies, Agile practices
◇ scope — what to include, what to defer, what to drop
For each significant decision, capture:
- what you chose
- what alternatives you considered
- why you decided this way
- what risks or limitations you accept as a result
This applies whether you are choosing a database, a research method, a design pattern, or a project management approach. The discipline differs; the habit is the same.
What makes a decision worth recording?
Not every choice is a decision. A decision worth recording is one where alternatives genuinely existed, where you had to weigh something, or where you accepted a known trade-off or risk. If a question had only one reasonable answer, it probably does not need its own entry. If the question was genuinely difficult, it almost certainly does.
Category 3 — Work Performed¶
Record what you actually did — not what you planned, and not a diary of the day.
Useful entries here include:
◆ features implemented or modules completed
◇ tests run and their outcomes
◆ meetings held — client, supervisor, team stand-up
◇ documentation produced or updated
◆ experiments, prototypes, or drafts created
Write short summaries that answer:
- what changed or moved forward since your last entry
- what blocked or slowed progress
- what the current state of the work is
For group projects, be explicit about your individual contribution within shared work sessions. "The team completed the authentication module" is not as useful as "I implemented the token refresh logic while [name] worked on the login UI." The former documents what the group did. The latter documents what you did — which is what matters for your individual record and your individual showcase.
Category 4 — Problems, Failure, and Rework¶
Failure is not something to hide. In Vestigia, it is required material.
Record:
◆ things that did not work — technically, logically, or practically
◇ bugs, dead ends, and invalid assumptions
◆ designs or approaches you tried and abandoned
◇ moments where your plan had to change significantly
For each failure or problem, note:
- what failed or went wrong
- why you think it happened
- what you learned from it
- what you will try next
Do not skip failure entries
This category is often the most valuable part of an entire project record. It demonstrates thinking under pressure, adaptability, and genuine engagement with the problem. Employers and lecturers can distinguish between a project that claims to have had no problems and one that encountered them honestly and responded thoughtfully. The honest account is the more credible one.
Category 5 — Reflection in Motion¶
Do not save reflection for the end of the project. Record it as it happens.
Throughout the project, note:
◆ moments of genuine insight or realisation
◇ shifts in your understanding of the problem
◆ skills that developed noticeably
◇ changes in confidence, approach, or strategy
Simple prompts that work well:
- I expected X, but found Y.
- This changed how I think about...
- If I were starting this section again, I would...
- What I still don't fully understand is...
These short, honest observations become the raw material for reflection sections in reports, individual assessment components, presentation narratives, interview responses, and your professional showcase. Written at the time, they are specific and credible. Reconstructed at the end, they are generic.
How Often to Write¶
There is no fixed rule. Consistency matters more than length.
Use these as reliable triggers:
◆ after a meaningful work session
◇ after a key decision is made
◆ after a problem, failure, or breakthrough
◇ after a meeting — with your client, supervisor, or team
◆ at the end of each sprint or project milestone
◇ at minimum, once per week
A short, honest entry written regularly is far more useful than a long, polished entry written from memory weeks later.
If you miss a period, do not reconstruct it. Simply note that there is a gap, briefly explain why, and resume from where you are. Gaps are honest. Reconstruction is not.
Sprint boundary habit
If your project runs in Agile sprints, the sprint review and retrospective are natural moments for a substantive Vestigia entry. What did this sprint deliver? What decision was made in the retrospective? What is the team carrying into the next sprint? Three minutes of writing at the sprint boundary produces a record that would take thirty minutes to reconstruct a month later.
Format and Tools¶
Vestigia does not prescribe a specific tool or format.
You may use:
◆ Markdown files in a private or shared repository
◇ a digital notebook — Notion, OneNote, Obsidian, or similar
◆ a document tool — Google Docs or Word
◇ a physical notebook, if that suits your thinking style
What matters is that your records are:
◆ dated — every entry has a date
◇ sequential — entries build on each other over time
◆ readable later — written clearly enough that you can understand them in two months
◇ honest — not polished for an audience, not retrospectively edited
Do not rewrite history. Do not polish entries to make them look better than the moment was.
Vestigia values process over presentation. The record is for you first. Its value comes from its accuracy, not its tidiness.
Guide A and Your Subject Requirements¶
Vestigia sits outside your formal subject requirements. It does not replace any documentation your subject requires — proposals, sprint logs, meeting minutes, progress reports, reflective journals.
What it does is complement and strengthen those requirements.
When you keep good Vestigia records:
◆ your proposal justification sections become easier to write
◇ your meeting minutes carry more context
◆ your sprint retrospectives become more specific
◇ your reflection submissions become more authentic
◆ your final report has a traceable foundation
Think of it this way: the documentation your subject requires captures what was delivered. Vestigia captures how you thought while delivering it. Both are needed to tell the full story of a project. Only one of them is usually missing.
A Final Note¶
Vestigia is not something you submit.
It is something you use.
The habit you are building here — of paying attention to your work while you are doing it — is one of the most transferable professional skills a graduate can have. Most students finish their final-year project and struggle to explain what they actually did and why. You will not have that problem.
Guide A is where that advantage begins.
When your project is complete and you are ready to present your work professionally, continue to Guide B.