A proof library is the set of records you can safely quote on your website, in proposals and on the phone. It answers a buyer's fair question: what backs that up? We'd take five records that say what happened, who approved publishing it and what it proves over a big folder of screenshots.
We hold our own site to the same rule. Every inquiry figure we publish for Garrison, the microsite software from Trojan Digital Marketing, keeps the trade, the count, the number of Indiana sites and the dates together. We call them inquiries because those records don't show which became jobs. This guide covers deliverables, photos, customer statements, measured results and credentials, and treats each as a different kind of proof.
Begin with the decision the proof should support
- Question
- Identify what the customer needs to know.
- Answer
- Explain it clearly.
- Evidence
- Support the answer with a source.
Choose one service and list the questions a prospective customer asks before contacting you. They may want to see a relevant design, understand the project process, check whether you have handled a similar constraint, or examine an outcome measured over a defined period. Each question calls for a different kind of evidence.
A portfolio image can show the appearance of a completed deliverable. It cannot establish how many customers bought because of it. A customer statement can describe that person's experience. It does not automatically establish the experience every customer should expect. Make these distinctions before you write sales copy. Our Jerry Super case study shows why. We edit every video on Jerry Super's YouTube channel, so when we talk about its growth we say it grew while we edited every video. We don't claim every view as ours.
Our broader guide to content that builds authority and supports buyer decisions explains how proof fits the page's purpose. Use the library to resolve relevant uncertainty, then offer a next step that matches the service.
1. Inventory evidence before writing the claim
We start by gathering what already exists: the agreed scope, approved deliverables, dated photos, measurement exports, customer permissions and current credential records. Then we name the person who knows each source best. A file sitting in a shared drive isn't cleared for public use yet.
Keep private operational evidence separate from the public asset. An internal agreement may establish the work completed without being suitable for publication. The public case study can describe the supported scope while the internal record allows the team to check it later.
We mark gaps out loud. If a campaign had no reliable starting number, we don't invent one to fit a case study template. A case can still explain the problem, the choices, the deliverable and when it was finished, and leave money results out.
2. Classify what each source can establish
| Evidence | Useful claim | Boundary to preserve |
|---|---|---|
| Approved deliverable | What the team created or changed | Completion does not prove commercial impact |
| Dated project photograph | Visible work at the documented stage | Image selection and context affect interpretation |
| Measurement record | A defined observation for a stated period | Attribution and causation need separate support |
| Customer statement | The speaker's reported experience | Do not expand it into a universal result |
| Credential record | Current status within the issuing body's scope | Entity, service, location, and expiry matter |
Use the classification to choose the wording. Designed, implemented, observed, reported, and certified communicate different facts. A careful verb often prevents a larger misunderstanding without making the page difficult to read.
3. Create a claim record that survives reuse
We give each reusable claim a short ID and write out its exact approved sentence. Record the business or project it describes, the service scope, relevant geography, date or period, source location, reviewer, and any conditions on use. Link the record to the public pages where the sentence appears.
The record should also identify the narrowest wording the evidence supports. For a hypothetical project, an approved claim might say the team produced a bilingual department sign system. An unsupported extension would say the signs increased sales if no reliable sales analysis exists.
Include a review trigger. A credential may expire on a known date; a service claim may change when the offering changes; a case study image may require review if permission changes. A generic annual reminder alone can miss an important change that happens tomorrow.
The business facts maintenance playbook extends this record into a broader publishing system. Your proof library and general business facts should agree about names, services, dates, and source ownership.
4. Write a case study around documented decisions
Use a structure that follows the work: the customer's situation, the agreed objective, relevant constraints, the work performed, and the result that can be documented. Explain why the team made a meaningful choice. A reader learns more from a specific constraint and response than from repeated claims that the project was innovative.
Distinguish the original objective from the observed result. A brief may aim to improve visibility, simplify navigation, or encourage inquiries. Those are project goals until the team has evidence of the corresponding outcome. Labeling the goal clearly preserves useful context without presenting it as a measured success.
Include what a similar buyer can reasonably learn. A design case may demonstrate how the team worked within an established color system. A website case may show how a confusing inquiry route was clarified. Neither needs an invented revenue figure to be informative.
5. Use the Georgetown Market example within its actual scope
The Georgetown Natural Foods Market case study covers a brief for more than 30 bilingual grocery signs in the store's three brand colors. Jeff Clerisier, our founder, designed them in his two years as its marketing director, when he was also assistant store manager there (July 2023 to July 2025). Those details support a talk about store signs and consistent design.
The case should remain evidence of that work. It should not be presented as proof of SEO growth, additional store visits, or increased sales when those outcomes are not documented. A retail page can link to the case when discussing signage and the connection between department language and the store experience.
This is a useful model for an evidence boundary: retain the concrete work, show the relevant visual material, and avoid adding outcomes merely because they would make the story sound larger. The buyer can evaluate the demonstrated capability on its own terms.
6. Treat metrics as records with definitions
- Event → record
- Define the event and check the record.
- Meaning → decision
- Review the business meaning before acting.
Before publishing a number, identify the metric, source, unit, period, and comparison. Ask whether it counts events, people, inquiries, orders, or something else. Record whether the period is complete and whether the underlying tracking definition changed.
For a hypothetical example, a business might record 30 service inquiries in one period and 36 in another. The arithmetic increase is 20 percent. That calculation alone does not explain the reason, establish that all requests were suitable, or show an increase in completed work. The public wording should not imply those additional findings.
Preserve the relevant denominator and caveats near the number. If the team has only a selected group of projects or a short observation window, describe that scope. Avoid combining unlike periods or sources into a single trend line without a defensible reconciliation.
Our article on measuring content assisted inquiries explains why a content touchpoint should not automatically receive sole credit for a result. Use it when a proposed case study connects website activity to later business outcomes.
7. Keep photographs and illustrations truthful
Record who supplied each image, what it shows, when it was captured if relevant, and the permission for public use. Keep an original copy so editors can distinguish legitimate cropping or formatting from changes that alter the apparent work.
A before and after pair should make its context understandable. Differences in angle, lighting, stage, or scope can change what a viewer concludes. Explain material differences instead of relying on a dramatic visual comparison to carry an unsupported claim.
Label an illustration or hypothetical concept when a reader could mistake it for a completed client project. Do not use a generated scene as photographic evidence of work, equipment, personnel, or a customer relationship. Visual clarity is part of the evidence standard.
8. Preserve the meaning of customer statements
Keep the original statement and the approved public version together. Editing for length should not change the meaning or remove an important qualification. Confirm the attribution and permission the business is entitled to use.
The FTC's endorsement guidance emphasizes honest experience and clear disclosure of material relationships. It also cautions against using an endorsement to make a claim the advertiser could not support directly. Treat a quote as evidence of the speaker's experience, with its relevant context.
If permission or wording is uncertain, resolve that before publication. A placeholder testimonial is not a harmless design device once it becomes public. Use an actual project explanation while the statement is being reviewed.
9. Place proof beside the question it answers
- Fit
- Explain the service scope.
- Trust
- Show supporting evidence.
- Next step
- Give a clear contact route.
A service page can include one relevant project excerpt and link to the full case. A process section can show a sample deliverable. A pricing explanation can clarify what was included in a documented scope. These placements help visitors use the evidence during a decision.
Avoid repeating the same impressive looking figure across unrelated services. Reuse should preserve the original project and scope. The article on adding proof to service pages provides a focused review method.
For SEO, AEO, GEO, and AI SEO, keep the public explanation and any structured data consistent. Google's structured data policies require relevant, truthful content that represents the visible page. Markup is not a place to add unsubstantiated awards, reviews, or results, and it does not guarantee a search appearance.
10. Build a practical approval and correction loop
Assign a content owner to assemble the case, a subject owner to verify the work, and an authorized reviewer for publication permissions. A small team can combine roles, but it should still answer each question explicitly.
Before publishing, review the headline, image captions, summary, chart labels, social excerpt, and metadata together. A careful body can be undermined by a headline that turns an objective into a guaranteed result. Check every place the claim is presented.
After a correction, update the claim record and the pages that reuse it. Preserve a short change note explaining what was corrected and why. Removing one sentence from the case study will not resolve the problem if a service page or downloadable proposal still repeats it.
Five questions about building a proof library
Can a case study be useful without a revenue result?
Yes. A documented problem, meaningful constraints, actual work, and clear deliverables can demonstrate relevant capability. Publish the outcome the evidence supports.
Should every project become a public case?
No. Choose cases with a useful buyer lesson and appropriate permission. Internal records can support verification without becoming public content.
Can a testimonial replace measurement?
It can describe an experience, but it does not automatically establish a quantified or typical outcome. Keep those evidence types distinct.
Does a source link verify a claim automatically?
No. A reviewer must check that the source supports the exact wording and scope. The AI Answer Kit organizes supplied facts and links; it does not perform that verification.
What should the first proof library project produce?
Start with one service, a small evidence inventory, one approved case, and a record of every public reuse. That provides a manageable maintenance process.
Make your next case study easier to assess
Bring the source materials for one completed project to Trojan Digital Marketing. We can discuss how website design and search content services can present the work clearly. A free audit can identify where existing proof needs a stronger connection to a buyer's question.
