letsbe
/
MOPC-App
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
MOPC-App/docs/codex-architecture-redesign.../10-monaco-reference-configu...

4.7 KiB
Raw Permalink Blame History

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
  1. eligibility_filter
  • type: FILTER
  • trigger: admin or auto-on-close
  1. jury1_evaluation
  • type: EVALUATION
  • open: 2026-06-05
  • close: 2026-06-25
  • jury binding: MAIN_SEMIFINAL
  1. submission_r2_intake
  • type: INTAKE
  • open: 2026-06-28
  • close: 2026-07-20
  1. jury2_evaluation
  • type: EVALUATION
  • open: 2026-07-24
  • close: 2026-08-10
  • jury binding: MAIN_FINALIST
  1. jury3_live_finals
  • type: LIVE_FINAL
  • event date window: 2026-09-01
  • jury binding: MAIN_LIVE_FINALS
  1. 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
  1. 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