8.2 KiB

Raw Blame History

Special Awards

Overview

Special awards run alongside the main competition flow, typically activating during or after the Jury 2 evaluation round (R5). Each award has its own jury, document requirements, review window, and selection process. Awards do NOT use the deliberation model — they are decided by their own jury/judge mechanism.

Award Routing Modes

Every special award operates in one of two configurable modes:

Mode A: SEPARATE_POOL (Pull-Out)

Projects are filtered into a dedicated award pool. The award may:

Pull projects out of the main competition pool, OR
Keep projects in both the main pool and the award pool

Pull-out requires admin confirmation (routingConfirmationMode: ADMIN_CONFIRMED). The admin reviews which projects are pulled out and approves before the pull-out takes effect.

Main Pool ──┬──→ continues in main competition
             └──→ [admin confirms] ──→ Award Pool ──→ Award Review ──→ Award Winner

Mode B: STAY_IN_MAIN (Dual Track)

Projects remain in the main competition but are flagged as "eligible for award." The award evaluation runs in parallel with the main flow.

Main Pool ──→ continues in main competition
     │
     └──→ flagged "eligible" ──→ Award Review ──→ Award Winner

Award Mini-Pipeline

Each special award has its own mini-pipeline:

Filtering → AI screens eligible projects based on award criteria
Review → Award jury evaluates eligible projects
Selection → Winner(s) selected by jury vote or single-judge decision

This mini-pipeline is independent of the main competition rounds. It has its own:

Jury (or reuses judges from main juries, with overlap allowed)
Document requirements (if the award needs specific docs beyond main submissions)
Review window (own start/end dates)
Selection process (jury vote or single-judge)

Data Model

SpecialAward

model SpecialAward {
  id            String   @id @default(cuid())
  competitionId String
  name          String
  description   String?

  // Routing
  routingMode            AwardRoutingMode  // STAY_IN_MAIN | SEPARATE_POOL
  pullOutBehavior        PullOutBehavior?  // REMOVE_FROM_MAIN | KEEP_IN_BOTH (only for SEPARATE_POOL)
  routingConfirmationMode RoutingConfirmation @default(ADMIN_CONFIRMED)

  // Eligibility
  eligibilityMode  AwardEligibilityMode // AI_SUGGESTED | MANUAL | ALL_ELIGIBLE | ROUND_BASED
  eligibilityCriteria Json?  // AI screening criteria (if AI_SUGGESTED)
  eligibilityRoundId  String? // filter from this round's output (if ROUND_BASED)

  // Jury
  juryGroupId    String?  // dedicated jury group (null = single judge)

  // Single judge mode
  winnerDecisionMode  WinnerDecisionMode @default(JURY_VOTE)
  singleJudgeUserId   String?  // only if winnerDecisionMode = SINGLE_JUDGE

  // Doc requirements
  requiresAdditionalDocs Boolean @default(false)
  docRequirements        Json?   // additional file slot definitions

  // Review window
  reviewWindowStart DateTime?
  reviewWindowEnd   DateTime?

  // Audience voting
  audienceVotingEnabled Boolean @default(false)

  sortOrder  Int @default(0)
  createdAt  DateTime @default(now())
  updatedAt  DateTime @updatedAt

  competition Competition @relation(...)
  juryGroup   JuryGroup?  @relation(...)
  winners     AwardWinner[]

  @@index([competitionId])
}

AwardWinner

model AwardWinner {
  id            String   @id @default(cuid())
  awardId       String
  projectId     String
  rank          Int      @default(1)  // 1 = winner, 2+ = runner-up
  decidedById   String   // judge or admin who confirmed
  decisionMode  WinnerDecisionMode
  reason        String?
  createdAt     DateTime @default(now())

  award   SpecialAward @relation(...)
  project Project @relation(...)

  @@unique([awardId, projectId])
}

Supporting Enums

