Singapore AI testing workshops: bringing a useful case without customer data

The problem

A real customer interaction exposes the weakness in your Singapore AI prototype, but sharing the original prompt, attachment or trace at an event could disclose information you do not have permission to publish.

Identify what makes the example fail

Separate the failure mechanism from the original wording. An instruction might be missed because it appears in an attachment, a question might depend on a permission boundary, or an answer might cite the wrong passage. Recreate that relationship with invented content. Replacing only a name is insufficient when the remaining details still describe a recognisable customer. Make a five-field relationship note: task; information or permission boundary the answer depends on; expected behaviour and its stated basis; observation actually available; and the question still open. Keep a guessed cause outside those fields. You may know that the output used an older passage without knowing why that happened. The purpose is to make the missing answer understandable through material you may discuss, rather than to create a flattering demonstration. If the real case cannot be shared, preserve that limit openly. This worksheet supplies no permission to publish prompts, attachments or traces.

Separate an authorised extract from wholly invented content

Choose the material route before preparing files. An appropriately authorised extract retains its actual sharing conditions; an invented example is a new scenario and must be labelled as such. Removing a customer name does not settle whether other facts, document structure or combined details identify the interaction. Describe which relationship you intend to preserve and which details you replaced, omitted or do not know. Do not write that a case is anonymous, confidential or approved because you personally removed a field. If permission or the event’s handling arrangement is unresolved, keep the original out of that route. A public workshop can examine a hypothetical question without gaining access to the customer record.

Check the event environment

Before booking, ask whether participants work in their own environment, upload examples to the instructor or share a screen with the room. Also ask about recordings and how files are retained. The AI Verify assurance pilot discusses different test environments and the safeguards needed around shared data; an event listing alone does not establish those safeguards for your case. Use four rows for the proposed route: who receives the input; where it is displayed or processed; what recording or retention is stated; and what condition remains unanswered. Ask about the exact selected session instead of assigning an assurance report’s pilot environment to the venue. A screen share can reveal surrounding windows and linked content, while a file upload can involve a different recipient. These are things to resolve through the actual instructions, not a universal provider arrangement. If the host offers only supplied exercises, your own invented case may still be outside the activity. Keep an accepted place and permission for participant material as separate answers.

• AI Verify Foundation: test implementation in the assurance pilot ↗ · Source checked 20 October 2026

Build the replacement around one observable relationship

Here is a wholly invented example with no real customer, system or measured usage behind it. A practice assistant receives two invented delivery notes. The older note says collection is Friday; the identified newer note says collection is Saturday. The task asks for the current collection day. Your replacement keeps two versions, a way to identify the newer one and a question that depends on that distinction. It does not copy a customer’s order number, account, wording or document. Before testing, write the expected Saturday answer and why the supplied practice material supports it. Choosing this replacement frames a version-selection question; it has not yet shown that the practice assistant makes the real application’s error.

Test the replacement before travelling

Run the invented example through your own permitted test environment. Confirm that it reproduces the problem you want to discuss, and write down the expected and observed outputs. If the replacement no longer fails, say so. Do not present it as an equivalent case merely to make a cleaner workshop demonstration. In the invented record, an initial permitted run returns Friday and identifies the older note. Keep that expected-versus-observed result with the practice setup and describe the cause as unknown. After you simplify the case further, a separate run returns Saturday and identifies the newer note. That second version does not reproduce the earlier discrepancy. Keep both versions and observations instead of labelling the clean second result an equivalent failure. Either may support a different discussion, but only the first supplies the fictional observation recorded for its own setup. Nothing in this example measures customer behaviour or establishes how your real application responds.

Bring a case card that tells the facilitator its limit

Use six entries in the final card: permitted material route; task and expected-answer basis; setup or version; observed result, if any; relationship preserved and details omitted; and the question you want to examine. Mark an unrun replacement as unrun. Mark a run that no longer fails as not reproducing the discrepancy. An unsent enquiry could say, “I can bring a wholly invented two-version example. One permitted practice run used the older note; a later simplified version did not. Does this session discuss these bounded results, and which input and recording arrangement applies?” Send only the question and material allowed by the actual route. The host’s willingness to discuss it does not approve access to the original interaction.

Leave with a next experiment

Ask the facilitator what one change would distinguish between two possible explanations of the failure. Keep that experiment small enough to run after the session. If a participant requests the original material, explain that it is unavailable for public sharing and work through the invented case instead. Event attendance does not change the permissions attached to your source data. Keep four fields for that next step: explanation being compared; one permitted change; observation that would inform the question; and limit of what the result could show. In the fictional case, a suggestion to inspect which note the practice flow supplies can help distinguish an input question from a final-answer question. Until that inspection happens it is proposed, not a finding. Do not add real customer content to make the next check convincing. Define application boundaries separately, and examine reviewer criteria if the difficulty concerns an assessment rule rather than preparing shareable material.

Record what the workshop actually helped clarify

After a permitted discussion, keep the example and the answer at the scope used. An invented outcome could be a clearer question about which practice note reached the response step, while the real customer case and the cause of its error remain unexamined. That can be useful learning without being a product test, an approved data-sharing arrangement or evidence that the issue is repaired. If no suitable session accepts the case route, retain the card and its missing condition. Use Boardzip’s free AI search for candidates and verify the named programme’s activity before joining. Search access does not supply permission to distribute the case, an individual review slot or a guaranteed reproduction.