Write the promise and proof

Complete Name the audience and buying moment first.

A brand promise says what people should remember. Proof keeps the promise from becoming a slogan. This lesson asks you to make a promise and proof pair, not a vague creative preference. The output should be specific enough that Claude, Canva, Adobe Express, Claude Design, or a designer can use it without guessing.

Here is the before and after: Before, the brand says it is trusted, premium, fast, or creative without showing why. After, each promise has proof: work samples, founder experience, customer quotes, process details, or measurable results. For example, a solo service brand should show who it helps, what promise it makes, what proof supports that promise, and where the identity must appear first. A company brand should add rules for collaborators, templates, and repeated use.

Now try it: Ask Claude for promise options, then force every promise to carry proof. Make one choice before asking Claude to write: audience, promise, reference, asset type, tool, launch context, or review risk. That choice keeps the work from turning into generic brand inspiration.

The lesson is done when the artifact can guide a real brand asset and survive one honest review.

Use this brand job and audience moment: [paste]. Give me five brand promise options. For each, include the proof that supports it, what proof is missing, and where the promise should appear first.

If any input is missing, ask me up to three questions before producing the artifact. Then return five sections: Finished Artifact, Realistic Brand Example, Assumptions To Check, What I Should Use In The Next Lesson, and One Risk If I Use This Publicly Without Fixing It. Keep the answer practical enough that I can paste it into my brand working doc.

Finished Artifact:
- a promise and proof pair
- Why it matters: it gives the brand system a concrete thing to inspect instead of a vague intention.
- Use it next: paste this artifact into the next lesson before asking Claude to write, build, import, publish, or review anything.

Reality Check:
- The artifact names the user, input, decision, owner, or proof it depends on.
- The weakest assumption is visible.
- The next step can be completed in one sitting.

What good looks like

• Each promise is one sentence.
• Every promise has proof or a missing-proof note.
• The strongest promise is chosen.
• The first use case is named.

Without rereading the lesson, explain why a promise and proof pair matters in three bullets. Then apply it to a second brand example: [describe a different solo brand, company, or project]. Return What Changed, What Stayed The Same, What To Check Before Public Use, and the exact next action.

Transfer Check:
- What changed: the second example has a different audience, input, or delivery context.
- What stayed the same: a promise and proof pair still needs a source, a review check, and a next step.
- Before trusting it: inspect the brand review check that would catch a wrong assumption.
- Next action: run the check once, then carry the revised artifact into the next lesson.

What good looks like

• You explained the lesson idea from memory before applying it again.
• The second example changes the artifact instead of copying the first answer.
• The public-use check names a real risk.
• The next action can be done in one sitting.