# Define a buyer sourcing requirement Create a procurement brief connecting the intended task to source records, evaluation evidence and explicit acceptance criteria. ## Define the work before looking for a supplier Use this when an AI acquisition or research team needs records from operating companies and must explain what would count as a useful contribution. Start with the intended task rather than a request for a large quantity of data. Have a task owner, a proposed evaluation process and the main technical or procurement constraints in mind. Describe required evidence without naming private source companies or uploading examples. ## Write checks that can produce a decision Connect each requested record family to the evidence it supplies. If the task concerns resolution quality, specify whether a case needs an outcome, a reason for closure or a link to a later action. A dataset name alone does not define those requirements. An acceptance criterion identifies what is checked, which evidence supports the check and what happens if it fails. Keep task suitability separate from rights and security review. Passing one does not imply passing the others. ## Hand over a requirement that can be revised The output preserves the task, source requirement, outcome evidence, checks and use boundaries. Its clarification list lets a supplier or evaluator respond to the requirement rather than guess at it. Use the brief to agree a bounded evaluation and its disclosure permissions. It is not a purchase order or a promise that a matching dataset is available. ## What you will take away A sourcing brief with task-linked evidence, acceptance checks, failure actions and procurement questions. Keep a high-level description in this document. Do not attach raw records, personal details, credentials or confidential contract text. Completing it grants no authority to disclose or license data. --- # Worksheet Record what is known and mark what needs confirmation. Unknown is useful information when it is attached to a specific next check. ### Task or decision to support Describe what the model or evaluator should do. Response: ________________________________________________________________ ### Required record families and context Explain which records must be connected. Response: ________________________________________________________________ ### Evidence of the result Say what shows the result, including unresolved cases. Response: ________________________________________________________________ ### Acceptance criteria and failure action State the check, evidence and what happens if it fails. Response: ________________________________________________________________ ### Permitted and excluded uses Describe evaluation, training or retrieval use and exclusions. Response: ________________________________________________________________ ### Procurement and delivery constraints State format, access, timing and security questions. Response: ________________________________________________________________ ### Who should verify this brief? Name the responsible role and the check, rather than assuming that a completed form establishes accuracy or authority. Response: ________________________________________________________________ --- # Filled example Fictional internal planning example. It illustrates the level of description, not a claim about Avelence clients or a source company. ### Task or decision to support Evaluate resolution using the documented case history ### Required record families and context Request, investigation, resolution and relevant follow-up ### Evidence of the result Closure reason and later follow-up ### Acceptance criteria and failure action Report missing links; exclude incomplete cases from outcome scoring ### Permitted and excluded uses Evaluation of support workflows; other uses require separate agreement ### Procurement and delivery constraints No raw personal content in initial discussions; evaluation access to be agreed ## An acceptance criterion with a consequence For a support-resolution evaluation, require each item to retain its request, relevant context and recorded resolution as a connected case. Report missing links separately. Hold a case without a recorded outcome out of the outcome-based test rather than silently treating it as a successful resolution. ## Before acting on the document 1. Agree each acceptance check and its failure action with the evaluator. 2. Resolve rights and security questions separately from task suitability. 3. Set a bounded evaluation and who may access it. ## Limits The brief does not prove dataset availability, suitability or licensing rights. Criteria require agreement with the evaluator and responsible procurement, technical and rights reviewers. ## Sources and scope NIST AI Risk Management Framework. Voluntary AI risk guidance. It does not certify a dataset or prescribe a licensing contract. https://www.nist.gov/itl/ai-risk-management-framework Resource revision: AVE-42, 3 November 2026. Prepared for editorial review. This revision does not change permissions, make a buyer commitment or establish a market price.