wiki content export 2026-03-24

content/wiki/hub/00-overview.md

@@ -0,0 +1,35 @@
+# Overview
+
+Cohort-OS is a web application for running cohort programs end-to-end. It collects applications through a public form, coordinates peer review with rubric-based scoring, records accept/waitlist/decline decisions, and tracks onboarding tasks.
+
+## The Four Phases
+
+Every cohort moves through four lifecycle phases, reflected by its status:
+
+1. **Apply** -- The cohort accepts applications through a public form. Applicants fill out questions from a shared question pool, and submissions appear in the **Applications** tab. The cohort status during this phase is `draft` or `active` with application acceptance turned on.
+
+2. **Review** -- Reviewers score applications against a rubric using a guided scoring interface. Admins assign reviewers to specific applications, configure review stages (first round, second round), and monitor progress. The cohort status is `review`.
+
+3. **Decide** -- Admins lock completed reviews, view consensus scores and percentiles, and record decisions (accept, waitlist, or decline) with rationale codes and committee notes. The cohort status is `decide`.
+
+4. **Onboard** -- Accepted applicants move into onboarding, where admins track checklist items and completion. The cohort status is `onboard`.
+
+After onboarding wraps up, a cohort can be moved to `active` (program is running) or `closed` (program is complete). Cohorts can also be archived at any point.
+
+## Roles
+
+Your role determines what you see and what you can do.
+
+- **Cohort admin** (includes org admins) -- Full access to cohort management: applications, reviewer assignments, review stages, decisions, email tasks, onboarding, and team settings. Cohort admins see the **Cohorts** dropdown and the **Manage** dropdown in the top navigation bar.
+
+- **Reviewer** -- Access to assigned applications for scoring and interviews. Reviewers see **My Reviews** in the top navigation bar, which links to a dashboard of their current assignments across all cohorts.
+
+Both roles can access **Settings** to manage their profile and password.
+
+## Key Terms
+
+- **Stage** -- A review round within a cohort (e.g., first round, second round). Each stage has its own reviewer assignments, scoring, and settings.
+- **Rubric** -- A set of scoring criteria provided by Flywheel, the external assessment engine. Reviewers score each criterion on a defined scale.
+- **Consensus** -- The aggregated view of all reviewer scores for an application in a given stage, including averages and percentiles.
+- **Ghostie** -- Your avatar in Cohort-OS. You pick an expression and a color, and it renders as a small ghost illustration next to your name throughout the app.
+- **Flywheel** -- The external assessment engine that provides rubrics, scoring logic, surveys, and reporting.

content/wiki/hub/01-logging-in-and-your-profile.md

@@ -0,0 +1,58 @@
+# Logging In & Your Profile
+
+This page covers how to access Cohort-OS for the first time, how to sign in on return visits, and how to manage your profile and security settings.
+
+## First-Time Setup
+
+When an admin adds you to the team, you receive an invite email with a setup link. That link takes you to the **Set Your Password** page, where you choose a password (minimum 6 characters) and confirm it. Submitting the form sets your password and logs you in automatically -- you land on your **My Reviews** dashboard.
+
+:::warning
+Setup links expire. If your link no longer works, ask your admin to resend the invite, or use the forgot-password flow described below.
+:::
+
+## Signing In
+
+Go to the login page and enter your email and password, then click **Sign in**. After a successful login you are redirected to your **My Reviews** dashboard.
+
+If you enter incorrect credentials, an error message appears at the top of the form.
+
+## Forgot Password
+
+If you cannot remember your password:
+
+1. Click **Forgot your password?** on the login page.
+2. Enter your email address and click **Send Reset Link**.
+3. Check your inbox for a reset email. Click the link in the email.
+4. On the **Set Password** page, enter and confirm your new password (minimum 6 characters), then click **Reset Password**.
+5. You are logged in automatically and redirected to your dashboard.
+
+:::info
+The reset confirmation always says a link was sent, even if no account exists with that email. This is intentional -- it prevents revealing which email addresses have accounts.
+:::
+
+## Your Profile
+
+Open your profile by clicking your name (with your ghostie avatar) in the top-right corner of the navigation bar, or by navigating directly to **Settings**.
+
+### Profile Section
+
+The **Profile** section shows your current information in a compact list:
+
+- **Avatar** -- Your ghostie. Click **[CHANGE]** to open the avatar picker (see below).
+- **Name** -- Click **[EDIT]** to update inline. Press Enter or click **[SAVE]** to confirm.
+- **Email** -- Click **[EDIT]** to update inline. Works the same as name.
+- **Role** -- Read-only. Displays your current role (e.g., reviewer, orgadmin).
+- **Organization** -- Read-only. Shows your active organization.
+- **Member Since** -- Read-only. The month and year your account was created.
+
+### Choosing a Ghostie Avatar
+
+Click **[CHANGE]** next to your avatar to open the ghostie picker. You can select from six expressions -- Sweet, Mild, Exasperated, WTF, Disbelieving, and Double Take -- and pick a color from six presets or use the custom color picker. A live preview updates as you make selections. Click **[SAVE]** to apply your new avatar, or **[CANCEL]** to discard changes.
+
+### Changing Your Password
+
+The **Security** section lets you change your password. If you already have a password set, enter your current password first, then your new password and confirmation. If you do not have a password set yet (e.g., you were added to the system before password setup was available), you can set one directly without entering a current password. Passwords must be at least 6 characters.
+
+### Display Settings
+
+The **Display** section lets you switch between **Light**, **Dark**, and **System** themes.

