Enterprise dataset spec sheets by data type

How to read a spec sheet

Every sheet follows the same order, so types can be compared line by line. Structure shows how the type uses the shared conversation schema and which fields are specific to it. Size drivers name what makes one delivery large and another small, because raw volume says little until filtering is done. Sample checks are the tests to run on a sample before you agree to the full set. Uses say where the type earns its place, and questions for the supplier are what to put in your first email.

Matching type to training goal

• Dialogue between people. Workplace chat for many short voices, email for longer, more formal exchanges with outside parties.
• Tasks with a result. Support tickets, where a case ends in a recorded outcome, and code, where an issue ends in a merged change and passing tests.
• Long reading and drafting. Business documents, best with versions or with inputs paired to the finished deliverable.
• Process and decision data. CRM and process records, where each deal or case carries its stages and its ending. These are specified per request because every system is configured differently.

What makes a delivery worth more

Four properties raise usefulness across all types. Depth of history, because years show how work changes. Linked sources from one organisation, because tasks cross systems. Recorded outcomes, because they turn records into checkable tasks. And clean rights with documentation, because data your counsel cannot clear never reaches a training run.

Formats

Conversational types ship as JSON Lines. For large deliveries, the same records can be written to Apache Parquet with an identical field layout. Metadata about the set itself belongs in the datasheet, and can also be expressed as Croissant or a Hugging Face dataset card if your tooling reads those.