# Exploratory session charter

## Mission
Explore [feature or boundary] with [accounts and data] to discover [failure or uncertainty].
- Business consequence if this fails:
- Build / environment / supported client:
- Tester / reviewer / time box:
- Starting state and safe test data:
- Excluded areas:

## Investigation prompts
- What changes for another role or organisation?
- What happens after cancellation, interruption or a repeated action?
- Which empty, expired, malformed or boundary values matter?
- Does keyboard operation expose a different failure?
- Which assumption in the specification needs confirmation?

## Session notes
| Time | Variation explored | Observation | Evidence / next question |
| --- | --- | --- | --- |
| | | | |

Distinguish an observed product problem from a setup failure or an undecided requirement. Capture enough starting state for a later reproduction.

## Debrief
- Paths explored and paths left untested:
- Reproducible defects and private issue links:
- Product questions and decision owners:
- Candidate regression checks:
- Follow-up owner and next review:

## Filled mission — fictional
Explore invitation acceptance with an ordinary member, an organisation administrator and an account in a different organisation to discover permission or state-transition failures. Use staging with synthetic addresses and a 45-minute time box. Exercise new, expired, cancelled and already-used invitations. Exclude delivery-provider resilience from this session and arrange it separately.

Example observation: accepting a cancelled invitation displays a generic error. The charter records the observed response; the feature owner must confirm the intended message before it is classified as a defect. A second tester can repeat the recorded steps, while the original tester investigates whether the account state changed despite the refusal.