Enterprise workflow datasets are useful for AI when they show enough context to reconstruct a task: what a person was trying to do, which records they used, what action they took, and what result followed. A document archive, an action trace, and an agent evaluation environment each reveal different parts of that story.
Start with the model task. An assistant that answers questions about a project needs source documents and reliable citations. An agent that updates a business system needs a description of the starting state, allowed actions, and a way to tell whether the update was correct.
Three different kinds of workflow data
| Data form | What it captures | What it may leave out |
|---|---|---|
| Business archive | Emails, drawings, tickets, files, tables, and decisions saved during work | The exact sequence of actions, or a clean link from one system to another |
| Demonstration or trace | The steps a person took in a tool, often with screens or action records | Why the person chose a step, or what happened weeks later |
| Task and evaluation environment | A starting state, a request, available actions, and a success check | The wider history and variation found in a real company archive |
For example, WONDERBREAD publishes human demonstrations of business process tasks, with action traces and other task material. WorkArena offers knowledge-work tasks with validation functions. These are useful references for task design. Neither means a company's old files arrive with the same structure.
Look for links and outcomes
A useful unit of data is often a case, such as a customer request, purchase, support issue, or project. Ask whether the dataset can connect its files and events to that case. Then ask which version of each record was visible at the time of the decision. An answer based on a later document can make an evaluation look easier than the real task was.
For one case, try to fill in five fields:
- Request: What did the worker need to decide or complete?
- Context: Which records were available then?
- Action: What did the worker change, approve, send, or produce?
- Outcome: What later record shows the result?
- Permissions: Which records can be used for the proposed training or evaluation?
If the action is missing, the data may still support question answering. If the outcome is missing, it may support imitation or retrieval but not a strong success check. The right label depends on the task, not the amount of storage. Mercor's published data page lists sources such as messages, CRM, code, work orders, and QA logs. Those file types show possible coverage, but the buyer still has to test the joins and task labels in the delivered data.
Where an Orla archive fits
Orla's SolarThermal-4TB combines native design files with project and business records from a Brazilian solar heating company. Its published card describes an available archive of about 4.2 TB across an estimated 1,200 projects, with drawings, models, documents, spreadsheets, saved emails, photos, and video among its file types. The listed counts are estimates.
That mix makes it a candidate for project-level research. It does not establish that every project has a complete timeline, linked actions, outcome labels, or a ready agent environment. Its downloadable sample is a selection of technical files and is not representative of the full archive. Tell Orla the workflow and links you need to inspect so the sample can be scoped to your task.
For one concrete way to test a project archive, read construction project data for AI agents. For procurement, use the enterprise workflow dataset buyer checklist.