> For the complete documentation index, see [llms.txt](https://synap.ac/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://synap.ac/docs/platform/exams/overview.md).

# Overview

Exams let you deliver quiz content to students under a defined set of rules. You choose who can take the exam, when it is available, how it behaves in the player, how answers are marked and what students see afterwards.

The editor divides these choices across several pages, but students experience them as one journey. A clear exam setup should answer five simple questions: what will I take, when can I take it, how long do I have, what can I use during it, and what happens after I submit?

{% hint style="info" %}
It helps to work from the questions outwards: choose the content first, then decide how students will take it, and finally configure marking and results. Some settings affect one another. For example, manually marked questions can delay results, relative deadlines give students different closing dates, and proctoring changes what students need to do before they can begin.
{% endhint %}

```mermaid
flowchart LR
  A["Prepare<br/>Questions, scoring, timing and publish"] --> B["Deliver<br/>Register, Exam Hall, sit and submit"]
  B --> C["Complete<br/>Mark, finalise, release, resit or certificate"]
```

*An exam moves from administrator setup to the student journey, then into marking and results.*

### Exam lifecycle

| Area      | What you configure                                         | What it changes                                                |
| --------- | ---------------------------------------------------------- | -------------------------------------------------------------- |
| Setup     | Name, type, source quiz and registration model             | Defines what the exam is and who it belongs to                 |
| Build     | Questions, sections, scoring and grades                    | Defines what is assessed and how marks become outcomes         |
| Configure | Experience, instructions, results, resits and certificates | Defines what candidates see and what happens after submission  |
| Advanced  | Security, legal terms, marking and proctoring              | Controls access, monitoring and any human review               |
| Schedule  | Open/close rules, candidate deadlines and communication    | Defines when each candidate can take the exam                  |
| Publish   | Validate and publish a version                             | Freezes the version used to generate attempts                  |
| Deliver   | Register candidates and monitor attempts                   | Creates and manages candidate-specific assessment records      |
| Finish    | Mark, finalise, release and review                         | Completes the attempt and makes the intended results available |

### Settings that need to be reviewed together

| Decision                                | Also check                                                   | Why                                                                    |
| --------------------------------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------- |
| Change the source quiz or dynamic rules | Version management, scoring and rehearsal attempts           | New papers must remain valid and comparable                            |
| Change timer or navigation              | Sections, instructions, access arrangements and proctoring   | A reasonable setting alone can become restrictive in combination       |
| Change registration timing              | Relative candidate deadlines and automated email             | Registration can start the candidate's clock and trigger communication |
| Change manual-marking content           | Results release, finalisation and staff capacity             | Candidates may otherwise receive an incomplete or delayed result       |
| Change result visibility                | Resits, certificates and question disclosure                 | A result can trigger the next attempt or expose reusable content       |
| Change security or proctoring           | Device requirements, support plan and candidate instructions | The setting changes what candidates must prepare before exam day       |

### Before publishing

Use this checklist as a minimum pre-flight review:

1. Confirm the source quiz and question count, including dynamic selection rules.
2. Test scoring, penalties and every grade boundary with representative scores.
3. Preview the candidate player, instructions, permitted tools and navigation.
4. Decide whether results are automatic or require marking, finalisation or proctoring review.
5. Confirm schedule timezone, candidate deadline behaviour and resit cut-offs.
6. Test access controls, passcodes, Internet Protocol (IP) restrictions and proctoring requirements on the intended devices.
7. Register internal test candidates and complete at least one end-to-end attempt.
8. Check automated email content and timing with a real test inbox.

{% hint style="warning" %}
Publishing is not the same as opening an exam. Publishing creates the version that new attempts will use; the schedule controls when students can start it.
{% endhint %}

### Rehearse as a candidate

Preview is useful while building, but a registered test candidate exposes the complete workflow: email, authentication, schedule, access checks, instructions, player, submission and results. Use at least one normal candidate and one candidate with a representative access arrangement. Where an exam is proctored, include the actual supported device and proctoring pre-flight.

### Where to go next

* **Exam setup** covers type, source, registration and versioning.
* **Questions and structure** and **Dynamic exam selection** cover assessment assembly.
* **Grading and scoring** explains marks, penalties, grade bands and section criteria.
* **Candidate experience** covers modes, timers, navigation, tools and instructions.
* **Scheduling and communication** explains fixed and relative windows in depth.
* **Marking**, **Security and legal terms** and **Proctoring** cover controlled delivery.
* **Attempts and monitoring** and **Statistics** cover live administration and reporting.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://synap.ac/docs/platform/exams/overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.