> For the complete documentation index, see [llms.txt](https://docs.lamsfoundation.org/lams/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lamsfoundation.org/lams/tools/peer-and-self-evaluation/monitor.md). # Monitor ## Summary The **Summary section** provides you with a **clear, structured overview of peer and self-evaluation results at team level**. It is designed to help you **quickly interpret contributions, identify patterns, and take action**.

### Team Overview Each team is displayed as a **collapsible panel**, for example: * *Team Code Blue Crew* * *Team Grey Matter Collective* * *Team IV Leaguers* ### Criteria-Based Results Within each team, results are organised by the **evaluation criteria you defined**. Each criterion appears as a separate item: ## Example #### Contribution to Clinical Discussion View **star ratings** and associated comments helping you **who contributed most effectively** and overall **quality of participation and reasoning**.

#### Overall Contribution to the Group Task (Ranking) Displays how **students ranked each other** (and themselves). Allows you to **identify top contributors**, **detect low participation** and **see consistency or disagreement** in rankings

{% hint style="info" %} **The lower the rank indicates top ranked individual** {% endhint %} #### Distribution of Contribution (Hedging) Shows how students **allocated points across the team members.** Provides you an insight into: * **Perceived effort and contribution** * **Whether contribution was balanced or uneven** * **This feeds directly into SPA calculations for fairness**

#### Qualitative Constructive Feedback (Comments) Displays **qualitative feedback** provided by students. You can review: **strengths highlighted**, **areas for improvement** and **specific examples of behaviour**.

{% hint style="info" %} ### Gives you insights into * Understanding team dynamics * Identifying communication or collaboration issues {% endhint %} #### Rubrics Shows **rubric-based evaluations** for the team. Allows you to review performance against **structured criteria** and identify **strengths and weaknesses across key competencies**.

### Share Results with Students Notify team members of results: sends each student their peer and self-evaluation results ## Analytics The **Analytics section** provides a **team-level overview of activity completion**, allowing you to quickly see **which teams have completed the evaluation, which are in progress, and which have not started**. This is especially useful for managing **participation, timing, and follow-up actions**.

### Team Completion Summary Each team is displayed as a separate card, giving you a clear snapshot of their progress. #### Team Name * Displays the name of the team (e.g. *Team Code Blue Crew*) * Helps you quickly identify and compare teams *** #### Completion Status Badge Each team has a clear status indicator: * **Complete (green)** → All students have finished * **In progress (yellow)** → Some students have completed * **Not started (grey)** → No students have begun ## Advanced Settings The **Settings section** in the monitoring interface allows you to r**eview and adjust key behaviour settings of the activity**, even after it has been deployed. This gives you flexibility to **control visibility, reflection, and integrity of the evaluation process**.

--- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.lamsfoundation.org/lams/tools/peer-and-self-evaluation/monitor.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.