Tell the planner where your recovery practice stands and which systems matter, and it proposes a drill you could run: a first exercise, a scenario, roles, success criteria, the evidence to capture and a cadence, with the reason for each choice.
How the planner decides
Six of your answers (last test restore, what it covered, RTO, RPO, runbook, backup protection) are scored from worst to best, and the total is shown as a gap indicator out of 18. The indicator is a count of foundations not yet in place, and nothing more.
The first exercise is chosen by fixed rules. With nowhere isolated to restore into, the plan is a tabletop, because any exercise that really restores data is unsafe without isolation. With an isolated environment, the plan is a functional restore of one system. A timed, ordered service restore is proposed only when you report a recent whole-system restore and a written runbook. A failover or interruption exercise is proposed only when you also report written targets, a runbook that someone else has followed, a protected copy of the backups and an agreed maintenance window. Better answers never lower the level, which the tool’s tests check.
The restore order is guessed from keywords in the system names: identity, name resolution and network first, then storage, hypervisors and databases, then applications, then web front ends and portals. It is a heuristic. Correct it against your real dependencies, as described in designing a recovery drill.
What it will not tell you
The planner cannot tell you whether your backups are intact, whether a restore would work, or how long one would take. Those can be found out only by running the exercise, which restore testing and backup validation explain. The cadence it suggests is a set of starting points rather than a requirement from any standard, and the roles are a typical split, not a prescription. After you run an exercise, the after-action review guide covers what to record and how to turn findings into fixes.