Agree the boundary before the demonstration
Choose one workflow and one representative exception. Define the participating roles, the records needed and the output you will inspect. Make any dependence on integrations, migration or specialist calculations explicit.
Use synthetic data first. Before real personal or sensitive records enter a pilot, resolve the relevant access, privacy, contract and security questions. The OAIC’s security guidance is a useful reference for organisations assessing personal-information safeguards; applicability and appropriate controls depend on the circumstances.
Choose five observable scenarios
| Scenario | Example question | Evidence to retain privately |
|---|---|---|
| Ordinary workflow | Can the intended role complete the agreed task? | Expected and actual steps, with synthetic record identifiers. |
| Correction or rejection | What happens when an entry or supporting document is not accepted? | State changes and the retained reason. |
| Permission boundary | Can an unrelated role or organisation access a restricted record? | Authorised test outcome, not sensitive production content. |
| Record retrieval | Can another evaluator find the related records without help? | Retrieval steps and any missing relationship. |
| Exit or recovery requirement | Can the supplier demonstrate the agreed export or recovery behaviour? | The exact scope demonstrated and any untested dependency. |
Do not turn this table into a list of assumed product features. Ask the supplier what can be demonstrated now. Mark an unavailable or untested capability honestly, and decide whether it prevents the pilot from proceeding.
Write acceptance criteria that can fail
“Easy to use” is a useful aim, but a weak acceptance criterion. A more testable statement is: “An evaluator can locate the agreed equipment event and its supporting evidence from the equipment identifier without assistance.”
For a permission boundary, define who should be denied, which record is involved and what the expected response is. For a correction, define which earlier value or decision must remain retrievable. Avoid vague criteria such as “full audit trail” until you have named the changes that matter.
Keep decisions separate from feature requests
Use a simple result vocabulary: met, gap, not tested and outside scope. A gap may be acceptable with a documented workaround, but the workaround should have an owner and a reason it is sustainable.
Record future feature requests separately. A promised change is not an observed pass. Where a change is essential, define the evidence needed before that item can be accepted.
Decide who has authority to accept the result
A laboratory manager, technical reviewer and IT or privacy reviewer may answer different questions. Do not allow a successful user demonstration to stand in for approval of data handling or scientific use.
Assign acceptance by subject: workflow fit, technical suitability, data handling, commercial arrangements and operational readiness. A small pilot may combine some roles, but the decisions should still be explicit.
End with a proceed, revise or stop decision
A useful closing record states the agreed scope, what was demonstrated, what remains unresolved and the conditions for the next step. Retain the synthetic test evidence privately. Do not publish it as customer proof or a case study without separate approval.
A pilot can succeed by showing that a product is not the right fit. That is better than discovering a fundamental scope mismatch after importing records or making a wider commitment.
Start with the current boundaries of AureqoLab or AureqoEq. A Request a product walkthrough can help establish which questions a separately agreed pilot could reasonably answer.