content/wiki/hub/02-navigating-the-app.md

@@ -0,0 +1,64 @@
+# Navigating the App
+
+This page explains the top navigation bar, what each section contains, and how navigation differs by role.
+
+## The Navigation Bar
+
+The top navigation bar is a black bar across the top of every page. From left to right, it contains:
+
+1. **Organization name** (or org switcher)
+2. **My Reviews** link
+3. **Cohorts** dropdown (admins only)
+4. **Manage** dropdown (admins only)
+5. **User area** (your name, avatar, theme toggle, logout)
+
+### Organization Name and Switcher
+
+The far-left of the navigation bar shows your current organization name. If you belong to multiple organizations, this becomes a dropdown. Click it to see all your organizations, with a checkmark next to the active one. Select a different organization to switch context -- the page reloads with data from the selected org.
+
+:::info
+If you only belong to one organization, the org name displays as static text with no dropdown.
+:::
+
+### My Reviews
+
+The **My Reviews** link appears for all roles. It takes you to your reviewer dashboard at `/reviews`, which shows all applications assigned to you for scoring. If you have incomplete reviews, a count appears in parentheses next to the link.
+
+This is also where you land after logging in.
+
+### Cohorts Dropdown
+
+The **Cohorts** dropdown is visible to cohort admins and org admins -- reviewers do not see it. It lists all cohorts in your current organization. Clicking a cohort name takes you to that cohort's management page, where you can access tabs for **Applications**, **Reviewers**, **Assignments**, **Decisions**, **Email Tasks**, **Form**, and more.
+
+If no cohorts exist yet, **Cohorts** appears as a plain link to the cohorts index page.
+
+### Manage Dropdown
+
+The **Manage** dropdown is visible to org admins (and above). It provides access to administrative tools:
+
+- **Team Members** -- Invite users, assign roles, manage access to specific cohorts. Found at `/manage/users`.
+- **Configure Stages** -- Set up review stages for your cohorts, including reviewer minimums/maximums and blind review settings. Found at `/admin/stages`.
+- **Activity Log** -- A feed of all actions across your organization: logins, review submissions, status changes, decisions, and more. Found at `/manage/activity`.
+
+:::tip
+Superadmins see two additional items in the **Manage** dropdown: **Users** (system-wide user management) and **Organizations** (org-level administration). These are system-level tools not covered in this guide.
+:::
+
+### User Area
+
+The right side of the navigation bar shows:
+
+- **Your name and ghostie avatar** -- Click to go to **Settings**, where you can edit your profile, change your password, and pick a new avatar.
+- **Theme toggle** -- A small button to switch between light and dark mode.
+- **[LOGOUT]** -- Signs you out and returns you to the login page.
+
+## What Each Role Sees
+
+| Navigation element | Reviewer | Cohort Admin | Org Admin |
+|---|---|---|---|
+| My Reviews | Yes | Yes | Yes |
+| Cohorts dropdown | No | Yes | Yes |
+| Manage dropdown | No | No | Yes |
+| Settings (via user area) | Yes | Yes | Yes |
+
+Cohort admins see the **Cohorts** dropdown but not the **Manage** dropdown. Org admins see both. Reviewers see only **My Reviews** and their user area.

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.
+:::

content/wiki/hub/reference/00-application-status-reference.md

