A working guide from Beeston Labs. Version date: 8 November 2026.
Begin with the intended use and exact service configuration. Ask the supplier for references to the relevant contract, documentation or test evidence. Record uncertainty where an answer does not cover the proposed use.
Review details
Supplier/product:
Proposed use and configuration:
Review owner:
Decision required and date:
People contributing to the review:
Questions and evidence
| Area | Question | Evidence or answer | Open issue and owner |
|---|---|---|---|
| System boundary | Which models, services and optional features are included? | ||
| Data flows | Which inputs, outputs, files and logs reach each provider? | ||
| Data use | For what purposes can the supplier use each category of data? | ||
| Retention | How are deletion, backups and account closure handled? | ||
| Access | Who can access customer content, including for support? | ||
| Subprocessors | Which other providers are involved, and how are changes notified? | ||
| Locations | Where is processing performed and what transfer arrangements apply? | ||
| Performance | What evidence relates to our task, language and operating conditions? | ||
| Limitations | Which failures and unsupported uses are known? | ||
| Security | How are permissions, tool use and untrusted inputs controlled? | ||
| Change | Can the model or configuration change without our approval? | ||
| Incidents | How will problems be reported, investigated and communicated? | ||
| Licence | Which terms apply to our exact use, modification and distribution? | ||
| Continuity | What happens if a version, feature or service is withdrawn? | ||
| Exit | What can be exported, and what must be rebuilt elsewhere? |
For physical AI and accelerator suppliers
Add questions about device and software compatibility, model-conversion constraints, supported operating conditions, update mechanisms and integration responsibilities. If safety evidence is being relied on, establish exactly what it covers and which assumptions apply to the proposed system.
A product-family name or component certificate should not be treated as evidence for the entire application. Record the configuration and scope to which any claim applies.
Assess the gaps
Use a short narrative for each material issue:
Question: What do we need to know?
Evidence received: What supports the answer, and which version does it describe?
Remaining uncertainty: What is still unknown?
Consequence: Which proposed use or decision does this affect?
Action: Obtain more evidence, test, restrict the use, change the design or choose another option.
Owner and decision date: Who will resolve it?
Avoid adding scores from unrelated categories into one overall number. A satisfactory commercial answer cannot compensate for failure to meet a necessary data or safety condition.
Review outcome
Record the decision, conditions, owner and review triggers. Keep the relevant supplier documents with a retrieval date so a later reviewer can identify what the decision relied on.
Suggested outcomes: further information required; limited trial under stated conditions; approved for the stated use; unsuitable for the stated use.
This is a starting worksheet. The review scope needs to reflect the actual use and applicable obligations.