“Our AI handles your follow-ups.”
That sentence leaves a lot unanswered. Does the product draft a message, schedule it, send it, or decide who receives it? Does someone approve the message first? What happens when a required detail is missing?
Before you make the promise louder, make it reproducible.
Keep a small proof card beside the claim. Use it when you write website copy, record a demo, brief a creator, or ask AI to draft your next post. The card connects the words you publish to behavior someone actually checked.
One claim, one observable behavior
Start with a sentence a customer can interpret literally. Avoid putting several untested jobs inside a phrase such as “runs your entire business.”
For an illustrative product, a narrower candidate might be: “Turn an inquiry into a follow-up draft you can review.” That still needs a test. It does not imply automatic sending, a connected inbox, or a reply from the customer.
Split a bigger promise into separate claims before checking it. Creating a draft, saving it, assigning an owner, and sending a message are different behaviors. Evidence for one does not establish the others.
Build the proof card
Use these five fields:
Claim: the exact sentence you want to publish.
Check: the setup, inputs, and steps someone else can repeat.
Evidence: the observed result and a link to a suitable recording, screenshot, or test record.
Boundary: what the check does not establish, including required human work.
Owner and date: who checked it, on which version or environment, and when.
Keep the internal evidence private when it contains customer information. Create a separate, sanitized demonstration with synthetic data for public use. Do not publish an internal recording just because it proves the point.
A worked example—without invented results
Imagine you want to publish this claim: “Generate a follow-up draft from an inquiry.” Here is a test plan, not a completed test or a CORA feature announcement.
Setup: use a test workspace and a synthetic inquiry containing a fictional prospect, a requested service, and a question. Record the product version and any required configuration.
Check: open the inquiry, request a draft, and inspect the output. Look for the relevant service and question. Check whether the draft invents a price, deadline, discount, or commitment that the input never supplied.
Persistence check: save it, leave the screen, and reopen it. Only describe the draft as saved if that behavior works in the tested environment.
Boundary check: repeat with an inquiry that omits the requested service. Note whether the system asks for clarification, flags the gap, or guesses. Record the actual result—even if it contradicts the claim.
Publication decision: keep the result marked unverified until the check runs. If the draft works only with a specific setup or human correction, make that condition visible. If the behavior fails, repair it or remove the promise.
A successful demonstration establishes what happened in that case. It does not prove universal reliability, time saved, revenue gained, or a higher conversion rate.
Use AI as an editor, not a witness
Give your AI assistant the claim, the sanitized test notes, and the boundaries. Ask it to separate supported wording from assumptions:
“Rewrite this product statement using only the evidence supplied. Preserve prerequisites and human review steps. Separate observed behavior from proposed behavior. Flag every outcome claim that needs additional evidence. Do not turn a single successful demo into a reliability or performance claim.”
Review the answer against the record. An AI assistant can help organize evidence; a polished paragraph cannot substitute for the check itself.
For broader design guidance, Microsoft Research’s human-AI interaction guidelines cover initial use, regular use, errors, and change over time. Your proof process should look beyond the happy-path introduction too.
Make one proof session feed your content
Record a short, sanitized walkthrough of the real task: input, action, result, and limitation. From the same verified material, create a website explanation, a short video, and a newsletter example.
Keep the boundaries consistent in every format. A video caption should not promise automatic sending when the demonstration stops at a draft. A partner brief should not add integrations you never checked.
Recheck the card when the relevant product behavior changes. Old proof can describe an old version accurately while misleading someone about the current one.
The CORA connection
Explore CORA’s website-and-workspace direction. A broad AI co-founder vision becomes easier to explain when each concrete workflow has a clear input, an observable result, and an honest boundary.
The proof card is a manual operating practice you can use today. The inquiry example is hypothetical; this issue does not claim CORA has passed those checks or maintains proof cards automatically.
Do it now: choose one sentence from your homepage. Write the repeatable check that would support it. If you cannot point to evidence yet, keep it unverified or narrow the wording before your next promotion.
One workflow you can show gives your content something real to say.
— Dravya Bansal
