Decisions and bulk actions

Where decisions live

Open Admin → Submissions. Each submission can receive a recorded decision: accept, reject, or waitlist. Decisions are domain commands with audit events and correlation identifiers. High-risk automation uses the decisions:write scope, which is default-deny on new API keys.

Record a decision

Review evaluation scores and comments. Select the submission, choose accept, reject, or waitlist, and include a reason when your program requires it. Save once — re-deciding should be intentional and audited.

1. Filter submissions to the decision cohort (for example scored or submitted).
2. Open a submission detail and review scores plus answers.
3. Choose accept, reject, or waitlist and add a reason if required.
4. Confirm the decision and verify status updates in the list.
5. For accepts, open Speakers admin and portal tasks to confirm side effects.

Side effects of accept

Accept links or creates person and participation records for speakers on the proposal. Task templates for the event generate speaker_tasks the portal will show. Reject and waitlist do not create the same portal workload. Comms templates can later target decision states when you draft messages.

Submission is not the same as session. Accepting does not by itself place a room and time; schedule studio handles placement after the program team builds sessions.

Bulk and agent paths

When the UI offers bulk actions, use them only after a reviewed shortlist. Agents can call decisions record via the CLI with an explicit scope grant. Prefer --json and treat exit code 2 as missing authorization, not a retry signal.

speakerops decisions record --submission <id> --decision accept --reason 'Program committee' --json