Examples can make AI concepts easier to understand, but an example should not be presented as a customer success story or proof of product performance unless the evidence exists. The patterns here are instructional demonstrations using fictional inputs. They are not reports of AILooma testing or real deployments.
Example 1: Sort fictional feedback
Create six fictional comments about a made-up app and label each “setup,” “navigation,” or “export.” Ask a text model to suggest labels and quote the phrase that supports each label. Compare the suggestions with your labels. Add a comment that could fit two categories and decide whether the right result is a human review rather than a forced choice.
Example 2: Extract fields from a sample request
Write a fictional request with a date, item, and missing field. Ask an AI tool to return a structured draft. Check every field against the original text and confirm that the missing information remains blank instead of being guessed. Do not use a real customer form for a public tool unless your organization has approved the data path.
Example 3: Search a small document set
Use a few public or fictional policy paragraphs. Ask a system to answer one question and identify the source paragraph for each part of its response. Remove the supporting paragraph and repeat the question. Note whether the system says it cannot find evidence or invents an answer. This explores source-grounding; a tiny exercise cannot establish reliability for a larger collection.
Record enough to repeat the example
- Tool and version, if visible, plus date.
- Fictional input and exact task prompt.
- Expected result and human reference.
- Observed output, correction, and one failure case.
- Data, permissions, and assumptions excluded from the demo.
Make each example repeatable with a small test card
The examples are intentionally different from a course list: each demonstrates an input/output contract that a learner can inspect. Keep the inputs fictional, write the expected result before asking a model, and treat an unexpected result as a useful failure to explain—not evidence of general accuracy.
Example A: extract fields from a fictional request
Input: “Please send the sample kit to Room 4 on Friday.” Expected fields: item=sample kit, location=Room 4, date=Friday (year and calendar date unknown). Check that the system does not invent a year or a recipient. If the output schema requires a full date, the correct behavior is to ask for clarification.
Example B: answer from a tiny document set
Place two fictional policy paragraphs in a small permitted document collection. Ask a question whose answer appears in only one paragraph. Require a short answer and the source paragraph identifier. Then ask about a detail absent from both documents; the expected behavior is “not stated in the provided material,” not a plausible guess.
Example C: label a few fictional comments
Write a simple label guide first—for example, “setup,” “export,” and “unclear.” Label a few invented comments by hand, then ask for suggested labels plus the text span that supports each one. Include a comment that fits none of the labels. Review consistency and disagreement; do not describe this tiny exercise as a sentiment benchmark.
For each card, save the prompt, input, expected output, observed output, and one failure. Keep the provider, model version, and date if the tool exposes them. These short demonstrations teach test design; they do not replace the separate risk-tier evaluation method or establish product performance.
Related reading
For a project checklist with clear pass/fail criteria, see the project-based learning guide. For a framework to verify generated claims, see the fact-checking guide.
About the author
Femica Maydinda Harend writes practical technology guides for AILooma with an emphasis on transparent examples and limitations.
Editorial note
These are fictional teaching examples, not field results or a product review. Do not use sensitive material, and do not infer real-world accuracy from a toy exercise.