Skip to content
Pondara Pondara docs

Author a scenario

A scenario is a real professional situation. Authoring it means writing the parts that make the situation behave like itself — so a learner who runs it is practising against your field, not against a generic training exercise. You are the authority on what would actually happen on the floor.

Before you begin

Pick a real situation from your work that learners need to practise. Have it in your head as one paragraph: who is involved, what just happened, what the learner walks into, why it matters. If you can tell a colleague the situation in two sentences, you are ready.

Step 1 — Identity

Give the scenario a title, a slug (a short URL identifier — auto-generated from the title; only edit if you need to), the field it belongs to, and an optional role tag (service advisor, technician, ward nurse). The role tag helps trainers filter scenarios later; it is a tag, not a separate entity.

Step 2 — Trigger

Write the situation in one paragraph. What happened. What is at stake. What the learner walks into. Concrete beats abstract — “the patient’s SpO₂ dropped to 88% during the handover” beats “the patient is unstable”.

Step 3 — Actors

Each actor has a role name (the customer, the patient, the charge nurse) and a role brief — what they want, what they are willing to give, how they speak, what they will not say unprompted. The AI plays them in the hybrid dialogue, so the brief carries the weight. A thin brief produces a thin actor; invest here.

See scenario actors for the full shape.

Step 4 — Engagement phases

The default sequence is Interpret → Attempt → Reflect → (optional) Theory → (optional) Re-attempt. Edit the phase list only when the field genuinely demands it — for instance, a scenario with a hard hand-off mid-attempt. If the default fits, leave it.

See engagement phases for what each phase is for.

Step 5 — Competency vector

Pick which of the eight sub-competencies this scenario exercises and at what target level. A scenario does not need to exercise all eight — most exercise three or four well.

Step 6 — Weights

How strongly each dimension contributes to the evidence drawn from this scenario. A customer-conversation scenario weights Communication, Situational Awareness, and Decision-Making heavily and Domain Knowledge lightly. A technical-inspection scenario inverts that. The weights are your call as the field expert.

See weights.

Step 7 — Variants (optional)

Variants are modifiers like “high-pressure”, “language barrier”, or “after-hours” that adjust how the scenario plays without forking it into a separate scenario. Up to three. Use them when the same core situation has a few flavours practitioners would recognise as the same scenario.

Step 8 — Success criteria

What does a competent run look like? Two or three sentences naming the moves a competent practitioner makes and the things they avoid. This is reference material for the trainer rendering verdicts, not a pass/fail rubric — leave room for judgement.

Step 9 — Submit for validation

Two peers in your field will sign off. One sign-off is allowed if your field has only one expert in the platform. AI-suggested scenarios follow the same gate; the AI cannot bypass peer validation.

See validate a peer draft for what your peers will be looking for.

When something goes wrong

  • The form blocks submission. The realism preview surfaced an issue. Open it, address what is real, override what is not, and try again. See run the realism preview.
  • Your actor brief feels thin. Practitioners almost always catch thin briefs in peer validation. Invest the extra ten minutes now — another sentence on what the actor will and will not say is usually the difference.
  • You’re unsure about the weights. Ask another expert in your field. If two of you disagree on the weights, that is a sign the scenario actually exercises a different mix than you first thought.