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
|