enum AwardRoutingMode {
  STAY_IN_MAIN    // Mode B: projects stay in main pool
  SEPARATE_POOL   // Mode A: projects enter dedicated pool
}

enum PullOutBehavior {
  REMOVE_FROM_MAIN  // pulled out of main competition
  KEEP_IN_BOTH      // in both main and award pools
}

enum RoutingConfirmation {
  ADMIN_CONFIRMED   // admin must approve pull-out
  AUTOMATIC         // pull-out happens automatically on eligibility
}

enum AwardEligibilityMode {
  AI_SUGGESTED   // AI screens projects against criteria
  MANUAL         // admin manually selects eligible projects
  ALL_ELIGIBLE   // all projects in the competition are eligible
  ROUND_BASED    // projects that passed a specific round are eligible
}

enum WinnerDecisionMode {
  JURY_VOTE     // jury evaluates and votes
  SINGLE_JUDGE  // one designated judge decides
}

Eligibility & Filtering

Award eligibility is determined by the eligibilityMode:

Mode	How Projects Become Eligible
`AI_SUGGESTED`	AI screens all projects against the award's `eligibilityCriteria`. Uses the existing AI screening system.
`MANUAL`	Admin manually flags projects as eligible for this award.
`ALL_ELIGIBLE`	Every project in the competition is automatically eligible.
`ROUND_BASED`	Projects that passed a specific round (e.g., filtering, Jury 1) are eligible.

For AI_SUGGESTED, the filtering uses the same AI screening infrastructure as the main R2 filtering round, just with award-specific criteria.

Per-Award Jury

Each award can have its own JuryGroup:

Members can overlap with main juries (same judge on Jury 2 and Innovation Award jury)
Independent cap and assignment configuration
Own scoring rubric if needed

For simpler awards, SINGLE_JUDGE mode allows one designated judge to make the decision directly.

Per-Award Document Requirements

If requiresAdditionalDocs is true, the award defines additional file slots that eligible projects must submit:

type AwardDocRequirement = {
  slotKey: string        // e.g., "innovation_statement"
  label: string          // "Innovation Impact Statement"
  required: boolean
  maxFileSize: number    // bytes
  acceptedTypes: string[] // ["application/pdf", "video/mp4"]
}

These are separate from the main submission windows. Award docs are uploaded through the applicant's award-specific section.

Award Review Window

Each award has its own review window (start/end dates) that is independent of the main competition schedule. The review window:

Can overlap with Jury 2 evaluation or run after it
Shows countdown on the award jury's dashboard
Triggers email reminders as the deadline approaches

No Deliberation for Awards

Special awards are decided by their own jury/judge mechanism:

JURY_VOTE: Award jury members evaluate and vote. Simple majority or highest score wins.
SINGLE_JUDGE: Designated judge reviews and selects the winner(s).

There is no DeliberationSession for awards. The award winner is confirmed by the deciding jury/judge and recorded as an AwardWinner.

Audience Voting for Awards

If audienceVotingEnabled is true on an award:

Audience can vote for their preferred project within the award pool
Audience vote can influence the award decision (configurable weight)
Audience vote results are visible to the award jury during their review

Admin Controls

Create/edit awards: name, mode, eligibility, jury, doc requirements, review window
Confirm pull-out: for SEPARATE_POOL mode, admin reviews and approves which projects are pulled
Override eligibility: admin can add/remove projects from award eligibility at any time
Override winner: admin can override the jury/judge decision with audit trail
View award status: see all awards, their eligible projects, jury progress, and winners

All admin actions on awards are logged to DecisionAuditLog.

Integration Points

R5 (Jury 2): Awards typically activate during or after Jury 2. Award filtering runs alongside Jury 2 evaluation.
Live Finals (R7): Award winners may be announced during the live finals ceremony.
Reports: Award selections, jury decisions, and audit trails are included in competition reports.

See 03-competition-flow.md for how awards fit into the overall competition flow.

8.2 KiB Raw Blame History