@@ -0,0 +1,66 @@
+# Application Status Reference
+
+Every application moves through a defined set of statuses as it progresses from submission to final outcome. This page documents each status, what it means, and the valid transitions between them.
+
+## Status Definitions
+
+**`new`** -- Application recently submitted. This is the starting status for every application that comes in through the apply form.
+
+**`waiting_first_round`** -- Waiting to be scheduled for a first-round interview. The application has been advanced from its initial review stage into the first-round interview stage but does not yet have an interview booked.
+
+**`first_round_scheduled`** -- First-round interview has been scheduled. Set automatically when a Cal.com booking webhook matches the applicant's email, or when an admin manually changes the status.
+
+**`needs_first_decision`** -- First round complete, awaiting a decision. Set automatically when an admin locks the first-round stage (all completed reviews must be locked and the minimum reviewer threshold met).
+
+**`waiting_second_round`** -- Waiting to be scheduled for a second-round interview. The committee decided to advance the application past the first round into a second-round stage.
+
+**`second_round_scheduled`** -- Second-round interview has been scheduled. Same mechanism as first round -- triggered by a Cal.com webhook match or manual status change.
+
+**`needs_final_decision`** -- Second round complete, awaiting final decision. Set automatically when the final stage is locked.
+
+**`accepted`** -- Application accepted into the cohort. Terminal status.
+
+**`waitlist`** -- Application waitlisted. Can still transition to `accepted` or `declined`.
+
+**`declined`** -- Application declined. Terminal status.
+
+## Valid Transitions
+
+Each status can only move to specific next statuses. The system enforces these rules and rejects invalid transitions.
+
+- `new` → `waiting_first_round`, `first_round_scheduled`, `declined`
+- `waiting_first_round` → `first_round_scheduled`, `waiting_second_round`, `declined`
+- `first_round_scheduled` → `needs_first_decision`, `waiting_first_round`, `declined`
+- `needs_first_decision` → `waiting_second_round`, `accepted`, `waitlist`, `declined`
+- `waiting_second_round` → `second_round_scheduled`, `accepted`, `waitlist`, `declined`
+- `second_round_scheduled` → `needs_final_decision`, `waiting_second_round`, `declined`
+- `needs_final_decision` → `accepted`, `waitlist`, `declined`
+- `accepted` → (none -- terminal)
+- `waitlist` → `accepted`, `declined`
+- `declined` → (none -- terminal)
+
+## What Triggers Transitions
+
+**Automatic transitions:**
+
+- **Stage locking** sets `needs_first_decision` or `needs_final_decision` depending on whether the locked stage is the final stage or a first-round stage.
+- **Advancing to next stage** sets `waiting_first_round` or `waiting_second_round` based on the next stage's type. If an interview is already scheduled for that round, the status skips directly to `first_round_scheduled` or `second_round_scheduled`.
+- **Cal.com webhooks** move an application from `waiting_first_round` to `first_round_scheduled` (or the second-round equivalent) when a booking is created.
+
+**Manual transitions:**
+
+- Admins can change any application's status through the **Applications** tab, provided the transition is valid.
+- Bulk status changes are available for processing multiple applications at once.
+- The **Decisions** tab records accept, waitlist, or decline decisions and updates the status accordingly.
+
+:::info
+An application can be declined from almost any active status. The `waitlist` status is the only non-terminal outcome status -- waitlisted applications can still be accepted or declined later.
+:::
+
+## Status Groups
+
+The system groups statuses for filtering:
+
+- **Active:** `new`, `waiting_first_round`, `first_round_scheduled`, `needs_first_decision`, `waiting_second_round`, `second_round_scheduled`, `needs_final_decision`
+- **Decision pending:** `needs_first_decision`, `needs_final_decision`
+- **Terminal:** `accepted`, `waitlist`, `declined`

content/wiki/hub/reference/01-rubric-and-scoring-details.md

