BUILDSIDE — AI DEMO EVIDENCE CHECKLIST
https://www.buildside.app/build-in-public/ai-product-founders

Use this writing aid to make an AI product demo inspectable. Buildside is a place to share context and feedback; it is not an evaluation runner.

TASK
Who is the user?
What are they trying to complete?
Where does AI contribute, and where is human review needed?

SAMPLE
Input, with appropriate permission or synthetic data:
Why this example was selected:
What context is omitted:
Version and settings, if relevant:
When the run was performed:

EXPECTED BEHAVIOR
What would a useful output preserve, include or avoid?
What can a reviewer observe to judge it?
What would count as a meaningful failure?

ACTUAL RESULT
Output exactly as observed:
Source evidence for each important statement:
Mismatch:
Why the mismatch matters to the user's task:
Latency or cost only if measured and relevant:

LIMITATION
What this sample does not establish:
Other inputs or user groups not covered:
Known failure cases:
Do not turn one successful output into a general reliability claim.

NEXT TEST
Cases to compare:
Criterion to check:
How results will be recorded:
What would change your decision?

FICTIONAL MEETING-SUMMARY CASEBOOK
Clear: "We agreed to launch Friday. Sam will publish the release."
Expected: retain the agreed date and owner.
Tentative: "Friday might work. Confirm after design review."
Expected: retain uncertainty and the condition.
Illustrated failure: "Launch date: Friday."
Missing owner: "The release notes need a final check. We have not assigned that yet."
Expected: show that the owner is unassigned.
These are editorial examples, not measured model outputs.

PUBLIC DEMO DRAFT
[Product] helps [people] with [task].
Here is [sample and conditions].
I expected [criterion], but observed [result].
The important limitation is [limit].
I would value a review of [specific question].
Next I plan to test [cases]. I will distinguish a planned change from a measured improvement.

Before sharing: check permissions, remove confidential inputs and identify fictional examples. Keep a record of the actual test evidence in your own workflow.