Guide B — From Records to Narrative¶

Extraction, Filtering, and the Two Inputs¶

What This Guide Asks You to Do¶

Guide A asked you to pay attention while working.

Guide B now asks you to make deliberate choices about what you captured. Specifically, you are learning to decide:

◆ what to extract from your Vestigia records
◇ what to extract from your formal project artefacts
◆ what to connect between the two
◇ what to leave out entirely

This guide does not teach you how to write your final showcase. It teaches you how to think before you write.

That distinction matters. Students who jump straight to writing produce showcases that are either too long, too generic, or too disconnected from the actual project. The extraction work you do here is what makes the writing possible — and honest.

The Two Inputs¶

Everything you present publicly or professionally should emerge from two sources. Before you extract anything, be clear about which source you are drawing from and what it can reasonably provide.

Input 1 — Your Vestigia Records¶

These are your working traces — the notes, decisions, reflections, pivots, and problems you recorded during the project. They represent how you thought.

They are personal, contextual, often messy, and written for yourself in the moment. They are not ready for presentation as they stand — but they contain the raw material that no formal report can produce: the reasoning behind decisions, the honest account of what went wrong, the moment your understanding shifted.

What Vestigia records are good at providing:

◆ decision rationale — why you chose one path over another
◇ learning trajectory — how your understanding changed over time
◆ honest failure accounts — what went wrong and what you took from it
◇ individual contribution evidence — what you specifically initiated and worked on

Input 2 — Your Project Artefacts¶

These are the formal outputs required by your subject or project: proposals, reports, designs, code repositories, implementations, evaluations, presentations, sprint documentation, meeting minutes, and WIL records. They represent what was delivered.

They are structured, assessed, and shared with supervisors, clients, or markers. They carry credibility because they are verifiable — someone else has seen and evaluated them.

What project artefacts are good at providing:

◆ evidence of outcomes — what was actually built or produced
◇ proof of process — that certain work happened within a defined timeframe
◆ shared context — the project's scope, requirements, and deliverables
◇ external validation — that your work met a standard beyond your own assessment

The Mistake to Avoid¶

Many students rely on one input and ignore the other.

Using only artefacts produces a showcase that describes what happened but cannot explain why. The thinking is absent. The reflection is generic. The contribution is indistinguishable from any other student on the same project.

Using only Vestigia records produces a showcase that feels personal and reflective but lacks grounding. There are no outcomes to point to. Claims cannot be verified.

Guide B exists to help you connect both inputs into something that is simultaneously honest and credible.

The Extraction Filters¶

Extraction is not a summary of everything you did.

It is the act of identifying moments of significance — the decisions, problems, and learning that actually shaped the project and demonstrate your engagement with it.

Think of the following as filters, not sections. You are not expected to produce content under each one. You are using them to search your material for what is worth keeping.

Filter 1 — Decisions¶

Look through your records and artefacts for decisions that shaped the project's direction — not routine choices, but the ones where alternatives were genuinely considered and a path was chosen for reasons you can explain.

Ask yourself:

◆ Which decisions changed what the project became?
◇ Which decisions required genuine trade-offs or accepted risks?
◆ Which decisions would raise questions if I left them unexplained?
◇ Which decisions excluded alternatives that might have worked?

For each decision you identify, you should be able to explain:

what was decided
what the alternatives were
why this path was chosen
what was accepted as a trade-off or risk

Decisions that meet this standard are the intellectual core of a strong showcase. They demonstrate that you were not just executing tasks — you were thinking.

Decisions that had no real alternatives and no real risk are routine. They do not need to be there.

Filter 2 — Learning¶

Learning is present in every project, but it is usually implicit. Students who cannot articulate their learning tend to describe activity instead — a list of things they did rather than an account of how they grew.

From your Vestigia records, look for:

◆ moments where an assumption was challenged or overturned
◇ points where your understanding of the problem deepened significantly
◆ skills that developed noticeably across the project
◇ entries where your approach changed because you understood something better

Then look for where that learning is visible in your artefacts:

a design that improved after feedback or failure
an implementation that became more robust after a debugging session
a report section that became more precise after you understood the domain better
a strategy that shifted after user research disconfirmed the original premise

Learning is not a catalogue of tools you used or technologies you touched. It is change over time — and it is only convincing when you can point to both the moment it happened and where it shows up in the work.