@@ -0,0 +1,74 @@
+# Rubric & Scoring Details
+
+This page covers how scoring works end to end in Cohort-OS -- from how rubrics are structured, through per-criterion scoring by individual reviewers, to how consensus scores are calculated across the review panel.
+
+## Rubric Structure
+
+Rubrics are defined in Flywheel (the external assessment engine) and linked to each review stage. A rubric contains:
+
+- **Criteria** -- The individual dimensions being evaluated (e.g., "Mission Alignment", "Governance Readiness"). Each criterion has a name, description, and maximum point value.
+- **Thresholds** (or levels) -- Descriptive scoring bands within each criterion. Each threshold has a title, a description of what that performance level looks like, and a point range. Reviewers select the threshold that best matches the applicant.
+- **Max points** -- Each criterion defines its own maximum score (commonly 5 points). The rubric's total possible score is the sum of all criteria max points.
+
+Each review stage in a cohort is linked to a specific Flywheel rubric via the stage's configuration. Different stages can use different rubrics.
+
+## How Reviewers Score
+
+Reviewers use the **guided scoring interface** to evaluate applications criterion by criterion. For each criterion:
+
+1. Read the criterion description and the applicant's relevant answers (shown side by side).
+2. Select a threshold/level that matches the applicant's response. Selecting a threshold automatically assigns the corresponding point value.
+3. Optionally add notes specific to that criterion.
+4. All criteria must be scored before proceeding to the recommendation step.
+
+After scoring all criteria, the reviewer sees their total score (sum of all criterion scores) and percentage (total divided by maximum possible), then selects a recommendation and writes overall notes.
+
+:::info
+If a rubric does not have thresholds configured in Flywheel, reviewers see simple numeric score buttons (1 through the max points) instead of descriptive threshold options.
+:::
+
+## Individual Review Scores
+
+Each completed review stores:
+
+- **Per-criterion scores** -- The point value and max value for each criterion, plus optional notes.
+- **Total score** -- Sum of all criterion scores.
+- **Percentage** -- Total score divided by total max points, expressed as a percentage.
+- **Recommendation** -- One of `advance`, `reject`, `hold`, or `undecided`.
+- **Overall notes** -- Free-text assessment from the reviewer.
+
+A review starts as `draft` (editable, can be saved and returned to) and becomes `completed` when submitted. Submitting locks the scores and notes. The recommendation can still be changed after submission with a recorded reason.
+
+## Consensus Calculation
+
+When multiple reviewers have completed their reviews for the same application and stage, the consensus view aggregates their scores. The consensus endpoint calculates:
+
+- **Average score** -- Mean of all reviewers' total scores.
+- **Average percentage** -- Mean of all reviewers' percentage scores.
+- **Per-criterion averages** -- For each criterion, the mean score across all reviewers.
+- **Score spread** -- The difference between the highest and lowest score for each criterion. A criterion is **flagged** when the spread is 2 or more points, or 40% or more of the max points. Flagged criteria indicate significant disagreement between reviewers.
+- **Recommendation tally** -- Count of advance, hold, reject, and undecided recommendations.
+
+:::warning
+Only completed reviews with `review` permission are included in consensus calculations. View-only assignments and draft reviews are excluded.
+:::
+
+## Grade Bands
+
+Cohorts can define grade bands that map percentage ranges to letter grades:
+
+| Band | Range | Label |
+|------|-------|-------|
+| A | 90-100% | Exceptional |
+| B | 80-89% | Strong |
+| C | 70-79% | Good |
+| D | 60-69% | Acceptable |
+| F | 0-59% | Needs Work |
+
+Grade bands are configured per cohort in the Flywheel integration settings. They provide a quick way to categorize application strength during committee discussions.
+
+## Blind Review
+
+When **blind review** is enabled on a stage (the default), reviewer identities are hidden from other reviewers viewing the consensus. Reviewers appear as "Reviewer 1", "Reviewer 2", etc. Admins always see full reviewer names and emails regardless of the blind review setting.
+
+Blind review affects the consensus view only -- it does not change what reviewers see while scoring. Each reviewer always scores independently without seeing other reviewers' scores until their own review is submitted.

content/wiki/hub/reference/02-glossary.md

