Guide B — Integrity and Attribution¶
Representing Your Work Honestly and Professionally¶
Why This Document Exists¶
Guide B has helped you extract what matters, connect it into a narrative, and think about how to structure and present it.
This document exists to help you do all of that responsibly.
Final-year projects sit at an unusual intersection: they are simultaneously academic work, collaborative effort, professional evidence, and public representation. Each of these contexts carries its own expectations — and they do not always point in the same direction.
Integrity is not a constraint on good showcases. It is what makes them credible. A showcase that misrepresents contribution, obscures collaboration, or exaggerates impact does not become more impressive because of it — it becomes fragile. It cannot survive scrutiny. It cannot support a real conversation. And it cannot do the one thing a showcase is actually for: help you get the opportunities you want, and be ready for them when they arrive.
Integrity Is About Accuracy, Not Modesty¶
A common misunderstanding is that professional integrity requires downplaying your contribution — hedging, understating, attributing everything to the team.
This is not correct.
Integrity requires accuracy. An accurate account may describe substantial individual responsibility, clear leadership, and significant impact. It should. An inaccurate account may describe very little — or far too much.
What integrity asks is not that you minimise, but that you represent:
◆ what you actually did — specifically and honestly
◇ what others contributed — acknowledged clearly and fairly
◆ what the project produced — grounded in verifiable evidence
◇ what you genuinely learned — without performance or exaggeration
Truthful representation can be confident. When it is grounded in specific evidence and honest about context, it usually is.
Individual Contribution in Collaborative Work¶
Most final-year projects are group-based. Presenting your work individually after a collaborative project is appropriate, expected, and professionally normal — but it requires care.
You are presenting as an individual. You are not presenting your group. This means you need to be specific about what you were responsible for, while making the collaborative context visible.
What you are responsible for explaining:
◆ what you owned or led
◇ what you contributed to or implemented directly
◆ where your decisions influenced the project's direction
◇ where the work was genuinely shared
What you are not required to do:
◆ present the entire project as your own work
◇ diminish your contribution to avoid seeming to claim too much
◆ reproduce work done by teammates as your own individual evidence
The test is this: if a teammate read your showcase, would they recognise your account of the project as fair and accurate? If yes, proceed. If you are uncertain, revise toward clarity — not toward either inflation or deflation.
The ambiguity of 'we'
Vague collective language — "we built," "the team decided," "it was agreed" — tells a reader nothing about you specifically. It may feel safe, but it is not useful. If you did something, say you did it. If you did it with others, say that too and describe what your part was. The difference between "we built the backend" and "I designed and implemented the authentication module as part of the backend, working alongside [name] who handled the data layer" is the difference between a collective description and an individual account.
Attribution in Practice¶
The following principles guide practical attribution decisions.
Attribute specifically, not collectively¶
Where work was collaborative, say so clearly:
- who was involved
- how responsibility was distributed
- what you contributed within the shared effort
This is not about listing every person's contribution exhaustively. It is about not hiding the collaborative nature of work behind language that implies sole authorship.
Reference shared artefacts without reproducing them¶
You may and should reference:
◆ shared repositories
◇ group reports or documentation
◆ collective presentations or demonstrations
◇ team project websites or shared portfolios
What you should not do:
◆ reproduce group submissions as your own content
◇ copy sections from shared reports into your individual showcase without qualification
◆ present collective artefacts as evidence of your individual work alone
Linking outward is almost always better than reproducing. A link to a shared repository says: here is the work we produced together, and here is what I specifically contributed within it. Reproduction without attribution says something less honest.
Use language that describes your involvement accurately¶
Prefer language that is specific:
◆ "I designed and implemented the authentication module"
◇ "I led the user research phase and developed the persona framework"
◆ "I was responsible for the database schema design and the API layer"
◇ "I contributed to the frontend development, specifically the dashboard and reporting components"
Avoid language that overstates:
◆ implying you built or designed something you contributed to but did not own
◇ using "I" for work that was genuinely shared, without qualification
◆ omitting the team context to make your individual contribution appear larger
Precision is a professional quality. Readers who know the field will notice when claims are vague. Readers who are evaluating you will respect someone who can describe their work specifically and honestly — even if the scope was modest.
Public Presentation — CVs, LinkedIn, Portfolios¶
When you share work publicly, you are writing for an audience that may include potential employers, recruiters, academic supervisors, professional peers, and future collaborators.
These readers bring no prior knowledge of your project, your institution, or your team. They also may not raise questions if something feels unclear — they simply move on, or they ask a question in an interview that you are not prepared for.
Before publishing or sharing, consider:
◆ Is the project's context clear — what it was, who it was for, at what scale?
◇ Is the collaborative nature acknowledged where relevant?
◆ Are the claims specific enough to be credible?
◇ Is there evidence I can point to for every significant claim?
An effective approach is to frame at the project level first — "this was a final-year group project building X for Y context" — and then zoom into your individual contribution within that frame. This gives readers the context they need to evaluate what follows, and it makes the individual contribution more legible, not less.
Confidentiality and Institutional Agreements¶
Some final-year projects involve real clients, industry partners, or sensitive data.
Before publishing any aspect of your work publicly:
◆ check whether a confidentiality or non-disclosure agreement was signed
◇ confirm with your supervisor what can and cannot be shared publicly
◆ consider whether data, screenshots, or code contain sensitive information
◇ respect any agreements made between your institution and a project partner
This is not a reason to avoid sharing your work. Most projects can be described publicly without exposing confidential content. Your account of what you decided and what you learned does not usually require reproducing the client's data, internal documents, or proprietary systems.
When in doubt, describe the work at a level of abstraction that is honest but does not breach any agreement. And ask your supervisor if you are uncertain — before publishing, not after.
What Integrity Looks Like in Practice¶
A showcase has integrity when:
◆ a supervisor could follow your narrative and recognise the project in it
◇ a teammate would read your account of your contribution and consider it fair
◆ you could defend every claim verbally, specifically, in a conversation
◇ the evidence you reference actually supports what you claim
Integrity is compromised when:
◆ contribution is exaggerated through vague language or selective omission
◇ collaboration is obscured in order to appear more individually responsible
◆ context is removed to make claims appear more impressive than they are
◇ evidence is absent for claims that require it
If you find any of these in your draft, correct them before publishing. The risk of an inaccurate showcase is not only ethical — it is practical. Interviews surface inconsistencies quickly. Professional networks are smaller than they appear.
Final Checks Before Publishing¶
Before you share your showcase in any public or professional context, run through these questions:
◆ Have I clearly framed the collaborative nature of the project where it is relevant?
◇ Can I support every significant claim with specific evidence or example?
◆ Have I used language that describes my involvement accurately, not impressively?
◇ Would I be comfortable if a supervisor, teammate, or employer asked follow-up questions about anything here?
◆ Have I respected any confidentiality requirements?
If you can answer yes to all of these, your showcase is ready.
In Summary¶
Integrity in a showcase means accuracy over ambition, explanation over assertion, and collaboration acknowledged without being used as a shield against specificity.
Your goal is not to impress. Your goal is to represent your work in a way that is honest, specific, and defensible. That is what makes a showcase worth having — and worth reading.
Guide B is complete. If your project was a group project and your team wants to build a collective outward-facing presence, continue to Shared Presence.