wiki content export 2026-03-24

content/wiki/hub/admin/00-setting-up-a-cohort.md

@@ -0,0 +1,55 @@
+# Setting Up a Cohort
+
+This page covers how to configure an existing cohort. Cohort creation is handled by system administrators -- once a cohort exists, you configure it from the cohort page.
+
+## Prerequisites
+
+You need cohort admin, org admin, or super admin access.
+
+## Cohort Lifecycle
+
+Every cohort moves through six stages. The current stage controls which tabs are visible and what actions are available.
+
+- `draft` -- Setup mode. Reviewers do not see this cohort. Configure settings, stages, and the application form here.
+- `review` -- Reviewers can score assigned applications. The **Decisions** tab is not yet visible.
+- `decide` -- Review is considered complete. The **Decisions** tab appears so you can accept, waitlist, or decline applicants.
+- `onboard` -- Decisions are finalized. The **Onboarding** tab appears for accepted participants.
+- `active` -- The cohort program is running. All admin tabs remain accessible.
+- `closed` -- The cohort is closed. Applications stop being accepted automatically. All data is preserved in read-only mode.
+
+You can move forward, skip stages, or move backward. No data is lost when moving between stages -- earlier-stage tabs and features are simply hidden or shown.
+
+## Changing the Cohort Stage
+
+1. Open the cohort page and click the **Settings** button (gear icon) in the top right.
+2. In the **Cohort Stage** section on the left, click the target stage in the pipeline.
+3. A confirmation modal shows what will happen. Review the implications and click **Confirm**.
+
+:::warning
+Moving to `closed` automatically disables application intake. Moving backward hides tabs associated with later stages but preserves all data.
+:::
+
+## Configuring Settings
+
+Click **Settings** to open the full-screen settings modal. From here you can:
+
+- **Cohort Name** -- Edit the display name.
+- **Cohort Slug** -- Edit the URL slug. This is locked once the cohort leaves `draft` status.
+- **Application Opens / Closes** -- Set the date range for the application window.
+- **Notification Emails** -- View which org admins receive new-application alerts. Manage recipients from **Team Settings**.
+- **Survey** -- Manage the survey version and scoring profile used for application questions.
+- **Organizations** -- Select which organizations can access this cohort.
+
+Click **Save Configuration** when done.
+
+## Accepting Applications
+
+In the settings modal under **Application Intake**, toggle **Accepting Applications** on or off. This controls whether the public apply form accepts new submissions. The toggle is disabled when the cohort is in `closed` status.
+
+## Archiving a Cohort
+
+In the settings modal under **Danger Zone**, click **Archive Cohort**. Archiving hides the cohort from the main list and stops accepting applications. All data is preserved. You can unarchive a cohort from the archived banner that appears at the top of its page.
+
+:::info
+Archiving is reversible. Click **Unarchive** on the archived banner to restore the cohort.
+:::

content/wiki/hub/admin/01-customizing-the-apply-form.md