@@ -0,0 +1,43 @@
+# Glossary
+
+Key terms used throughout Cohort-OS and this documentation.
+
+---
+
+**Blind review** -- A stage setting that hides reviewer identities from other reviewers when viewing consensus scores. Reviewers appear as "Reviewer 1", "Reviewer 2", etc. Admins always see full names regardless of this setting. Enabled by default on all stages.
+
+**Cohort** -- A group of applicants going through a selection process together. Each cohort has its own application form, review stages, reviewers, and decisions. Cohorts move through lifecycle statuses: `draft`, `review`, `decide`, `onboard`, `active`, `closed`.
+
+**Cohort admin** -- A user with the `cohortadmin` role. Can manage applications, assign reviewers, configure stages, make decisions, and send notifications for cohorts they have access to. Cannot manage organization-level settings or users.
+
+**Consensus** -- The aggregated view of all completed reviews for a single application within a stage. Shows average scores per criterion, overall averages, score spread, and a tally of reviewer recommendations. Used by admins and committees to inform decisions.
+
+**Criterion** -- A single dimension of evaluation within a rubric (e.g., "Mission Alignment", "Governance Readiness"). Each criterion has a name, description, maximum point value, and optional scoring thresholds that describe what each performance level looks like.
+
+**Decision** -- The final outcome recorded for an application: `accepted`, `waitlist`, or `declined`. Decisions include a rationale, rationale code, and optional committee notes. Recorded in the **Decisions** tab.
+
+**Flywheel** -- The external assessment engine that Cohort-OS integrates with. Flywheel provides rubrics (scoring criteria and thresholds), surveys (application form question sets), and reporting capabilities. Rubrics are authored in Flywheel and linked to review stages in Cohort-OS.
+
+**Ghostie** -- The avatar system in Cohort-OS. Each user chooses a ghostie -- a small ghost illustration defined by an expression (sweet, mild, exasperated, wtf, disbelieving, double-take) and a body color (from presets or a custom color picker). Ghosties appear on user profile circles throughout the app.
+
+**Guided scoring** -- The primary review interface where reviewers score applications criterion by criterion. In focused mode, one criterion is shown at a time with the applicant's answers alongside. In "show all" mode, every criterion is visible at once. After scoring all criteria, reviewers proceed to the recommendation step.
+
+**Org** -- Short for organization. The top-level entity that owns cohorts, users, and settings. Users can belong to multiple orgs via org memberships. All data is scoped to an org.
+
+**Orgadmin** -- A user with the `orgadmin` role for an organization. Full management access: can manage users, cohorts, settings, and view the activity feed. Can do everything a cohort admin can, plus organization-level administration.
+
+**Orphaned interview** -- A Cal.com booking that could not be automatically matched to an application. This happens when the email on the booking does not match any applicant's contact email in the cohort. Orphaned interviews appear in a modal accessible from the **Applications** tab, where an admin can manually match them to the correct application or dismiss them.
+
+**Permission (view/review)** -- The access level assigned to a reviewer for a specific application. `review` permission allows the reviewer to score the application and submit a review. `view` permission gives read-only access to the application data without the ability to score. View-only reviews are excluded from consensus calculations.
+
+**Rationale code** -- A short code attached to a decision that categorizes the reasoning (e.g., `manual_accept`). Used alongside the free-text rationale to provide structured data about why a decision was made.
+
+**Recommendation** -- A reviewer's suggested outcome for an application, selected after scoring. Four options: **advance** (move to the next stage), **reject** (decline the application), **hold** (flag for further committee discussion), **undecided** (no recommendation yet). Recommendations inform but do not determine the final decision. Reviewers can change their recommendation after submission by providing a reason.
+
+**Reviewer** -- A user assigned to evaluate applications. Reviewers are first added to a cohort's reviewer pool, then assigned to specific applications with either `view` or `review` permission. Reviewers access their assignments through the review dashboard and score applications using the guided scoring interface.
+
+**Rubric** -- A structured scoring framework defined in Flywheel and linked to a review stage. Contains multiple criteria, each with descriptive thresholds/levels. Rubrics standardize evaluation so all reviewers assess applications against the same dimensions.
+
+**Self-assessment** -- A survey sent to members of an applicant's team (e.g., studio members). Each team member receives a unique token-based link that does not require login. Admins can track completion status, resend emails, and view responses. Self-assessment data is available to second-round reviewers during scoring.
+
+**Stage** -- A phase within a cohort's review process. Common stage types are `application-reviews` (initial paper review), `first-round` (first interview round), and `second-round` (second interview round). Each stage has its own rubric, reviewer settings (minimum/maximum reviewers, blind review, self-review), and status. Stages are ordered sequentially and applications advance through them.

content/wiki/hub/reviewer/00-your-dashboard.md

