Build a clearly fictional fixture around the task's relationships and edge cases without copying real customer records into the recipe.
A demo needs examples that make the task visible. Copying last week’s customer spreadsheet may feel convenient, but it can expose details that have nothing to do with the feature you want to explain. Start with the behaviour to demonstrate, then invent the minimum information needed to show it.
This method creates examples from a fictional specification. It does not anonymize real records, test a model’s privacy protections or guarantee that a dataset derived from customers is safe to share.
Choose the story before the fields
Suppose you are demonstrating an internal tool that checks whether an exhibition-display enquiry contains enough information for staff to review it. The tool needs a requested product, quantity, artwork status and collection preference. It does not need a real name, phone number, address, order history or the text of a private message.
Write the demonstration goal: “Show how the tool separates a complete enquiry from missing or contradictory information, while leaving acceptance to staff.”
Now choose only fields that help with that goal:
- Example ID, visibly labelled DEMO
- Product code from the fictional catalogue
- Quantity in whole units
- Artwork status: ready, not ready or unknown
- Collection preference: weekday, other request or unspecified
- Review state: ready for staff review or clarification needed
If a field has no role in the demonstration, leave it out. More realistic-looking detail can make the example harder to inspect without making the behaviour clearer.
Build a small catalogue that stays consistent
For this invented exercise, the catalogue contains DISPLAY-TRI and SIGN-FLAT. Quantities must be positive whole numbers. A weekday collection preference is a request, not evidence that a slot is available. “Artwork ready” means the enquirer says it is ready; staff have not checked the file.
Those definitions matter more than plausible customer names. If two sample records use the same product code, they should mean the same product. If the demonstration shows a count of accepted requests, it must not silently treat a complete enquiry as an accepted job.
| Example ID | Product | Quantity | Artwork | Collection preference | Expected review finding |
|---|---|---|---|---|---|
| DEMO-01 | DISPLAY-TRI | 2 | Ready | Weekday | Complete enough for staff review; no acceptance implied |
| DEMO-02 | SIGN-FLAT | 1 | Unknown | Unspecified | Ask about artwork and collection needs |
| DEMO-03 | DISPLAY-TRI | 0 | Ready | Weekday | Quantity needs correction |
| DEMO-04 | UNKNOWN-ITEM | 3 | Not ready | Other request | Product unresolved; staff clarification required |
These rows are fictional fixtures. They are expected examples, not observed tool results. Include the invalid row deliberately and label why it is invalid. Otherwise a colleague may “clean” it away and remove the case you wanted to demonstrate.
Add relationships instead of personal detail
A useful example set often needs relationships: one request has two line items; a revised request replaces a prior version; a staff note refers to one specific question. Create fictional identifiers to connect those records and write down the rules.
For instance, DEMO-05-R2 can be a revision of DEMO-05-R1, with quantity changed from two to four. The expected result is that the current view uses four while the history remains identifiable. No real customer identity is needed to explain that behaviour.
Keep the relationships small enough that a reviewer can check them by hand. If the point is a missing field, do not bury it among fifty arbitrary columns.
Review the recipe before generating more rows
An AI drafting tool can propose variations from this fictional specification. Give it the allowed fields and values, the relationships to preserve and the exact edge cases you need. Instruct it to use conspicuous DEMO identifiers and no real people or copied customer messages. Review every generated row before using it.
Canadian privacy regulators’ generative-AI principles recommend alternatives such as synthetic or de-identified data where personal information is unnecessary. This article takes the narrower route of inventing examples from scratch. Replacing names in a real record does not establish that its remaining details cannot identify someone.
Avoid uploading real data merely to ask a tool to “make it anonymous.” If the intended task genuinely requires real records, use the organisation’s approved privacy and security review rather than treating this exercise as permission.
Run the fixture check
Before a demo, have a colleague answer four questions using only the sample pack:
- What is the business task, and which fields matter to it?
- Which records are ordinary, incomplete, contradictory or deliberately invalid?
- What result is expected for each record, and why?
- Could any visible content be mistaken for a real customer, booking or performance result?
Check totals, references and versions independently. Keep the fixtures separate from production import folders and avoid working integrations that could send messages from sample addresses or create real jobs. A clear DEMO label helps communication; technical isolation still needs its own implementation check.
Your finished pack is a schema, a few fictional rows, expected findings and a short explanation of what the demo does not test. That is enough to make a useful conversation concrete.
Week 39 · interactive local candidate
Make fictional fixtures explain the real decision
Fictional local exercise. No live AI, business verification or external action. Use invented information only. Working state stays in page memory; reset or reload clears it. Copies and printouts are outside this page’s control.
Inspect six invented rows, including two versions of one request. Change a quantity, introduce a duplicate ID, or redirect a revision to expose what becomes ambiguous. Nothing is imported or sent.
Minimal fictional schema
Product catalogue: DISPLAY-TRI: Fictional triangular exhibition display; SIGN-FLAT: Fictional flat sign. No names, emails, phone numbers or private message fields are needed.
Review pending. Review the current version after edits. Earlier conclusions are cleared after every edit.
Week 39: Make fictional fixtures explain the real decision
Fictional local exercise. No live AI, business verification or external action. Use invented information only. Working state stays in page memory; reset or reload clears it. Copies and printouts are outside this page’s control.
All observations and checks below are fictional or reader-reported; none independently verified.
FIXED FICTIONAL EXERCISE CONTEXT
{
"catalogue": {
"DISPLAY-TRI": "Fictional triangular exhibition display",
"SIGN-FLAT": "Fictional flat sign"
},
"meaning": "Complete enough for staff review is not accepted. Artwork readiness is enquirer-reported. Collection is a request."
}
CURRENT INPUTS AND EXPLICIT HISTORY
{
"rows": [
{
"id": "DEMO-01",
"product": "DISPLAY-TRI",
"quantity": "2",
"artwork": "ready",
"collection": "weekday",
"replaces": "",
"intent": "ordinary"
},
{
"id": "DEMO-02",
"product": "SIGN-FLAT",
"quantity": "1",
"artwork": "unknown",
"collection": "unspecified",
"replaces": "",
"intent": "incomplete"
},
{
"id": "DEMO-03",
"product": "DISPLAY-TRI",
"quantity": "0",
"artwork": "ready",
"collection": "weekday",
"replaces": "",
"intent": "deliberately invalid quantity"
},
{
"id": "DEMO-04",
"product": "UNKNOWN-ITEM",
"quantity": "3",
"artwork": "not ready",
"collection": "other request",
"replaces": "",
"intent": "unresolved product"
},
{
"id": "DEMO-05-R1",
"product": "DISPLAY-TRI",
"quantity": "2",
"artwork": "ready",
"collection": "weekday",
"replaces": "",
"intent": "historical version"
},
{
"id": "DEMO-05-R2",
"product": "DISPLAY-TRI",
"quantity": "4",
"artwork": "ready",
"collection": "weekday",
"replaces": "DEMO-05-R1",
"intent": "current revision"
}
],
"version": "FIXTURES-v1",
"note": ""
}
Review pending. No current conclusion; earlier review invalidated by input changes.
LIMITATIONS AND WARNINGS
• Invented specification only. This does not anonymize real data or establish privacy protection.
• A ready artwork value is an enquirer statement, not a checked file. A collection preference is not a reserved slot.
• There are no integrations or import actions; verify technical isolation in any actual demo environment.Use the text-only exercise
The complete unchanged manuscript remains readable if the controls are unavailable.
Return to Run the fixture checkPrimary sources checked 4 October 2026
Sources & review
Primary sources checked on . The checklists and planning examples are AI-assisted editorial guidance, not source quotations or reported client results.
This AI-assisted guide uses fictional examples for practice. It does not report client results or establish that a live system will behave the same way.
Originally published: .