163 lines
4.7 KiB
Markdown
163 lines
4.7 KiB
Markdown
# 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
|