@@ -0,0 +1,57 @@
+# Your Dashboard
+
+The **My Reviews** dashboard is your home base. It shows every application assigned to you, organized by urgency so the most important items surface first.
+
+## Getting There
+
+Click **My Reviews** in the top navigation bar. This takes you to `/reviews`. A badge on the nav link shows how many assignments need your attention.
+
+## Card Grid Layout
+
+Active assignments appear as a card grid -- one, two, or three columns depending on your screen width. If you have assignments across multiple cohorts, cards are grouped under cohort headers. When you only have one cohort, the header is suppressed.
+
+Each card shows:
+
+- **Studio name** -- the applicant's studio or team name
+- **Progress bar** -- small block indicators showing how far through the review stages this application has progressed
+- **Stage name** -- which stage this assignment belongs to (e.g., "1st Interview", "2nd Interview"), plus the interview date if applicable
+- **Status text** -- contextual information like "In progress" for drafts, "View only" for read-only assignments, or pipeline status
+- **Action button** -- the primary action available to you
+
+## How Cards Are Sorted
+
+Cards are sorted by urgency, not alphabetically. The order is:
+
+1. **Overdue** -- interview stages past their due date (shown in red)
+2. **In progress** -- reviews you have started but not submitted (drafts)
+3. **Ready to score** -- non-interview stages waiting for your input
+4. **Post-interview ready** -- interview stages where the interview has already occurred
+5. **Scheduled** -- upcoming interviews (future date)
+6. **Awaiting scheduling** -- interview stages with no date set yet
+7. **View only** -- assignments where you have read-only access
+8. **Pipeline** -- applications not yet at this stage (shown dimmed)
+
+## Action Buttons
+
+The button on each card reflects the most relevant action:
+
+- **Score Now** -- the application is ready for you to score
+- **Continue** -- you have a draft in progress
+- **Prepare** -- an interview stage where you can review materials before the interview
+- **View** -- view-only access to the application
+
+Clicking the card or its action button opens the guided scoring interface.
+
+## Search
+
+When you have 10 or more active assignments, a search field appears at the top. Type a studio name to filter the visible cards.
+
+## Completed Reviews
+
+Below the active grid, a **completed** section lists reviews you have already submitted. Click the toggle to expand or collapse it. If you have no active assignments, completed reviews display automatically.
+
+Each completed row shows the studio name, stage, your score percentage, and the date you submitted. Click **View** to revisit a completed review in read-only mode.
+
+:::info
+The count shown next to "My Reviews" in the navigation bar reflects actionable assignments only -- it excludes view-only and pipeline items.
+:::

content/wiki/hub/reviewer/01-scoring-an-application.md

@@ -0,0 +1,60 @@
+# Scoring an Application
+
+The guided scoring interface walks you through each rubric criterion one at a time, then asks for your overall recommendation. This is where you do the actual work of evaluating an application.
+
+## Opening the Scoring Interface
+
+Click any active card on your **My Reviews** dashboard (or its **Score Now** / **Continue** button). This opens the guided scoring page at `/review/[cohortSlug]/guided`.
+
+The page has a two-column layout:
+
+- **Left column** -- background information about the application
+- **Right column** -- the scoring form
+
+## Left Column: Background Tabs
+
+The left column has several tabs depending on the stage:
+
+- **Application** -- the applicant's submitted answers, attachments, and links. Eligibility questions are filtered out. File attachments can be downloaded; URLs open in a new tab.
+- **Reviews** -- completed reviews from earlier stages (hidden on the first stage). If blind review is enabled, reviewer identities are hidden.
+- **Assessments** -- self-assessment results from team members (second-round stages only).
+- **Script** -- interview questions configured for this stage, rendered from markdown. Use this to guide your interview conversation.
+- **Notes** -- a private text area for your own interview notes. These auto-save and are tied to the specific stage. Only you can see them.
+
+## Right Column: Scoring
+
+By default, you score one criterion at a time in **focused mode**. A **Show all** toggle in the upper right switches to a view where every criterion is visible at once.
+
+In focused mode, each criterion shows:
+
+1. **Criterion number and name** (e.g., "Criterion 1/5 -- Mission Alignment")
+2. **Description** of what to evaluate
+3. **Score options** -- either threshold cards with descriptions (click to select), named levels, or numeric buttons depending on how the rubric is configured
+4. **Notes field** -- optional per-criterion notes
+
+Use the **Next Criterion** and **Previous** buttons to navigate. You can also use the **Jump to...** dropdown to skip to any criterion. A criterion must be scored before you can advance to the next one.
+
+### Keyboard Shortcuts
+
+In focused mode, you can score without touching your mouse:
+
+- **Up/Down arrows** -- navigate between threshold or level options
+- **Enter** -- select the focused option and advance to the next criterion
+- **Left/Right arrows** -- move to the previous or next criterion
+- **Number keys (1-9)** -- set a numeric score directly (when simple score buttons are shown)
+
+## Saving and Submitting
+
+Your work auto-saves every 1.5 seconds after you make a change. A "Saving..." / "Saved" indicator appears near the top right. You can also click **Save Draft** manually at any time.
+
+Once all criteria are scored, click **Proceed to Recommendation** to move to the final screen. This shows your score summary, lets you select a recommendation, and provides space for overall notes.
+
+Click **Submit Review** when you are ready. A confirmation dialog explains that submission locks your scores and notes. After confirming with **Submit & Lock**, your review is complete and you are redirected to the dashboard.
+
+:::warning
+After submission, your scores and notes are locked. You can still change your recommendation if the review is for the application's current stage, but scores cannot be edited.
+:::
+
+:::tip
+For interview stages, the **Submit Review** button is disabled until after the interview has occurred. You can still prepare by reviewing the application and scoring criteria beforehand.
+:::

