Plan a sample of business data for AI

A usable sample starts with one decision, one outcome and a clear account of who can authorize the records. This one-page worksheet helps you scope the intended model task, decide what data can be shown, and prepare an example before sharing any raw export.

Use it for projects involving service tickets, quality inspections, internal procedures or similar operational records. Start with a fabricated example and list which real fields you could offer under the right terms. Then check the authority, privacy obligations and confidentiality restrictions for the actual data.

Describe an existing dataset · Discuss a new collection

An original support-ticket example

Invent ticket T-31 for a delayed practice delivery. An initial note proposes a replacement. A later message authorizes a refund instead, and a separate completion event records the refund under T-31. Add a replacement confirmation for T-13, a different ticket. Ask which action is documented as completed for T-31 and what evidence supports it.

The reference answer is the refund, supported by T-31’s authorization and completion event. T-13’s similar identifier does not establish a replacement for T-31. The proposal alone would not establish execution. Keep the answer and source references in a reviewer file that the model does not receive as an input.

Use the worksheet to define the smallest complete unit

Write the question first. Then list the fields and records necessary to answer it: ticket identity, event order, status, authorization and completion reference. A single flattened row may lose the distinction between a proposed action and the eventual outcome. Preserve the relationship in the package or narrow the task.

Include a second case where the completion event is missing. Its correct answer should retain the authorized but unconfirmed status. The exercise is more useful when it includes a supported answer and a realistic unresolved case, rather than only clean examples with the same outcome.

Separate a practice example from a real data proposal

The invented ticket explains a structure. A provider seeking real operational data may require actual history under a separate accepted scope. Describe the systems, approximate volume, available outcomes and ownership without treating the fictional exercise as a completed commercial dataset.

For real sources, identify customer, employee, vendor and contractual interests. Define who may inspect the sample, which information is removed and which relationships must remain. Keep credentials and unrestricted system access outside the initial description. Confirm the proposed source and permitted uses before arranging an export.

Make the review reproducible

Save the source version, question, allowed evidence, expected answer, error categories and reviewer decision together. Score entity matching, event status, outcome and response to missing evidence separately. Group related cases and revisions before forming a held-out test.

Use the planner to prepare a scoped conversation. A useful next outcome is a confirmed specification and authorized sample process. A submission, an accepted source, a signed licence and payment remain distinct events. Review Fiund’s actual contributor terms for the relationship that governs a later contribution.