Describe the model behavior
Explain what the system should do with the data in one concrete example. State the input, expected output, and operational setting. Extraction, classification, retrieval, and linked-table reasoning require different artifacts; asking only for business data leaves too many important decisions to assumption.
Define the required collection
List document or record types, target languages, periods, sectors, source diversity, and approximate scale. Distinguish pages, files, rows, entities, and independent events. Mark mandatory coverage separately from useful additions and identify whether authentic operational records are required or synthetic supplements are acceptable.
Specify evidence and handling
Include an output schema, annotation examples, dictionary requirements, relationship keys, and source documentation expectations. Describe exclusions and sensitive-field treatment for the specific project. Name the artifacts needed for your own review rather than asking a supplier to summarize a complex suitability decision with an unsupported assurance.
Plan the first review step
Propose a representative pilot and measurable acceptance questions before a larger discussion. Explain how you will inspect coverage, source lineage, label quality, and delivery consistency. Email the brief to jaeden@fiund.com; Fiund can use it to discuss potential sourcing scope, with availability and project suitability assessed source by source. An effective first email might describe a model that extracts line items from multi-page invoices and evaluates unfamiliar suppliers. Include a sample input, expected line-item structure, must-have languages, and exclusion rules. That level of specificity makes the next discussion more productive than asking for a broad collection of unspecified enterprise data.
Review checklist
- Show one input and expected output
- Rank required coverage and scale units
- Attach schema and review requirements
- Define pilot questions and next decisions