content/wiki/hub/reviewer/02-understanding-rubrics.md

@@ -0,0 +1,52 @@
+# Understanding Rubrics
+
+Rubrics define the criteria you score applications against. They are created and managed in Flywheel, the external assessment engine, and loaded automatically when you open the scoring interface.
+
+## What a Rubric Contains
+
+Each rubric has a title and a list of **criteria**. A criterion is a single dimension you evaluate -- for example, "Mission Alignment" or "Team Dynamics." Every criterion includes:
+
+- **Name and title** -- what the criterion is called
+- **Description** -- what you should be evaluating
+- **Maximum points** -- the highest score possible for this criterion
+- **Weight** -- how heavily this criterion counts in the overall score (used in consensus calculations)
+
+## Score Levels and Thresholds
+
+Depending on how the rubric is configured in Flywheel, scoring guidance appears in one of three formats:
+
+### Thresholds
+
+Each criterion has named scoring bands with a title, description, and score range. For example:
+
+- **Exceptional** (4-5): "Strong and nuanced understanding of their specific challenges..."
+- **Competent** (2-3): "Basic recognition of some of their main challenges..."
+- **Developing** (1): "Unaware of or defensive about their challenges..."
+
+When you click a threshold, the score is set to the midpoint of that range.
+
+### Named Levels
+
+Each level has a fixed score value, a name, and a description. You click the level that best matches the applicant. The score is assigned directly from the level definition.
+
+### Numeric Scores
+
+When no thresholds or levels are configured, you see simple numbered buttons from 1 to the maximum. You select the number that best reflects your assessment.
+
+## How Criteria Map to Application Questions
+
+Each review stage has a rubric assigned through its Flywheel configuration. The scoring profile for a cohort defines a **map** that connects rubric criterion keys to application question keys. For example, a criterion called `gov_readiness` might map to the question `Q.GOV_PLAN`, meaning the applicant's answer to that question is what you should consider when scoring that criterion.
+
+In practice, you see this mapping reflected in the scoring interface: the left column shows the applicant's answers, and the right column shows the corresponding criterion to score. The interface is designed so you can read the relevant answer and score it in the same view.
+
+## Per-Stage Rubrics
+
+Different review stages can use different rubrics. An application review stage might focus on written application quality, while an interview stage might use criteria like "Openness to Feedback" or "Cohort Fit." The rubric is loaded automatically based on the stage configuration -- you do not need to select one.
+
+:::info
+Rubrics are managed by administrators in Flywheel. If a rubric is missing or misconfigured, you will see a "Rubric Not Available" message when you try to open the scoring interface. Contact your cohort administrator if this happens.
+:::
+
+## Score Calculation
+
+Your total score is the sum of all individual criterion scores. The percentage is calculated as total score divided by the maximum possible total. This score, along with your recommendation, feeds into the consensus view that administrators use when making decisions.

content/wiki/hub/reviewer/03-recommendations.md