@@ -0,0 +1,47 @@
+# Customizing the Apply Form
+
+The **Form** tab on the cohort page lets you customize the public application form's appearance and messaging. Changes are reflected on the live form at `/c/{cohort-slug}/apply`.
+
+## Prerequisites
+
+You need cohort admin or higher access. The cohort must have a survey configured in its settings (questions come from Flywheel).
+
+## Live Preview
+
+The top of the **Form** tab shows a live preview of the application form. As you edit fields below, the preview updates immediately. The preview renders actual survey questions from Flywheel, grouped into sections: Eligibility Requirements, Personal Information, Studio Information, Application Questions, and Supporting Materials.
+
+At the bottom of the preview, the confirmation message is shown as it will appear to applicants after submission.
+
+## Content & Messaging
+
+- **Form Title** -- The main heading on the application form.
+- **Badge Text** -- A small label displayed above the title (e.g., "Now Accepting Applications").
+- **Subtitle** -- A brief description shown below the title.
+- **Confirmation Message** -- The message applicants see after submitting their application.
+- **Support Email** -- Contact email displayed on the form for applicant questions.
+
+## Color Theming
+
+Click **Customize Colors** in the preview header to open the color palette. You can configure:
+
+- **Primary color** -- The accent color used for buttons, links, and highlights. Choose from 18 color options including black/white, red, blue, indigo, and more.
+- **Neutral color** -- The base gray tone used for backgrounds and borders. Options include gray, slate, zinc, neutral, and stone.
+- **Theme** -- Choose Light, Dark, or System (follows the visitor's device preference).
+
+The badge color automatically matches the primary accent color.
+
+## Next Steps Messaging
+
+These fields appear on the confirmation page after submission:
+
+- **Review Process** -- Tell applicants how long review takes.
+- **Decision Notification** -- When applicants will hear back.
+- **Onboarding Information** -- When the program starts if accepted.
+
+## Saving and Previewing
+
+Click **Save Changes** at the bottom of the page to persist your customization. Click **Preview** in the header to open the live public form in a new tab.
+
+:::tip
+Save your changes before previewing. The preview button opens the actual public form URL, which uses the last saved customization.
+:::

content/wiki/hub/admin/02-managing-applications.md

@@ -0,0 +1,51 @@
+# Managing Applications
+
+The **Applications** tab is the primary workspace for managing submitted applications. It provides search, filtering, grouping, inline actions, and bulk operations.
+
+## Prerequisites
+
+You need cohort admin or higher access. Reviewers are redirected to their interview dashboard instead.
+
+## Viewing Applications
+
+Applications appear in a table with the following columns: **Studio** (applicant name), **Pipeline** (current stage, lock status, interview date, self-assessment status), **Reviews** (completed/assigned count), **Consensus** (reviewer recommendation tallies), **Score** (cumulative percentage), and inline **Actions**.
+
+Click a studio name to open the full application detail page, which shows all answers, review history, and status timeline.
+
+## Searching and Filtering
+
+- **Search** -- Type in the search box to filter by studio name or email.
+- **Status** -- Filter by application status (e.g., `new`, `accepted`, `declined`).
+- **Stage** -- Filter by current review stage (Application Review, First Round, Second Round).
+- **Reviews** -- Filter by review progress: Not Assigned, Not Started, In Progress, or Complete.
+- **Province** -- Filter by applicant location. When Ontario is selected, a **GTA only** toggle appears.
+- **Hide declined** -- On by default. Toggle to show or hide declined applications.
+
+Active filters appear as removable tags below the filter bar. Click **Clear** to reset all filters. Filter state persists in your browser across sessions.
+
+## Sorting and Grouping
+
+Use the **Sort** dropdown to order applications by name, score, date, pipeline stage, interview date, or consensus (mixed first). Use the **Group by** dropdown to group by status, stage, review progress, or consensus. Groups can be expanded or collapsed individually or all at once.
+
+## Inline Actions
+
+The **Pipeline** column shows lock icons. A ready-to-lock icon appears when the minimum reviewer threshold is met. Click it to open a confirmation modal to lock the stage. Once locked, you can advance or decline the application from the **Actions** column.
+
+## Bulk Operations
+
+Select applications using the checkboxes, then open the **Bulk Actions** dropdown:
+
+- **Change to Declined** -- Decline all selected applications.
+- **Reset to New** -- Reset selected applications to `new` status.
+- **Lock/Unlock Stages** -- Lock or unlock stages in bulk.
+- **Advance to Next Stage** -- Advance locked applications to the next stage.
+- **Skip to Stage** -- Jump applications to a specific stage, bypassing intermediate ones.
+- **Assign Reviewers** -- Open the reviewer assignment modal for selected applications.
+
+## Orphaned Interviews
+
+If Cal.com bookings could not be matched to an application, an **Orphaned** warning button appears in the filter bar. Click it to open the matching modal and manually associate bookings with applications.
+
+## The Timeline Tab
+
+Org admins and super admins see an additional **Timeline** tab on the cohort page. This shows a per-cohort activity feed including review submissions, status changes, decisions, and other cohort-level events.

content/wiki/hub/admin/03-configuring-review-stages.md

@@ -0,0 +1,49 @@
+# Configuring Review Stages
+
+Review stages define the evaluation pipeline for your cohort. Each stage has its own rubric, reviewer requirements, and settings. You configure stages from **Manage** > **Configure Stages** in the top navigation -- not from within the cohort view.
+
+## Prerequisites
+
+You need cohort admin or higher access. The cohort must already exist with stages created by a system administrator.
+
+## Accessing Stage Configuration
+
+1. Click **Manage** in the top navigation bar.
+2. Select **Configure Stages**.
+3. Choose a cohort from the dropdown.
+
+The page shows configuration cards for three stage types: **Application Stage**, **First Round Interviews**, and **Second Round Interviews**.
+
+## Stage Types
+
+- **Application Reviews** (`application-reviews`) -- The initial written application review. Reviewers score the submitted application form against a rubric.
+- **First Round** (`first-round`) -- First-round interview scoring. Reviewers evaluate interview performance using a separate rubric.
+- **Second Round** (`second-round`) -- Final-round interview scoring. Uses its own rubric for the final evaluation.
+
+## Settings Per Stage
+
+Each stage card offers the following configuration:
+
+### Scoring Rubric
+
+Select the Flywheel rubric used for scoring this stage. Application stage rubrics score the written application; interview rubrics score interview performance. Rubrics are managed in Flywheel and appear here as a dropdown.
+
+### Minimum Reviewers
+
+Set the minimum number of completed reviews required before a stage can be locked. The default is 2. This threshold is enforced when locking -- you cannot lock a stage until this many reviewers have submitted scores.
+
+### Interview Question Reference (Interview Stages Only)
+
+For first-round and second-round stages, you can enter interview questions or talking points. This content is available to reviewers as a popup reference during scoring. Use `##` for section headers.
+
+## Saving
+
+Each stage has its own **Save Configuration** button. Click it after making changes. Minimum reviewer changes save immediately when you change the value.
+
+## Stage Statuses
+
+Each stage has a status: `draft`, `active`, `completed`, or `archived`. These are managed by the system as the cohort progresses. Stage statuses are separate from the cohort lifecycle status.
+
+:::info
+The Application stage also includes survey version management. This controls which version of the Flywheel survey is used for application questions and ensures scoring consistency.
+:::

content/wiki/hub/admin/04-assigning-reviewers.md

@@ -0,0 +1,52 @@
+# Assigning Reviewers
+
+Reviewer assignment is a two-step process: first add reviewers to the cohort, then assign them to specific applications. All assignment is manual -- there is no auto-assignment.
+
+## Prerequisites
+
+You need cohort admin or higher access.
+
+## Step 1: Add Reviewers to the Cohort
+
+The **Reviewers** tab on the cohort page shows all reviewers currently assigned to this cohort along with their assignment counts.
+
+1. Click **Add Reviewers**.
+2. A modal opens with two tabs:
+   - **Select Existing** -- Choose from users already in your organization. Select one or more users from the dropdown and click **Add Reviewers**.
+   - **Add New User** -- Create a new user account. Enter their name, email, and role (Reviewer, Cohort Admin, or Org Admin). Click **Create & Add as Reviewer**. They will receive a password setup email.
+3. After adding, you are prompted to optionally assign them to applications immediately (Step 2 below). You can skip this and assign later.
+
+## Step 2: Assign Reviewers to Applications
+
+Once reviewers are on the cohort, assign them to specific applications:
+
+### From the Reviewers Tab
+
+Click the assignment count next to a reviewer's name to open the **Manage Assignments** modal. This shows:
+
+- **Current Assignments** -- Applications already assigned to this reviewer, with permission level and scoring status. You can toggle between `review` and `view` permissions, or unassign applications.
+- **Add Applications** -- Select additional applications to assign. Choose a permission level and click **Assign**.
+
+### From the Applications Tab (Bulk)
+
+Select applications using the checkboxes on the **Applications** tab, then choose **Assign Reviewers** from the **Bulk Actions** dropdown. Select the reviewers and permission level, then confirm.
+
+## Permission Levels
+
+- `review` -- The reviewer can view the application and submit scores. This is the default.
+- `view` -- The reviewer can see the application but cannot score it. Useful for committee members or observers.
+
+Permission can be changed at any time from the **Manage Assignments** modal. Locked reviews cannot have their permission changed.
+
+## Removing Assignments
+
+- **Unassign from application** -- In the **Manage Assignments** modal, click the X button next to an assignment. Locked reviews cannot be unassigned.
+- **Remove from cohort** -- On the **Reviewers** tab, click the trash icon next to a reviewer to remove them from the cohort entirely.
+
+:::warning
+Removing a reviewer from the cohort does not delete their completed reviews. The reviews remain in the system but the reviewer loses access.
+:::
+
+:::info
+When a reviewer is assigned to an application, that application appears on their review dashboard at `/reviews`. Unassigning removes it from their dashboard.
+:::

content/wiki/hub/admin/05-interview-scheduling.md

@@ -0,0 +1,54 @@
+# Interview Scheduling
+
+Interview scheduling is handled through Cal.com integration. When applicants book interviews through Cal.com, the booking data flows into Cohort-OS automatically via webhooks.
+
+## Prerequisites
+
+Cal.com must be configured with the correct webhook URL and cohort ID. This is set up by system administrators.
+
+## How It Works
+
+Cal.com sends webhook events to Cohort-OS when bookings are created, rescheduled, or cancelled. The system matches bookings to applications by the applicant's email address.
+
+### Booking Created
+
+When an applicant books an interview:
+
+1. The system looks up the application by matching the booking email to the applicant's contact email.
+2. If a match is found, the interview schedule data (date, time, meeting link) is saved to the application.
+3. The application status updates automatically -- for example, from `waiting_first_round` to `first_round_scheduled`.
+4. The current stage is synced to match the new status.
+
+### Booking Rescheduled
+
+When an interview is rescheduled, the schedule data (date, time, meeting link) is updated on the application. The application status is not changed.
+
+### Booking Cancelled
+
+When an interview is cancelled:
+
+- The schedule data is cleared from the application.
+- If the application is currently in a `*_scheduled` status, it reverts to the corresponding `waiting_*` status.
+- Applications in other statuses keep their current status.
+
+## Orphaned Interviews
+
+If a Cal.com booking email does not match any application in the cohort, the booking becomes an "orphaned interview." When this happens:
+
+- The booking is saved to an orphaned interviews table.
+- Org admins receive an email alert with the booking details.
+- An **Orphaned** warning badge appears on the **Applications** tab filter bar with a count of unmatched bookings.
+
+To resolve orphaned interviews, click the **Orphaned** badge to open the matching modal. From there you can manually match the booking to the correct application.
+
+## Interview Status on Applications
+
+The **Pipeline** column on the **Applications** tab shows interview scheduling information:
+
+- Applications in `waiting_first_round` or `waiting_second_round` show they are awaiting scheduling.
+- Applications in `first_round_scheduled` or `second_round_scheduled` show the scheduled interview date and time.
+- Past interview dates appear with strikethrough text.
+
+:::info
+Webhook events are deduplicated using the Cal.com event ID. Processing the same event twice has no effect. Applications in terminal statuses (`accepted`, `waitlist`, `declined`) do not have their status changed by new bookings.
+:::

content/wiki/hub/admin/06-locking-reviews-and-consensus.md

@@ -0,0 +1,55 @@
+# Locking Reviews & Consensus
+
+Locking is the mechanism that finalizes review scores for a stage and prepares an application for advancement or decision-making. Consensus data gives you a summary of how reviewers scored and what they recommended.
+
+## Prerequisites
+
+You need cohort admin or higher access. Reviews must be completed before locking.
+
+## When to Lock
+
+Lock a stage when the minimum number of reviewers have submitted their scores. The minimum is configured per stage (default: 2). You can see review progress in the **Reviews** column on the **Applications** tab -- it shows completed/assigned counts.
+
+The lock icon in the **Pipeline** column indicates readiness:
+
+- **Open lock (dimmed)** -- Not enough reviews completed yet. Hover to see how many more are needed.
+- **Open lock (visible)** -- Minimum reviewers met. Ready to lock.
+- **Closed lock** -- Stage is locked.
+
+## How to Lock
+
+### Single Application
+
+Click the lock icon in the **Pipeline** column, or click **Lock** in the **Actions** column. A confirmation modal appears. Click **Confirm** to lock.
+
+### Bulk Locking
+
+Select multiple applications using the checkboxes, then choose **Lock Stages** from the **Bulk Actions** dropdown. Only applications that meet the minimum reviewer threshold will be locked. The dropdown shows how many are eligible.
+
+## What Locking Does
+
+- Prevents reviewers from editing their scores for this stage.
+- Records who locked the stage and when.
+- Automatically transitions the application status:
+  - Locking the final stage sets the status to `needs_final_decision`.
+  - Locking the first-round stage sets the status to `needs_first_decision`.
+
+## Viewing Consensus
+
+Once reviews are completed, you can view consensus data for any application. The **Consensus** column on the **Applications** tab shows recommendation tallies (e.g., "2x Advance, 1x Hold"). Hover over the consensus cell to see a popover with each reviewer's name, recommendation, and score percentage.
+
+For detailed consensus, open an application and view its review consensus page. This shows:
+
+- **Per-reviewer breakdown** -- Each reviewer's total score, percentage, recommendation, and notes. In blind review mode, reviewer identities are hidden from other reviewers (admins always see names).
+- **Per-criterion comparison** -- Average, min, max, and spread for each scoring criterion across all reviewers. Criteria with high spread (disagreement) are flagged.
+- **Aggregate stats** -- Average score, average percentage, recommendation counts, and whether all reviews are complete and locked.
+
+## Unlocking
+
+If you need to allow a reviewer to make changes after locking, click the closed lock icon on a locked application. A confirmation modal appears. Click **Confirm** to unlock. This reverts the stage to its pre-locked state.
+
+You can also unlock in bulk via the **Bulk Actions** dropdown.
+
+:::warning
+Unlocking a stage allows reviewers to edit their scores again. The application status does not automatically revert -- you may need to manage status transitions manually.
+:::

content/wiki/hub/admin/07-making-decisions.md

@@ -0,0 +1,58 @@
+# Making Decisions
+
+The **Decisions** tab provides a ranked view of applicants and tools to record accept, waitlist, or decline decisions. It appears when the cohort reaches the `decide` stage.
+
+## Prerequisites
+
+You need cohort admin or higher access. The cohort must be in `decide`, `onboard`, `active`, or `closed` status.
+
+## The Decision Dashboard
+
+The **Decisions** tab shows:
+
+- **Statistics cards** -- Total applications, accepted count, waitlisted count, and declined count.
+- **Ranked Applicants table** -- All applications with review scores, sorted by average score (highest first). Each row shows rank, studio name, contact name, email, average score percentage, review count, and current decision status.
+
+Applications appear here once they have review scores or are already in a terminal status (`accepted`, `waitlist`, `declined`).
+
+## Making a Decision
+
+### Single Application
+
+Click the dropdown menu (three dots) on any row. Choose **Accept**, **Waitlist**, or **Decline**. The decision is recorded immediately and the application status updates.
+
+You can also click **View Reviews** to open the application detail page and review scores before deciding.
+
+### Bulk Decisions
+
+1. Select applications using the checkboxes in the leftmost column. Use the header checkbox to select all.
+2. Click **Accept**, **Waitlist**, or **Decline** in the header buttons. The count of selected applications is shown on each button.
+3. Decisions are applied to all selected applications. If some applications cannot transition to the chosen status (e.g., already decided), those are skipped and you receive a partial update notification.
+
+## Decision Records
+
+Each decision creates a record in the Decision model with:
+
+- **Decision** -- `accepted`, `waitlist`, or `declined`.
+- **Decided at** -- Timestamp of the decision.
+- **Rationale** -- Optional text explaining the reasoning.
+- **Rationale code** -- Optional code for categorizing the reason.
+- **Committee notes** -- Optional notes from committee discussion.
+
+:::info
+Decisions enforce valid status transitions. You cannot re-decide a `declined` application to `accepted` without first changing its status. Waitlisted applications can transition to `accepted` or `declined`.
+:::
+
+## Workflow
+
+The typical decision workflow is:
+
+1. Lock all reviews for the relevant stage (see Locking Reviews & Consensus).
+2. Review consensus data and scores on the **Decisions** tab.
+3. Hold a committee discussion if needed.
+4. Record decisions individually or in bulk.
+5. Move the cohort to `onboard` status when all decisions are finalized. If all decisions are made through the bulk decision endpoint, the cohort may automatically transition to `onboard`.
+
+## After Decisions
+
+Once decisions are recorded, the **Email Tasks** tab shows which applicants need to be notified. Accepted applicants will appear on the **Onboarding** tab when the cohort reaches `onboard` status.

content/wiki/hub/admin/08-email-tasks.md

@@ -0,0 +1,55 @@
+# Email Tasks
+
+The **Email Tasks** tab tracks which applicants need to be notified and provides a record of completed notifications. It appears as a tab on the cohort page, with a badge count showing pending items.
+
+## Prerequisites
+
+You need cohort admin or higher access.
+
+## Notification Types
+
+The system tracks six notification types based on application status:
+
+- **1st Round Scheduling** -- Applicants in `waiting_first_round` or `first_round_scheduled` who have not been sent a scheduling link.
+- **2nd Round Scheduling** -- Applicants in `waiting_second_round` or `second_round_scheduled` who have not been sent a scheduling link.
+- **Acceptance** -- Applicants with `accepted` status who have not been notified.
+- **Waitlist** -- Applicants with `waitlist` status who have not been notified.
+- **Decline** -- Applicants with `declined` status who have not been notified.
+
+## Pending Notifications
+
+The top section shows applications awaiting notification. Each row displays the studio name, contact email, current status, notification type, and a **Mark Done** button.
+
+Use the type filter dropdown in the header to narrow the view to a specific notification type. The filter shows counts for each type.
+
+## Marking Notifications as Done
+
+Notification sending happens outside of Cohort-OS (you compose and send emails manually). When you have sent a notification:
+
+1. Click **Mark Done** on the corresponding row.
+2. A modal appears with:
+   - **Date & time sent** -- Pre-filled with the current time. Adjust if the email was sent earlier.
+   - **Sent by** -- Pre-filled with your name. Change if someone else sent the notification.
+3. Click **Confirm** to record the notification.
+
+The application moves from the pending list to the completed list. The badge count on the **Email Tasks** tab updates accordingly.
+
+## Completed Notifications
+
+The bottom section shows all recorded notifications. Each row displays the studio name, contact email, notification type, date notified, and who marked it as sent.
+
+### Editing a Notification
+
+Click the edit icon on any completed notification to update the sent date or the person who sent it. Click **Save** to confirm changes.
+
+### Deleting a Notification
+
+In the edit modal, click **Delete** to remove a notification record. This moves the application back to the pending list.
+
+## Tab Badge Count
+
+The **Email Tasks** tab shows a badge with the count of pending notifications. This updates in real time as you mark items done or as application statuses change.
+
+:::tip
+Use the type filter to work through notifications by category. For example, filter to "Acceptance" after making batch accept decisions, and work through the list in one pass.
+:::

content/wiki/hub/admin/09-self-assessments.md

@@ -0,0 +1,42 @@
+# Self-Assessments
+
+Self-assessments are confidential surveys sent to individual team members of applicant studios. They are typically used during later interview stages to gather independent perspectives from each team member.
+
+## Prerequisites
+
+You need cohort admin or higher access. The application must be at a stage where self-assessments are relevant (typically `waiting_second_round` or `second_round_scheduled`).
+
+## How Self-Assessments Work
+
+Self-assessments use token-based access. Each team member receives a unique link that does not require a login. The link takes them to a form at `/c/{cohort-slug}/assessment/{token}` where they complete the survey independently.
+
+Responses are confidential -- they are not shared with the applicant's teammates. The form includes sections like About You, Capacity, Your Role, Co-op Readiness, and Looking Ahead. Questions may include conditional logic where follow-up questions appear based on previous answers.
+
+## Sending Self-Assessments
+
+Self-assessment invitations are managed from the application detail page. An admin initiates the process by entering the names and emails of each team member. Each member receives an email with their unique assessment link.
+
+## Tracking Completion
+
+The **Applications** tab shows self-assessment status in the **Pipeline** column for applications in second-round stages:
+
+- **"Self-assessment not sent"** (highlighted) -- No assessments have been initiated for this application.
+- **"Self-assessment: X/Y"** -- X of Y team members have completed their assessment.
+
+The `SelfAssessmentStatus` component on the application detail page provides a detailed view:
+
+- A progress bar showing completion percentage.
+- Each member listed with their status: **Completed**, **Pending**, or **Cancelled**.
+- Completed members can be expanded to view their responses.
+
+## Resending Emails
+
+If a team member has not received or has lost their assessment link, you can resend the email from the application detail page. The resend updates the `lastResentAt` timestamp for that member.
+
+## Cancelling a Member
+
+If a team member should no longer complete the assessment (e.g., they left the studio), you can cancel their invitation. Cancelled members are excluded from the completion count and their status shows as **Cancelled**.
+
+:::info
+Self-assessment responses are stored directly on the application document under `selfAssessment.members[].responses`. Each member's token, sent date, completion date, and last access time are tracked for audit purposes.
+:::

content/wiki/hub/admin/10-onboarding.md

@@ -0,0 +1,45 @@
+# Onboarding
+
+The **Onboarding** tab tracks post-acceptance tasks for accepted participants. It appears when the cohort reaches the `onboard` stage.
+
+## Prerequisites
+
+You need cohort admin or higher access. The cohort must be in `onboard`, `active`, or `closed` status. At least one application must have `accepted` status.
+
+## Viewing Participants
+
+The **Onboarding** tab displays accepted participants in a card layout with two sections:
+
+- **Participants list** (left, two-thirds width) -- Each participant card shows their studio name, contact name, email, and a completion badge showing their progress percentage. A progress bar provides a visual indicator.
+- **Onboarding Stats** sidebar (right, one-third width) -- Shows total accepted count, overall progress percentage with a progress bar, and the count of pending tasks across all participants.
+
+If no applications have been accepted yet, the tab shows an empty state message.
+
+## Checklist Items
+
+Each participant has an onboarding checklist. Items are displayed as checkboxes within each participant card. Checking an item records who completed it and when. Completed items show a strikethrough label and the completion date.
+
+To toggle a checklist item, click the checkbox next to it. The change saves automatically.
+
+:::info
+Onboarding checklist items are defined per application. The specific items depend on how the onboarding template is configured for the cohort.
+:::
+
+## Notes
+
+Each participant card has a notes section at the bottom. Click **Add notes** (or **Edit** if notes exist) to open an inline editor. Type your notes and click **Save**. Notes are free-form text for any onboarding-related information.
+
+## Progress Tracking
+
+Progress is calculated as the percentage of completed checklist items out of total items. The color of the completion badge changes based on progress:
+
+- 100% -- green (complete)
+- 75%+ -- blue
+- 50%+ -- yellow
+- Below 50% -- red
+
+The sidebar shows the overall progress averaged across all participants and the total count of pending (unchecked) tasks.
+
+:::tip
+Use the notes field to record any special requirements or follow-up items for individual participants. This keeps onboarding context in one place.
+:::

content/wiki/hub/admin/11-team-and-settings.md

@@ -0,0 +1,73 @@
+# Team & Settings
+
+Team management and the activity feed are accessed from the **Manage** dropdown in the top navigation. These pages let you invite users, assign roles, and monitor what is happening across your organization.
+
+## Prerequisites
+
+You need org admin or super admin access.
+
+## Team Members
+
+Navigate to **Manage** > **Team Members** to view and manage your organization's users. The page shows a searchable table with each user's name, email, role, and status.
+
+### User Statuses
+
+- **Active** -- User has accepted their invite and set up their password.
+- **Invite pending** -- User has been created but has not set up their password yet.
+- **Inactive** -- User has been deactivated and cannot log in.
+
+### Inviting a New User
+
+1. Click **Add Team Member**.
+2. Choose **Create New** (default) or toggle to **Add Existing** if the user already exists in another organization.
+3. For new users, enter their name, email, and role. Click **Create User**.
+4. The user receives an email with a link to set up their password.
+
+### Roles
+
+- **Reviewer** -- Can view and score applications they are explicitly assigned to.
+- **Cohort Admin** -- Can manage cohort settings and make decisions.
+- **Org Admin** -- Can manage organization settings, team members, and all cohorts.
+- **Super Admin** -- Full system access (only assignable by super admins).
+
+### Managing Users
+
+Click the dropdown menu (three dots) on any user row for options:
+
+- **View Profile** -- Open the user's profile page.
+- **Edit** -- Change the user's role.
+- **Re-invite User** -- Send a new password setup link to the user's email.
+- **Deactivate/Activate** -- Toggle the user's active status. Deactivated users cannot log in.
+- **Remove from Organization** -- Permanently remove the user from your organization.
+
+:::warning
+Removing a user from the organization is permanent. Their completed reviews are preserved, but they lose all access.
+:::
+
+## Activity Log
+
+Navigate to **Manage** > **Activity Log** to view the organization-wide activity feed. Events are grouped by day with the most recent events first.
+
+Each event shows:
+
+- **Category badge** -- Color-coded by type (auth, user management, cohort management, reviews, decisions).
+- **Event description** -- What happened.
+- **User and timestamp** -- Who performed the action and when.
+- **Details** -- Additional context such as changed fields, status transitions, or avatar changes.
+
+### Filtering
+
+Use the filter dropdown in the header to narrow events by category:
+
+- All Actions
+- Auth (Login/Logout)
+- User Management
+- Cohort Management
+- Reviews
+- Decisions
+
+Click **Load more** at the bottom to see older events. The feed loads 50 events at a time.
+
+:::info
+The activity log records over 50 distinct action types including logins, user creation, cohort updates, review submissions, decision pushes, stage locks, and more. All actions include the user who performed them and relevant details.
+:::