Synthetic Research Procurement Checklist

Synthetic research procurement combines ordinary SaaS diligence with a harder question: what evidence justifies acting on a simulated answer? This checklist keeps security, data rights, research validity, and commercial terms in one review without treating them as the same thing.

Send the same request to every shortlisted vendor. Record “public,” “provided under NDA,” “contractual,” “roadmap,” or “not publicly available” for each item. A verbal assurance is not equivalent to a product feature or signed commitment.

1. Define the deployment

• Name the users, teams, countries, and intended decisions.
• List customer files, respondent data, personal data, confidential plans, and public sources that may enter the system.
• Separate self-serve use from managed population, integration, calibration, or validation work.
• Identify high-risk topics that require legal, ethical, expert, or live-human review.
• Record the required plans, seats, usage allowances, support, and launch date.

2. Data sources and rights

• Which human interviews, panel data, behavioral data, transactions, location, search, media, customer research, and public sources construct the audience?
• Is each source collected, licensed, customer-provided, public, or inferred?
• What consent and downstream model-training rights apply to participant material?
• Can people revoke or delete submitted data and derived artifacts?
• Which source classes cover the exact market, language, and population?
• Are observed distributions, target quotas, and assumptions labeled separately?

Use synthetic audience data sources compared to structure this part of the review.

3. Customer-data use and model training

• Does the vendor train its own models on customer content?
• Do third-party model providers train on prompts, files, answers, or feedback?
• What is the default, and what requires explicit opt-in?
• Which retention and zero-data-retention settings apply by provider?
• Are embeddings, logs, caches, and evaluation datasets covered by the same policy?
• Can customer content be used to improve a general population or another customer's model?

Require actor, purpose, data class, legal basis, and opt-in state. “No training” without those qualifiers is incomplete.

4. Privacy, security, and subprocessors

Collect and review:

• DPA;
• subprocessor list with purpose and region;
• technical and organizational measures;
• privacy notice;
• DPIA or risk assessment where applicable;
• transfer safeguards;
• incident-response and breach-notification terms;
• retention, backup, and deletion schedule;
• audit or assurance evidence.

Minds publishes its DPA, subprocessors, TOM, and DPIA. Compare the applicable documents, not the number of badges.

5. Identity, tenant, and access controls

• How are tenants and customer-owned research objects separated?
• Which roles can create, edit, share, export, delete, and manage access?
• Is SSO generally available, an add-on, custom, or unavailable?
• How are API and MCP credentials created, scoped, rotated, and revoked?
• Are public share links access-controlled and auditable?
• Can former employees and external collaborators be removed promptly?
• Which actions require explicit confirmation or elevated permission?

Test the exact plan and workflow. Do not accept an enterprise roadmap as a current control.

6. Model providers and material changes

• Which models and providers process each workflow today?
• Can a customer restrict providers, regions, live web access, or external sources?
• What changes when the default model is upgraded?
• Which model changes trigger regression or benchmark work?
• How are subprocessor and data-flow changes notified?
• Can results be tied to the model, prompt, population, and calculator versions used?

Read the Minds model-change and validation provenance policy and request an equivalent answer from every vendor.

7. Research method and evidence

• Is the required job qualitative exploration, questionnaire, segment comparison, MaxDiff, conjoint, pricing, feature prioritization, or network simulation?
• Is the method a versioned product pipeline or a service-delivered analysis?
• Can the buyer inspect individual answers, transcripts, source context, and calculation artifacts?
• Which estimator, diagnostics, and failure rules apply?
• Are fallbacks visible and correctly labeled?
• Can raw artifacts reproduce the summary or score?

Minds' current research method pipeline catalog lists the operationalized methods and stages.

8. Validation and accuracy

• What population, task, reference, metric, and system version produced each headline result?
• Was the benchmark outcome held outside the runtime?
• Are item-level, subgroup, and failure-case results available?
• Is the evidence vendor-authored, customer-reported, partner-reviewed, or independently replicated?
• Does confidence predict observed error on held-out tasks?
• What live human or behavioral validation is required before the decision?

Do not rank incompatible vendor percentages. Use synthetic audience validation and accuracy compared and the Minds applied validation.

9. Exports, audit, and deletion test

• Export a complete example before signing.
• Verify that the export contains the evidence needed for review and migration.
• Confirm formats, source labels, caveats, and version fields.
• Delete a test audience or study and document active, backup, log, and provider behavior.
• Confirm termination export and deletion timelines.
• Record who can authorize a deletion or restore.

10. Reliability and support

• Collect the applicable SLA and status history.
• Verify uptime definitions, exclusions, response priorities, recovery objectives, and credits.
• Ask what happens to an in-progress study during a model, queue, or provider outage.
• Distinguish software support from research, calibration, and analyst services.
• Record included hours, response targets, and escalation contacts.

Minds publishes its SLA; the customer-specific agreement controls applicability.

11. Pricing and services

• Separate platform fee, usage, seats, data, implementation, analyst hours, validation, integrations, and support.
• Compare one routine study and one high-trust study.
• Record overages, refresh costs, export/API limits, and cancellation terms.
• Mark unpublished competitor pricing as not publicly available rather than estimating it.
• Confirm which future or experimental capabilities are excluded from the signed scope.

Minds publishes a pricing baseline. Customer-specific services and enterprise controls remain governed by the order form or separate statement of work.

12. Approval record

The final record should name:

• approved use cases and prohibited uses;
• plan and configuration;
• data classes and regions;
• applicable legal documents;
• method and evidence requirements;
• model-change and notice obligations;
• required human validation;
• security, legal, research, and business owners;
• renewal and re-review date.

Pair this checklist with the security and procurement comparison, research evidence center, self-serve vs managed comparison, and synthetic respondent comparison hub.