Choose the unit your budget actually buys
Raw bytes, pages, tokens and accepted training records describe different things. If your product must revise an engineering requirement after a change, a page of general specifications is not interchangeable with a linked change instruction and its relevant outcome context.
Define a usable example before calculating its cost. Specify the input, required source relationships, target response, allowed uncertainty and review criteria. Include the fields that make it possible to reproduce the task. Otherwise, a supplier and a buyer can agree on a record count while discussing different deliverables. The resulting disagreement appears late, when annotation effort has already been spent.
Map the preparation work explicitly
List each operation between acquisition and acceptance: opening files, extracting text, converting application formats, identifying relevant objects, linking instructions to artifacts, translating when needed, reviewing scope, drafting targets and checking those targets. Different tasks use different combinations.
Separate work performed once from work repeated for every record. A converter may be reusable, while interpretation of a technical exception still requires expert attention. Also separate source availability from proposed services. If a source lacks correspondence, linking cannot recover an authentic interaction history from filenames. An estimate should show that limitation rather than allocate a small budget to an impossible reconstruction.
Calculate yield with a worked illustration
Here is an illustrative calculation, not a reported YourSOTA result. Suppose preparation of a scoped batch costs $6,000 and produces 300 candidate records. Review accepts 180 records for the agreed task. Candidate cost is $20; cost per accepted example is about $33.33. The usable yield is 60 percent.
These figures exclude any costs not included in the hypothetical preparation budget. Track acquisition and training separately, or state clearly when they are included. If the remaining records fail because they lack necessary source context, another training run will not improve the yield. Changing the source selection might. That is the financial insight the calculation should reveal.
Give rejected records reason codes
A rejected record is information about your supply and process. Record why it failed: unsupported output, incomplete reference, duplicate task, unreadable artifact, insufficient permission scope, ambiguous instruction or unresolved expert disagreement. Avoid a single miscellaneous category that hides the next decision.
Some records can be repaired through preparation. Others should remain excluded for the intended use. Measure repair effort rather than treating it as free work. A batch with a modest initial yield may become practical through a reusable conversion fix; a polished batch may become expensive if every example needs unique interpretation. The rejection ledger makes those differences visible.
Sample difficult material before forecasting
A preparation estimate built entirely from clean documents will underestimate a purchase containing unfamiliar formats, multiple languages or sparse references. Select a sample across the source conditions that matter to the task. Record its selection method and the share of each condition in the proposed package.
- Include files your tools struggle to open.
- Include records with incomplete context.
- Include common and unusual instruction types.
- Time expert review and dispute resolution.
Compare yield within these groups. A single average hides whether you are buying useful breadth or financing preparation for material that contributes little to your target behavior.
Agree on acceptance before scaling
For prepared records, define deliverables and acceptance checks before expanding the job. Identify which files are original sources, which fields were extracted and which responses were newly drafted. Set review responsibilities and document how changes to the task definition affect the estimate.
Use a bounded first batch to establish working costs. After acceptance, forecast the next batch using the source mix actually available, with uncertainty stated. A lower unit price only helps if the records meet the same criteria. Buying more examples that your team cannot use creates a larger denominator on an invoice, not a better return on the preparation budget.
Should we choose the cheapest prepared dataset?
Compare costs against the same accepted task, not the seller’s broad record description. A higher priced record with the necessary evidence may save substantial review work. A cheaper source collection may be preferable when your team already has a suitable extraction pipeline. Neither answer follows from price alone.
Ask for a proposal that separates source access, optional preparation, review and licensing scope. Then measure accepted examples and the behavior they support. Your next purchase decision should be based on both: economical production of usable data and a pilot showing that the data contributes to the product. Cost efficiency without task value is still wasted budget.