@@ -0,0 +1,49 @@
+# Recommendations
+
+After scoring all criteria for an application, you select a recommendation. This is your overall judgment on what should happen next with the applicant.
+
+## The Four Options
+
+You choose one recommendation from a dropdown on the **Final Recommendation** screen:
+
+- **Advance to Next Stage** -- you believe this applicant should move forward in the process. Use this when the application or interview performance meets or exceeds the bar for the current stage.
+
+- **Hold for Further Review** -- you are not ready to recommend advancing or declining. Use this when you see potential but have concerns that need committee discussion, or when the applicant falls in a borderline zone where additional input from other reviewers would help.
+
+- **Decline Application** -- you believe this applicant should not continue. Use this when the application clearly does not meet the criteria for the cohort, or when significant concerns emerged during the review.
+
+- **Undecided** -- you have not formed a recommendation yet. This is the default state. You must change it to one of the other three options before you can submit your review.
+
+:::warning
+You cannot submit your review while the recommendation is set to **Undecided**. All criteria must be scored and a recommendation selected before the **Submit Review** button becomes active.
+:::
+
+## The Recommendation Screen
+
+When you click **Proceed to Recommendation** after scoring, you see:
+
+- **Your total score** and percentage in the top right
+- **Recommendation dropdown** -- select your choice here
+- **Score summary** -- a breakdown of each criterion with your score
+- **Overall notes** -- a free-text area for your overall assessment of the applicant
+
+The score summary is read-only at this point (go back to scoring to change individual scores). The recommendation and overall notes can be edited freely before submission.
+
+## Changing Your Recommendation After Submission
+
+Once you submit, your scores and notes are locked. However, if the review is for the application's current stage, you can still change your recommendation. On the read-only review screen, click the **Change** button next to your current recommendation. A modal asks you to:
+
+1. Select a new recommendation
+2. Provide a reason for the change
+
+The change is recorded with a timestamp and your reason. A full history of recommendation changes is visible below the current recommendation.
+
+:::info
+Recommendation changes are only available while the application is still at the stage you reviewed. Once the application advances to a later stage, your earlier recommendation becomes fully locked.
+:::
+
+## How Recommendations Factor Into Decisions
+
+Your recommendation is one input among potentially several reviewers. Cohort administrators see all reviewer recommendations alongside consensus scores when making decisions on the **Decisions** tab. A pattern of "advance" recommendations supports moving an applicant forward, while mixed recommendations (some "advance," some "hold") typically trigger committee discussion.
+
+The final decision -- accept, waitlist, or decline -- is made by the cohort admin, not determined automatically by reviewer recommendations.

content/wiki/hub/reviewer/04-interviews.md

@@ -0,0 +1,56 @@
+# Interviews
+
+Interview stages follow the same scoring workflow as application review stages, with additional features for preparing, taking notes, and working with scheduled interview times.
+
+## The Dashboard for Interview Stages
+
+Your **My Reviews** dashboard at `/reviews` handles both application reviews and interview assignments in a single view. Interview stage cards show additional information:
+
+- **Stage label** -- displayed as "1st Interview" or "2nd Interview" instead of the raw stage name
+- **Interview date** -- shown next to the stage name if an interview has been scheduled
+- **"Unscheduled"** -- shown if the interview has not been booked yet
+- **Due date** -- if a due date is set, it appears on cards where the interview has already occurred. Overdue items show the date in red with an "OVERDUE" label.
+
+Interview cards sort by urgency alongside non-interview cards. Overdue interview reviews appear at the very top. Unscheduled interviews appear lower since there is nothing to act on yet.
+
+## Preparing for an Interview
+
+Before the interview takes place, you can open the scoring interface to prepare. Click **Prepare** on the card. Inside, you have access to:
+
+- **Application tab** -- review the applicant's full submission
+- **Reviews tab** -- read completed reviews from earlier stages to understand how the applicant has been evaluated so far
+- **Script tab** -- view the interview questions configured for this stage (rendered from markdown). Use these to guide your conversation.
+- **Notes tab** -- start writing private notes before, during, or after the interview
+
+You can score criteria and save drafts during preparation, but you cannot submit the review until after the scheduled interview time has passed.
+
+:::tip
+Open the scoring interface on a second screen during the interview itself. The **Script** tab gives you your question guide, and the **Notes** tab lets you capture observations in real time.
+:::
+
+## Taking Interview Notes
+
+The **Notes** tab provides a private text area tied to the specific stage. Your notes auto-save as you type (with a short delay). Only you can see these notes -- they are not visible to other reviewers or the applicant.
+
+Notes are stored separately from the review itself. Even if you have not started scoring, you can use the notes tab to capture thoughts during or after the interview.
+
+## Scoring After the Interview
+
+Once the interview time has passed, the scoring workflow is identical to a regular application review. Score each criterion, select your recommendation, write your overall notes, and submit.
+
+For second-round interview stages, an additional **Assessments** tab appears in the left column, showing self-assessment results from the applicant's team members. This gives you context on how the team views its own strengths and challenges.
+
+## What Happens After You Submit
+
+After submission:
+
+1. Your review is locked (scores and notes become read-only)
+2. You are redirected back to the dashboard
+3. The assignment moves to the **completed** section
+4. Your recommendation can still be changed if the application remains at this stage
+
+The cohort administrator is notified when enough reviewers have completed their reviews for a stage. They will then review the consensus scores and make a decision on each application.
+
+:::info
+Interviews are scheduled through Cal.com by the cohort administrator. You do not book interviews yourself. If your dashboard shows "Unscheduled" for an interview assignment, the booking has not been created yet -- no action is needed from you.
+:::