Choose a form for the uncertainty.
A sketch can help discuss where information appears. A physical mock-up may help someone consider reach or arrangement. A small software demonstration can make a sequence visible. The form should follow the question rather than a desire to make everything look complete.
For a visitor check-in example, paper screens may be enough to discuss acknowledgement wording. They would not show whether a real record is saved, whether a connection remains available, or how access permissions work.
Explain what is represented.
Tell participants which parts are functional, which are simulated, and which are absent. A polished appearance can create expectations that the model cannot meet. Clear boundaries help people comment on the relevant question.
The illustrative sequence on this page represents only a discussion aid. It has no working check-in function and does not describe a B Squared product. Keeping that distinction visible is part of presenting a model responsibly.
Keep changes connected to learning.
When a model is revised, record the reason. A change may respond to an observed misunderstanding, a newly identified constraint, or an alternative worth exploring. Without that context, successive versions can look different without showing what was learned.
A model is not automatically evidence of readiness. Further work may be needed to examine reliability, accessibility, safety, cost, or other requirements in the relevant setting. The next step depends on the question and the limits of the representation.
A visitor indicates they are here.
The visitor sees a clear response.
The visitor knows what to do next.