Prepare a pilot evidence pack before the demonstration

A demonstration is easier to trust when the presenter can open the evidence behind a claim without searching through private chat messages. Prepare that evidence before the meeting, alongside the demo environment.

The pack should help reviewers distinguish what has been observed, what is inferred and what remains planned. It should be concise enough to navigate during the session, with deeper material available through controlled references.

Start with the claims you expect to make

A hypothetical team plans to demonstrate a withdrawal workflow. Its proposed statements include “the request is captured”, “the campaign platform is updated” and “the event history can be reviewed”.

Each statement needs its own evidence. A captured request does not prove downstream application. A visible timeline does not prove that the event store detects alteration. The wording should stop where the evidence stops.

Create a claim register with the statement, scope, supporting artefact, version and known limitation. Remove or qualify claims that do not yet have support.

For SWARN, which is in development, planned capabilities must remain clearly labelled as planned. A prototype screen or design diagram should not be presented as an available production feature.

Prepare a safe, recognisable case

Use approved synthetic fixtures with documented origins. Give the demo case a stable reference that appears in the relevant interface, event history and target-system result.

Avoid using a real customer’s record simply because it looks convincing. A demonstration can be realistic in its sequence and decisions without containing a person’s private details.

The case should include a meaningful complication, such as a delayed acknowledgement or a corrected capture error. This lets the reviewer see how the workflow expresses uncertainty rather than only watching the ideal path.

NIST’s de-identification guidance explains why transformed or synthetic data still needs assessment. A file labelled “demo data” should have an actual preparation and approval basis.

Assemble the evidence in the order of the story

For the withdrawal example, the first artefact is the intended customer interaction and purpose. Next comes the recorded instruction, then the downstream request, acknowledgement and confirmation condition.

Include the configuration that determines what each status means. A reviewer should be able to see whether “complete” means queued, accepted or applied.

OWASP’s logging guidance supports useful event records and controlled access to them. The demonstration view should expose enough evidence to understand the case without opening unrelated customer data or administrative secrets.

Keep restricted supporting material behind authorised access. The public presentation and the internal review pack may require different levels of detail.

Document the environment

Record the application build, relevant integration configuration, model or recogniser version where applicable and the date of the run. State whether the target is a mock, sandbox or production service.

A mock is useful for showing intended interaction, but it cannot establish a live integration’s delivery or permission behaviour. A sandbox can validate some behaviours while leaving production assumptions unresolved.

If a component cannot disclose an exact internal version, record the identifier and settings that are available. Explain the resulting reproducibility limit instead of filling the gap with a confident label.

Include the known dependencies and what happens if one is unavailable during the session. A prerecorded result should be identified as such rather than presented as a live execution.

Give reviewers a way to challenge the result

Prepare a short set of questions that the evidence can answer: What data crossed the boundary? Which permission allowed the action? What proves the target changed? What remains pending? What would happen if the event arrived twice?

Where the pilot includes automated detection, provide the evaluation scope and representative errors. Presidio’s evaluation guidance supports use-case-specific evidence rather than a single unexplained accuracy claim.

Before the demonstration, check:

• Every material claim has a scoped supporting artefact.
• Fixture origins and environment type are visible.
• Status labels correspond to documented evidence.
• A failure or uncertainty case is included.
• Sensitive material is restricted in both live views and shared exports.
• Planned work is separated from observed behaviour.
• Reviewers can record unresolved questions and their owners.

The meeting should end with a decision record, including what the evidence established and what requires further work. A demonstration becomes useful when it helps the audience assess a concrete workflow, with enough detail to disagree intelligently.