Start with the synthetic worked example or other non-sensitive inputs. Run one prompt at a time in your chosen AI tool. Replace any bracketed placeholders with the requested material, check each reply, and supply the source or earlier outputs that step needs. Paste them again if the tool lacks that context.
Set up the worked example
Open
Open a new conversation in a text AI assistant and keep a document editor ready. This walkthrough uses a fictional project evidence pack. You do not need client files, screenshots or a live portfolio account.
Add the sample
In step 1, replace [paste pack] with all of ‘The starting point’ (Synthetic input), from ‘SYNTHETIC PROJECT EVIDENCE PACK’ through ‘No client name, logo, invented screenshot or invented metrics.’ Include P1–P6 and the required third-person mode. Send steps 1–3 separately in the same chat, checking each reply. In step 4, replace [paste both] with the full step 3 draft under DRAFT, followed by the unchanged complete pack under EVIDENCE. Step 5 uses the corrected draft. ‘The intended result’ and ‘Download the truthful case study’ are authored reference examples, not extra project evidence or work you performed.
Start with the synthetic example, then adapt each prompt to your task.
01
Build an evidence ledger
Start with source records rather than the story you wish the project told. Put proposed work and performed work in different buckets.
Your starting prompt
From evidence P1–P6, build a ledger with claim, source ID, contributor and status: performed, observed, proposed or unknown. Preserve the missing baseline, sample size of two, lack of a second review and non-deployed status. Do not infer commercial results or attribute Ellis’s work to Rowan.
EVIDENCE:
[paste pack]
Expect
An evidence ledger: a list of claims, source IDs, contributors and whether each claim is performed work, an observation, a proposal or unknown. P1–P6 stay attached to the facts.
Check
Rowan wrote the sequence and helper text and made a static prototype. Ellis supplied required questions and reviewed wording. Two volunteers reviewed the prototype; there was no baseline measurement, second review, approved deployment or real submission.
If it differs
If an activity changes owner or an unknown becomes a result, quote P2, P4, P5 or P6 as appropriate and ask for a corrected ledger. Do not infer an improvement just because a revision was made.
02
Choose a story the evidence can support
A small documented decision can be more credible than an unsupported transformation claim. Frame the project around that decision.
Your starting prompt
Propose one case-study angle supported by the ledger: clarifying intake questions through a small prototype review. Draft a title and structure covering context, role, decisions, observations, revision, delivered work and unknowns. Label the project a synthetic demonstration and use third person throughout.
Expect
A title and outline about clarifying intake questions through a small prototype review, with context, roles, decisions, observations, revisions, delivery and unknowns. It should be prominently labeled a synthetic demonstration and written in third person.
Check
Look for wording such as ‘Rowan’ or ‘the prototype’ rather than ‘I built’ or ‘my client’. The angle is supported design work, not a successful launch, paid engagement or measured business transformation.
If it differs
If the outline presents the project as your work or implies a launch, ask for a third-person fictional demonstration with the source status restored. Keep the synthetic label at the beginning, not hidden at the end.
03
Write the complete case study
Tell the reader what changed and why. Use qualifiers where the evidence ends rather than filling the gap with a percentage.
Your starting prompt
Write the full case study using only P1–P6. Include source IDs after factual paragraphs. Explain how each reviewer question led to a specific text change. Separate design intent from measured effects. State that there was no second review, no deployment, no real submission and no operational metric. Do not fabricate testimonials, client identities or screenshots.
Expect
A full case study with source IDs after factual paragraphs. Each reviewer question should be linked to the particular text revision it motivated, with delivered work and unknown effects kept separate.
Check
P4's question about ‘support’ led to help text naming people, materials, space or other help. The blank-contact question led to an optional-in-this-prototype note. No second review checked whether either change resolved confusion. A two-person review does not establish a success rate.
If it differs
If a revision is called a proven fix, ask for ‘responded to the question’ or equivalent supported wording and restore the no-second-review limit. Remove invented metrics, screenshots, testimonials and client identities.
04
Audit verbs and attribution
Words such as launched, improved, led and increased each make a claim. Check their evidence and scope.
Your starting prompt
Audit this draft sentence by sentence for unsupported impact verbs, invented metrics, exaggerated ownership, implied deployment and fake social proof. Return a corrected draft plus a short explanation of every material correction. Preserve the prominent synthetic label and third-person voice.
DRAFT AND EVIDENCE:
[paste both]
Expect
A sentence-by-sentence audit and corrected draft, with explanations of material changes. Every claim about impact, ownership or deployment should have source support.
Check
Check verbs such as ‘launched’, ‘increased’, ‘improved’ and ‘led’ against P1–P6 rather than accepting them as decoration. The proposed next validation is future work; Rowan's contribution and Ellis's contribution remain separate.
If it differs
For a sentence with no support, identify its wording and ask the AI to narrow or remove it. Check that the correction also reaches the title, opening and summary, not just the paragraph containing the first error.
05
Prepare a permission-aware final version
A complete narrative is not publication approval. Make remaining permissions and evidence gaps visible before adapting it to a real portfolio.
Your starting prompt
Return the final case study and a separate publication checklist covering client permission, collaborator attribution, removal of private information, permission for any visuals, exact project status and evidence for outcomes. For this fixture, explicitly state that all records are synthetic and not the author’s experience. Do not publish or imply approval.
Expect
A final third-person fictional case study and a separate checklist covering permissions, attribution, private details, visuals, status and outcome evidence. You can save the checked text locally as a practice document.
Check
The opening still identifies synthetic records and says this is not the author's experience. No output grants client or collaborator permission. The delivery remains a revised static prototype, with no approved deployment, real request or measured operational gain.
If it differs
If the reply says the case study is approved to publish or verified as real work, ask it to correct that claim. Leave publication separate, and retain unresolved evidence or permission items in the checklist.
Optional: improve the result
Maintain an evidence-backed portfolio revision
If later evidence becomes available, update only the claims it supports and preserve what the original work actually was.
Advanced prompt
Compare this case study with the newly supplied project evidence. Propose a revision log with each changed claim, its new source, the observation period and any remaining limitation. Replace “unknown” only where the new record resolves it. Do not retroactively describe a prototype decision as a measured result or imply the author performed later work they did not do.
CASE STUDY:
[paste]
NEW EVIDENCE:
[paste]
Optional: use your own input+
Write from your own permitted project records
Start a new chat with non-sensitive project notes you are allowed to process. Use consistent project and contributor labels; omit private client information, contact details and unapproved visuals. Fill the placeholders below. Check the ledger before sending these messages one at a time: “Propose one case-study angle and outline supported by this ledger. Use my stated project type, authorship and voice; do not imply stronger results.” “Write the case study with source IDs after factual paragraphs. Separate each person's work, observations, revisions, delivery status, measured outcomes, unknowns and proposed next work.” “Audit every sentence against my original records. Correct unsupported impact verbs, metrics, ownership, deployment and social proof; explain material corrections.” “Return the corrected case study and a publication-review checklist for evidence, status, attribution, private details and permissions. Do not imply publication approval.” Check the final story yourself before saving it. The sample's fictional people and missing results are not facts about your project. The original advanced extension stays sample-scoped until its inputs are replaced with your checked case study and genuine new evidence.
Your own-input prompt
Build an evidence ledger from my permitted project records before drafting a portfolio case study. Preserve existing source IDs or assign one to each record. For each possible claim, list the source, contributor and status: performed, observed, proposed or unknown. Use actual supplied sample sizes, dates, outcomes and project status; ask about conflicts rather than inventing a coherent success story. Keep measured results separate from intent, revisions and untested effects. Do not write the case study yet. We will choose a supported angle, draft, audit and prepare a permission checklist in later messages. Return text only; do not publish or share.
PROJECT TYPE, AUTHORSHIP AND VOICE
[State whether this is real work, a personal practice project or a fictional demonstration. State what you personally did, whose perspective to use and any permission limits. Keep fictional work prominently labeled and in third person.]
PROJECT RECORDS
[Paste non-sensitive records of the brief, each contributor's work, decisions, observations, revisions and current status, with source labels if available. Include measured outcomes only with their actual basis; mark absent or unrecorded results.]
KNOWN GAPS AND PROPOSED WORK
[List missing baselines, follow-up checks, approvals or other unknowns. Separately identify future work that has not happened.]
Check your own result
The title and opening accurately state your project's type, your involvement and the chosen voice; fictional work never becomes claimed professional experience.
Every factual paragraph has support in your records. Contributor labels, dates, sample sizes and status match those records together.
A proposed change, a completed revision and a measured improvement remain different claims. Unrecorded results are not supplied as estimates.
Permission to process notes is not permission to publish client material or visuals; unresolved permissions stay visible.
Any later revision uses genuinely new evidence without retroactively claiming work or outcomes that did not occur.
Show, then try
See the shape of the result.
This input is synthetic. The output is a written illustration of the intended result, not a verified AI-tool run.
01 / The starting point
Synthetic input
SYNTHETIC PROJECT EVIDENCE PACK
Project: Clear Route, a fictional volunteer-project request form. This is a practice case study, not a client engagement.
P1, brief: volunteers need to submit a project request with enough context for a coordinator to review it. Existing practice is an unstructured email. No baseline completion or review-time data exists.
P2, role record: Rowan wrote the question sequence and help text, and created a static clickable prototype. Coordinator Ellis supplied the required intake questions and reviewed wording. Rowan did not build a production system.
P3, approved change log: replace the single “Tell us about your project” field with project aim, requested support, constraints and preferred contact method. Add a summary page before the final prototype button. Keep the contact method optional in the prototype because policy is unresolved.
P4, observation notes: two volunteer reviewers walked through the prototype. One asked whether “support” meant people or materials. The other asked whether leaving contact method blank would block the request. No task completion rate, time-on-task measure or satisfaction survey was recorded.
P5, revision: Rowan changed the support helper text to “People, materials, space or another kind of help” and added “Optional in this prototype; final contact policy is still being reviewed.” Both reviewers' questions motivated revisions, but no second review was conducted.
P6, status: prototype review completed; deployment not approved. No real requests were submitted, no measurable operational outcome recorded and no client testimonial supplied.
Required portfolio mode: write in third person so no reader mistakes the fictional Rowan's experience for the author’s own. Label it a synthetic demonstration prominently. No client name, logo, invented screenshot or invented metrics.
Copies text only. For image or file tasks, use the source files named in the steps too.
SYNTHETIC PORTFOLIO DEMONSTRATION
Clear Route: structuring volunteer requests for review
A fictional practice case study. This does not represent the author’s client work or a deployed product.
CONTEXT
The project brief described volunteer requests arriving as unstructured emails. Coordinators needed enough context to review a request, but the team had no baseline completion or review-time data. The design question was how to ask for that context in a more structured way. [P1]
ROLE AND COLLABORATION
Rowan wrote the question sequence and helper text and made a static clickable prototype. Coordinator Ellis supplied the required intake questions and reviewed wording. Rowan did not implement a production system. [P2]
DECISIONS
The prototype separated a broad project-description field into four prompts: project aim, requested support, constraints and preferred contact method. A summary page let reviewers inspect the request before reaching the final prototype button. Contact method remained optional because its final policy was unresolved. These are design decisions, not measured improvements. [P3]
WHAT THE REVIEW REVEALED
Two volunteer reviewers walked through the prototype. One was unsure whether “support” meant people or materials. The other asked whether a blank contact method would block the request. The notes show specific points of uncertainty; they do not establish a completion rate or generalize to all volunteers. [P4]
REVISION
Rowan revised the support help to “People, materials, space or another kind of help” and marked contact method “Optional in this prototype; final contact policy is still being reviewed.” Those changes responded to the two recorded questions. No second review was conducted, so the evidence does not establish that the changes resolved the confusion. [P5]
DELIVERED AND STILL UNKNOWN
Delivered: a revised question sequence, helper text and a static clickable prototype. Prototype review was completed. Deployment was not approved and no real request was submitted. There are no measured effects on completion, coordinator review time or satisfaction, and no client testimonial. [P2, P5, P6]
NEXT VALIDATION STEP
A proposed next step is to settle the contact policy, then observe additional consenting volunteers attempting the revised flow and record clearly defined outcomes. This is a recommendation, not work already performed.
EVIDENCE BOUNDARY
P1–P6 are a synthetic evidence pack. Do not replace the missing metrics with estimates, infer success from the revisions, or present this demonstration as paid work. In a real portfolio, publish only material you have permission to share and accurately separate your contribution from collaborators’ work.
These checks use the worked example and its particular facts. With your own material, check your actual names, numbers, sources and rules; do not reuse the sample’s values as the answer.
Unsaved checks stay in this tab and reset when you reload. If you choose Save guide, its current example checkmarks are kept in this browser when storage is available.
!
A few things to watch for.
Inventing plausible percentages to fit a familiar case-study template.
Presenting an AI-generated demonstration as the author’s professional experience.
Saying the revision fixed the issue when no follow-up test supports that conclusion.