Guide B — Extraction Prompts¶

Questions and Integrity Checks for Your Showcase¶

How to Use This Document¶

This document is not something you complete from top to bottom.

It is a reference you consult deliberately — returning to different sections as your extraction work develops. Use it alongside your Vestigia records and your project artefacts, with the four filters from the previous document in mind.

The prompts here are designed to help you interrogate your material, not to generate content mechanically. Some will apply directly to your project. Some may not apply at all. If a prompt does not open up anything useful, move on.

If a prompt makes you pause — if it raises a question you are not sure how to answer — pay attention to that pause. It usually means something worth exploring.

Hold this principle throughout

Your goal is not to show everything you did. Your goal is to explain what mattered — and why. Extraction is an act of judgement, not transcription.

Decision Prompts¶

Use these to identify decisions worth including in your showcase.

From your records, ask:

◆ Which decisions most significantly shaped what the project became?
◇ Which decisions required you to choose between two or more credible options?
◆ Which decisions would raise questions if you left them unexplained?
◇ Which decisions did you feel least certain about at the time?

For each candidate decision, push further:

What was at stake when this decision was made?
What information was incomplete or uncertain at the time?
What trade-off did you accept, and what did you give up?
What changed in the project as a direct result of this decision?

A decision belongs in your showcase only if it created consequence — if something about the project is different because of how you decided.

Learning Prompts¶

Learning is often invisible until you look for it specifically. Use these prompts to find where it is in your material.

From your Vestigia records, ask:

◆ Where in my records did my understanding shift noticeably?
◇ Which assumptions did I hold at the start that I later revised or abandoned?
◆ What did I struggle with early that became clearer by the end?
◇ Which entries show a different level of understanding than entries from earlier in the project?

From your project artefacts, ask:

Where is the learning visible in the output?
What improved — technically, methodologically, or analytically — as the project progressed?
What would have been weaker or different if I had built it in the first month instead of the last?

Learning is not a catalogue of tools you used or skills you practised. It is change over time — a before and an after that you can point to in both your records and your work.

Problem and Resolution Prompts¶

Do not hide difficulty. Do not dramatise it either. The aim is to identify problems that produced insight — not every obstacle, but the ones that genuinely changed the project or changed you.

From your records, ask:

◆ Which problems forced a change in approach, design, or strategy?
◇ Which failures led to better decisions later?
◆ Which obstacles reshaped your plan, scope, or direction?

For each problem you identify, connect it forward:

What exactly went wrong, and when?
Why did the original approach fail?
What did you modify, rethink, or replace as a result?
How did the final outcome benefit from how you handled it?

A problem without a resolution or learning outcome does not belong in your public narrative. Include difficulty because it demonstrates growth — not because it demonstrates that the project was hard.

Contribution Prompts¶

These prompts are essential if your project was collaborative.

Your showcase is individual. You need to be able to distinguish your contribution from the collective work of the team — honestly and specifically.

From your Vestigia records, ask:

◆ What did I initiate rather than inherit from the group?
◇ What did I take responsibility for from start to completion?
◆ Where did my decisions influence the group's direction?
◇ What would be missing or different in the project if I had not been there?

From your project artefacts, ask:

Which components reflect my direct input?
Where is my thinking traceable in the final deliverable?
Which sections of documentation did I author or shape significantly?

Then ask the fairness check:

If a teammate read my account of my contribution, would they consider it accurate?
Am I claiming sole credit for work that was genuinely shared?
Am I deflecting credit for work I genuinely led?

The aim is not to maximise what you claim. It is to represent what you did with enough specificity that a reader — or an interviewer — can understand it clearly.

Reflection Prompts¶

Reflection is not a summary of what happened. It is an account of how you changed.

Use these prompts to identify genuine reflective material — not performance, not polish:

◆ What did I believe at the start of this project that I no longer believe, or believe differently?
◇ What surprised me — about the work, the process, the team, or myself?
◆ What would I do differently if I were starting this project again?
◇ What am I more confident in now than I was at the start?
◆ What am I still uncertain about, and why does that uncertainty matter?

On authentic reflection

The reflection that resonates in a showcase or an interview is the kind that sounds like it came from a real experience. "I learned the importance of communication" is not reflection — it is a placeholder. "I learned that a decision I made without consulting the team cost us two days of rework, and I now understand how early misalignment compounds" is reflection. The difference is specificity and consequence.

Integrity Checks¶

Run these before you finalise any material for public sharing.

On accuracy¶

Is every claim I am making something I can support with a specific example or artefact?
Am I describing what I actually did, or what I wish I had done?
Is the language I am using accurate — or am I using impressive-sounding words to describe ordinary work?

On collaboration¶

Have I made the collaborative nature of the project clear where it is relevant?
Am I using "I" for work that was genuinely shared without acknowledging that?
Would my teammates recognise my account of the project as fair?

On scope¶

Is the project's context clear to someone who knows nothing about my institution or subject?
Am I providing enough background for claims to make sense — without reproducing confidential content?
Have I checked whether any client, partner, or institutional confidentiality requirements apply?

On defensibility¶

Could I answer follow-up questions about everything I have included?
Is there anything here I would struggle to explain if pressed in an interview?
If the answer to either of the above is uncertain, does the content need to be revised or removed?

A Final Prompt¶

Before you begin structuring your showcase, read back through everything you have extracted and ask one last question:

Does this represent the project I actually worked on, and the person I became while working on it?

If yes — proceed. If anything feels inflated, evasive, or borrowed from someone else's experience — revise it now.

What you publish carries your name. It should carry your story.

Continue to From Fragments to Showcase to begin structuring and presenting your material.