Filter 3 — Problems and Resolutions¶

Difficulty is expected in a final-year project. Hiding it makes a showcase less credible, not more professional. Employers and supervisors understand that projects encounter problems — what they want to see is how you handled them.

From your records, identify problems that:

◆ forced a change in your approach, design, or strategy
◇ produced an insight that genuinely improved the project
◆ required you to think in a way you had not before

For each problem, connect it to its resolution:

what exactly went wrong
why the original approach failed
what was modified, rethought, or replaced as a result
how the final outcome was affected

Problems that have no resolution and no learning attached to them do not belong in a public showcase. Include difficulty because it demonstrates growth — not because it demonstrates that the project was hard.

Filter 4 — Contribution¶

This filter is especially important for group projects. Your showcase is individual even when your project was collaborative — which means you must be able to distinguish your contribution from the shared work of the team.

From your Vestigia records, identify:

◆ what you initiated rather than inherited from the group
◇ what you took responsibility for from start to completion
◆ where your decisions influenced the group's direction
◇ where your work would leave a visible gap if removed

From your project artefacts:

which components reflect your direct input
where your thinking is traceable in the final deliverable
which sections of documentation you authored or shaped significantly

This is not about claiming sole credit. It is about being specific and honest about what your work actually involved. Vague collective language — "we built," "the team decided" — is not useful in an individual showcase. It tells an employer nothing about you.

The contribution trap

In group projects, there is a common temptation to either claim too much ("I built the entire backend") or deflect too much ("we all worked on everything together"). Both are problems. The first is dishonest. The second is unhelpful to you and unconvincing to anyone reading it. Be specific: what did you initiate, own, and see through? What did you contribute to alongside others? The distinction is normal and professional.

What to Leave Out¶

A strong showcase is defined as much by exclusion as by inclusion.

Once you have applied the filters above, you will likely have more material than you need. Some of it will not make the cut. That is correct.

Actively exclude:

◆ routine activity with no learning or decision value
◇ work done exclusively by others that you cannot speak to
◆ repeated struggles that produced no insight
◇ raw notes that would require extensive explanation to be useful
◆ anything you could not confidently defend in a conversation

Exclusion is not dishonesty. It is discernment.

The purpose of a showcase is not to present a complete record of the project. It is to present a coherent, honest account of your engagement with it. Restraint in selection is a sign of professional judgement, not incompleteness.

From Fragments to Narrative¶

After applying the filters, you will have a collection of significant moments — decisions, learning, problems resolved, contributions made.

Your next task is to connect them.

A narrative is not a list of these moments. It is an explanation of how they relate — how a decision led to a problem, how the problem produced a learning moment, how that learning improved the outcome. Chronology alone is not enough. Meaning comes from cause, consequence, and reflection.

Ask yourself:

◆ Where did the project start, and how did my understanding of it change?
◇ What shaped the project's direction most significantly?
◆ What did I contribute that would not have happened the same way without me?
◇ What would I do differently, and what does that tell me about what I learned?

The answers to these questions are your narrative. Not a summary of the project — a story of your engagement with it.

Integrity in Extraction¶

As you extract and connect material, hold these principles throughout:

◆ accuracy matters more than impressiveness
◇ attribution matters more than visibility
◆ explanation matters more than technical terminology

You are not presenting a perfect project. You are presenting a thoughtful one.

A showcase that is honest about difficulty and specific about learning is far more compelling to a potential employer or supervisor than one that claims everything went well and every decision was right. The honest account is the more credible one — and the more memorable one.

If something you want to include is genuinely ambiguous — shared contribution, uncertain outcome, incomplete resolution — address that ambiguity directly. Clarity about what you know and what you do not is itself a professional quality.

Preparing to Structure¶

Once your extraction work is done, you will be ready to think about how to organise and present what you have found. Before moving to structure, make sure you have:

◆ a small set of high-significance decisions you can explain fully
◇ a clear account of how your learning changed over the project
◆ specific evidence of your contribution linked to real artefacts
◇ an honest account of at least one significant problem and its resolution

If any of these feel vague or incomplete, return to the relevant filter. Structure built on incomplete extraction produces hollow showcases — ones that look organised but say very little.

Continue to Extraction Prompts for specific questions to guide your work through the filters.