# 10. Monaco Reference Configuration (Example)

This is an example of how a Monaco 2026 competition would be configured in the redesigned system.

## 1) Program Profile
- Program: Monaco Ocean Protection Challenge 2026
- Categories: `STARTUP`, `BUSINESS_CONCEPT`
- Main pipeline: `mopc-2026-main`
- Award tracks: configurable per award

## 2) Stage Purpose Layout (Main Track)

1. `submission_r1_intake`
- type: `INTAKE`
- open: 2026-02-01
- close: 2026-05-31
- late policy: `flag`

2. `eligibility_filter`
- type: `FILTER`
- trigger: admin or auto-on-close

3. `jury1_evaluation`
- type: `EVALUATION`
- open: 2026-06-05
- close: 2026-06-25
- jury binding: `MAIN_SEMIFINAL`

4. `submission_r2_intake`
- type: `INTAKE`
- open: 2026-06-28
- close: 2026-07-20

5. `jury2_evaluation`
- type: `EVALUATION`
- open: 2026-07-24
- close: 2026-08-10
- jury binding: `MAIN_FINALIST`

6. `jury3_live_finals`
- type: `LIVE_FINAL`
- event date window: 2026-09-01
- jury binding: `MAIN_LIVE_FINALS`

7. `final_confirmation`
- type: `SELECTION`
- rule: unanimous active quorum + one admin approval
- absent juror handling: replace juror or mark as excused (admin-audited)
- admin override: enabled for both category and award scopes (mandatory reason/audit)
- unlock policy: super-admin only

8. `results_publication`
- type: `RESULTS`
- publication mode: manual

## 3) Jury Definitions

- `MAIN_SEMIFINAL` (display label example: `Jury 1 - Technical Panel`)
  - Purpose: semi-final selection
  - members: list of judges
- `MAIN_FINALIST` (display label example: `Jury 2 - Selection Panel`)
  - Purpose: finalist selection
  - members: list of judges (overlap allowed)
- `MAIN_LIVE_FINALS` (display label example: `Jury 3 - Live Finals Panel`)
  - Purpose: live final voting + deliberation
  - members: list of judges (overlap allowed)

## 4) Assignment Policy Example

### Jury1 policy
- required reviews: 3
- default cap mode: `SOFT`
- default cap: 25
- buffer: 10
- startup/concept bias target per judge: 50/50 (suggestive, not deterministic)

### Per-judge override example
- judge A: hard cap 18
- judge B: soft cap 22 buffer 8
- judge C: startup-biased preference (100/0 suggestion, not hard rule)

## 5) Submission Round Requirements

### Round 1 (`submission_r1_intake`)
Slots:
- `r1_exec_summary` (required)
- `r1_pitch_deck` (required)
- `r1_video_pitch` (optional)

### Round 2 (`submission_r2_intake`)
Slots:
- `r2_business_plan` (required)
- `r2_financials` (required)
- `r2_impact_metrics` (optional)

Behavior:
- applicants edit current round only
- previous round read-only
- admin can replace with provenance

## 6) Award Mode Examples

### Example A: Separate Pool, Pull-Out
- award: “Blue Innovation Prize”
- participationMode: `SEPARATE_POOL`
- routingBehavior: `PULL_FROM_MAIN`
- pull-out confirmation: admin-confirmed before removal from main pool

### Example B: Dual Track
- award: “Community Impact Award”
- participationMode: `DUAL_TRACK`
- routingBehavior: `KEEP_IN_MAIN`

### Example C: Single-Judge Award
- award: “Chair’s Special Recognition”
- winnerDecisionMode: `SINGLE_JUDGE_DECIDES`
- singleJudgeUserId: configured award judge
- candidate set: only projects remaining eligible after award filtering

## 7) Mentoring Layer Example

Eligibility:
- finalist projects with `wantsMentorship=true`

Permissions:
- mentor and team can upload/comment private files
- team lead + admin can promote file to official submission

Promotion artifact:
- records source file, target slot, actor, timestamp, resulting official file id

## 8) Live Finals Example

- voting mode: criteria
- audience voting: enabled for end-of-category only
- audience totals visible to Jury3 during deliberation: true
- tie-break order:
  1. highest Jury3 weighted score
  2. admin-declared tie-break (if still tied)

## 9) Final Confirmation Example

- decision rule: unanimous (categories + jury-based awards)
- active quorum must submit confirmation vote (absent juror can be replaced or marked excused)
- admin approval required after quorum unanimity
- admin override allowed for category or award outcomes with mandatory reason code and audit snapshot
- result lock snapshot generated immediately on finalize
- unlock available only to super admins with mandatory reason + unlock event audit

## 10) Invite Flow Example

### Admin invite (jury)
- create user with role `JURY_MEMBER`
- attach `JuryMembership: MAIN_FINALIST` (custom display label in UI)
- create optional `AssignmentIntent` for stage `jury2_evaluation` and/or direct policy-validated assignments
- send invitation
- on accept: jury onboarding -> cap/bias preference override if allowed (disclosure shown that bias is suggestive only)

### Team invite
- create/attach `TeamMember`
- send invitation
- on accept: applicant context landing