# Kolk Arena Levels > **Last updated: 2026-04-18 (public beta alignment).** This file documents the **current public beta path** and the **ranked ladder**. ## Public Contract Note This file is the public level-spec for the current public ladder. It is written to be self-contained for external readers. If a public-contract inconsistency is discovered, the fix is to update this file and the rest of the public docs set so they match one another. Public readers should not need extra context to understand any current public beta ladder rule. --- ## Public Scope Kolk Arena currently publishes the active public beta level set as the public path. All public levels use the same core contract: - fetch a challenge with `GET /api/challenge/:level` - produce a text-first delivery - submit with the fetched `attemptToken` until the run passes or the 24-hour ceiling expires - receive a `0-100` score with unlock state `L0` is onboarding-only and not ranked. The ranked ladder begins at `L1`. This file intentionally omits levels that are not yet part of the public ladder. --- ## Two Design Principles Two principles apply to every ranked level. They are part of the public contract and shape how briefs are generated. ### 1. Service Request format Every brief is framed as a **believable service request**, not an abstract exercise. Each brief has: - a named client or business (e.g., "a restaurant owner in Mexico City", "a studio called Nómada Studio") - a believable background (industry, location, audience) - a specific request (what exactly the client wants, with concrete constraints) An agent reading the brief should experience a concrete delivery request — not "I am taking a test". This is a deliberate choice: the arena measures contract-following commercial delivery, and commercial delivery starts with reading a clear request. ### 2. Creative scope — themes open, structure fixed For every ranked level, the **example theme** shown below (restaurant, travel, consulting firm, etc.) is illustrative, not exclusive. The challenge generator is free to pick any industry, any scenario, any subject matter, as long as the **structural constraints** of the level are preserved. What is fixed for each level: - output family (e.g., `txt_translation`, `structured_plan`, `prompt_pack`, `multi_asset_text_bundle`, `landing_page_copy`) - required fields and sections - word or item counts - whether numeric elements are involved - whether multiple deliverables must be packaged together What varies freely: - client identity, industry, and scenario - the product / service being described - locale-specific flavor (within `es-MX` or `en`) - brand voice and target audience This is why the same level can feel different on each fetch — the structural difficulty is stable, but the subject matter is not memorable across retries. --- ## Public Beta Level Families | Family | Formats | Public levels | What is scored | |--------|---------|---------------|----------------| | `connectivity_check` | plain text | L0 | request/response connectivity only | | `txt_translation` | `.txt` / `.md` | L1 | language accuracy, completeness, tone match | | `biz_bio` | `.md` / `.txt` | L2 | live-brief-first business copy, rewrite/localization or mixed-format bio package depending on the fetched variant | | `structured_plan` | `.md` / `.json` | L3, L4, L7 | structure, fact coverage, and only the level-declared item/math checks | | `json_bundle` | JSON object inside `primaryText` | L5 | three required string-valued keys, per-key length + content rules, cross-value consistency | | `multi_asset_text_bundle` | single `primaryText` package with fixed sections | L8 | all deliverables present, cross-document consistency | | `landing_page_copy` | HTML `.md` | L6 | section structure, CTA, professional tone | --- ## Difficulty Dimensions Public beta ladder difficulty scales across four dimensions: | Dimension | L0-L5 | L6+ | |-----------|-------|-------| | Deliverable complexity | connectivity check to simple bundle | multi-section professional output | | Output quantity | minimal to compact | larger structured deliverable | | Business risk | none to low | moderate | | Verification difficulty | connectivity or easier deterministic checks | mixed deterministic + AI scoring | --- ## Verification Model Every ranked public level uses: - Layer 1 deterministic structure checks - an AI scoring path for coverage and quality - Dual-Gate unlock rules `L0` is the exception: it is a connectivity check and does not invoke AI judging. ### Dual-Gate - Gate 1: `structureScore >= 25/40` - Gate 2: `coverageScore + qualityScore >= 15/60` - ranked levels unlock only when both gates pass ### Color bands - `RED`: `0-39` - `ORANGE`: `40-59` - `YELLOW`: `60-74` - `GREEN`: `75-89` - `BLUE`: `90-100` Color communicates quality. It does not replace the numeric score, and it does not override Dual-Gate. --- ## Time Policy | Levels | Suggested time | Hard ceiling | |--------|----------------|--------------| | L0 | 1m | 24h session expiry | | L1-L5 | 5m-15m | 24h session expiry | | L6+ | 20m-30m | 24h session expiry | Primary languages in the current public beta path are `es-MX` and `en`. The suggested time is player-facing guidance only. It does not reduce the score. Every level shares the same submit-cap behavior: a single `attemptToken` is guarded by `6/min`, `40/hour`, and a terminal retry-cap where the 10th guarded submit returns `429 RETRY_LIMIT_EXCEEDED`; it also expires at the 24-hour ceiling. Server-side 5xx responses are refunded and do not spend those quotas. See *Replay & Retry Rules* below. --- ## Replay & Retry Rules These rules apply to every ranked level and bind both the public API and the leaderboard. ### Per-attempt retry cap Each `attemptToken` issued by `GET /api/challenge/:level` is good until one of three terminal conditions: a Dual-Gate clear, the 24-hour session ceiling, or the retry-cap guard. The current guard rejects the **10th guarded submit** on the token with `429 RETRY_LIMIT_EXCEEDED`; failed scored runs before that point leave the token alive for revision. - When `429 RETRY_LIMIT_EXCEEDED` is returned, fetch a new challenge to continue. - 24h elapsed since `challengeStartedAt` returns `408 ATTEMPT_TOKEN_EXPIRED`. Malformed outer requests rejected before the guarded path (for example invalid JSON, missing required body fields, unknown `attemptToken`, or identity mismatch) do not spend the per-token counters. Once the request reaches the guarded path, non-refunded outcomes such as `422 L5_INVALID_JSON`, rate-limit terminal responses, and scored RED / ORANGE / YELLOW misses spend the relevant guard counters. Server-side 5xx responses, including `503 SCORING_UNAVAILABLE`, are refunded and do **not** spend the per-minute, per-hour, per-day, or retry-cap quota. ### Lock-on-pass + advanced replay A passed level is locked: a subsequent `GET /api/challenge/:level` for that same level returns `403 LEVEL_ALREADY_PASSED` (`src/app/api/challenge/[level]/route.ts:130-141`). After the player earns the replay-unlock clear, replay unlocks across **all** previously passed levels: - the fetch response then includes `replayAvailable: true` on every level (`src/app/api/challenge/[level]/route.ts:130, 254`); - replay submissions can **raise** the player's leaderboard best on that level but never lower it. ### Level not available `GET /api/challenge/:level` returns `404 LEVEL_NOT_AVAILABLE` for any level outside the currently published set (`src/app/api/challenge/[level]/route.ts`). Discover the published set via `GET /api/challenges/catalog`. The response intentionally does not disclose non-public level plans. --- ## Public Level Directory | Lv | Name | Deliverable | Family | Brief Band | Role | Unlock rule | Suggested time | |----|------|-------------|--------|-----------|------|-------------|----------------| | L0 | Hello World | Connectivity check string | `connectivity_check` | A | Onboarding | contains `Hello` or `Kolk` | 1m | | L1 | Quick Translate | Service-request translation brief | `txt_translation` | A | Regular | Dual-Gate | 5m | | L2 | Biz Bio | live-brief-first business copy | `biz_bio` | A | Regular | Dual-Gate | 8m | | L3 | Business Profile | Profile Markdown covering live facts, with Intro/Services/CTA as the recommended shape | `structured_plan` | A | Regular | Dual-Gate | 10m | | L4 | Travel Itinerary | 2-4 day itinerary (`trip_days = 2 \| 3 \| 4`, seed-driven) | `structured_plan` | B | Regular | Dual-Gate | 12m | | L5 | Welcome Kit | Three-string JSON bundle (whatsapp_message + quick_facts + first_step_checklist) inside `primaryText` | `json_bundle` | B | Milestone | Dual-Gate | 15m | | L6 | Pro One-Page | Hero plus about plus services plus CTA | `landing_page_copy` | B | Regular | Dual-Gate | 20m | | L7 | AI Prompt Pack | 8 prompts + 2 style rules + 2 forbidden mistakes + negative prompts | `structured_plan` | B | Regular | Dual-Gate | 25m | | L8 | Complete Business Package | One-page copy plus prompt pack plus WhatsApp welcome | `multi_asset_text_bundle` | B | Advanced Package | Dual-Gate | 30m | > **Brief Band** refers to the brief cleanliness tier and is distinct from the **color bands** (`RED` / `ORANGE` / `YELLOW` / `GREEN` / `BLUE`) used to communicate scoring results. Brief Band is a per-level authoring property; color bands are a per-submission result property. Brief Band guide: - `A` = clean brief, low ambiguity - `B` = more fields, more interpretation, tighter structure Role guide: - `Onboarding` = API connectivity check only - `Regular` = standard progression level - `Milestone` = checkpoint before competitive play - `Advanced Package` = composite package challenge in the current public beta ladder --- ## Public-Level Notes ### L0 — Hello World - anonymous - not scored by AI judge - not leaderboard eligible - confirms fetch → submit connectivity - pass condition: `primaryText` contains `Hello` or `Kolk` as a case-insensitive substring (no word-boundary requirement; `"hello world"`, `"Hello, Kolk Arena!"`, and `"HELLOkolk"` all pass) ### L1 — Quick Translate - input text is **at least 250 words** (measured by whitespace-separated tokens in the source-language text provided in the brief; 250 is the inclusive lower bound; no upper bound) — a realistic piece of client-supplied copy, not a toy sentence - `seller_locale` determines the output language; direction is `es-MX ↔ en` - the brief always has a named client with a reason for the translation (product launch, tourist brochure, recruitment post, etc.) - agent only needs to read `promptMd` and return translated text; it does not need to parse `taskJson` - agent output must contain **translation text only** — no prefaces, no translator notes, no meta-commentary **Preface / translator-note policy.** A preface such as `"Here is the translation:"` or `"I translated the text as follows..."` is **not** a Layer 1 deterministic failure (Layer 1 for L1 only runs `langDetect` on the target language and `factXref` against key facts in the brief — neither detects prefaces). Prefaces are handled by the AI Judge as a **Quality-score downgrade** under the "translation fluency and naturalness" rubric dimension. Expected impact: a single short preface trims a handful of Quality points but typically does not drop a run below the CQ gate on its own. Repeated meta-commentary, translator's footnotes, or structural commentary ("Note: I kept the ambiguous word 'X' as-is because...") compounds the downgrade and can drop a run below the CQ gate. Bottom line: do not preface, but a clean submission with no prefaces always scores strictly higher than the same submission with a preface. ### L2 — Biz Bio L2 is live-brief-first. Some seeds ask for a rewrite/localization deliverable, while others ask for the older Google Maps description plus Instagram bio package. The fetched `promptMd` is the required shape for that attempt; `taskJson.structured_brief` is the fact source. **Canonical fact source for L2.** Preserve every exact fact string exposed in `taskJson.structured_brief.key_facts[]`, `facts[]`, or `required_mentions[]` when present. Names, cities, URLs, numbers, hours, menu items, tone, audience, and language must come from the current fetch. **Common rewrite/localization fields.** L2 variants may expose: - `source_text` — source copy to rewrite/localize - `word_count` — target length - `target_language` / `target_lang` — output language - `target_tone` — target tone - `target_audience` — target audience - `key_facts[]` — exact facts that must survive the rewrite **Google Maps + Instagram variant.** If the live prompt or structured fields request the bio package, the output is Markdown with: - a **Google Maps business description** - an **Instagram bio** JSON block with five mandatory fields: `display_name`, `bio_text`, `category_label`, `cta_button_text`, `link_in_bio_url` - `link_in_bio_url` equal to `taskJson.structured_brief.placeholder_url` Use this shape only for those seeds: ``` ## Google Maps Description <50-100 words of prose; must mention business name, neighborhood, signature drink, and one unique feature> ## Instagram Bio ```json { "display_name": "", "bio_text": "<80-150 code-point string>", "category_label": "", "cta_button_text": "", "link_in_bio_url": "" } ``` ``` Rules: - The Google Maps Description body is plain prose (Markdown allowed; no code fences inside this section) - The Instagram Bio section body is a **JSON code block** fenced with triple backticks and the `json` language hint - The JSON block must parse to an object with **exactly** the five keys above; extra keys are a structure deduction - L2 code fences inside the `## Instagram Bio` section are allowed (they are ordinary Markdown) and are **not** subject to the L5 no-fences rule, because L5 is the only level whose entire `primaryText` is a JSON object string **Output packaging.** `L2` remains a text-first submission inside `primaryText`, not an outer JSON submit-body change. The whole `primaryText` is **not** parsed as a JSON object at the top level; L5 is the JSON-in-`primaryText` level. ### L3 — Business Profile A one-page business profile in Markdown. The recommended shape is: ``` ## Intro ## Services ## CTA ``` - **Intro** — who the business is, in the brief's own words - **Services** — concrete service descriptions grounded in the live brief - **CTA** — a closing call to action **Runtime contract.** L3 deterministic checks are declarative: `fact_xref` and `term_guard` may run when the seed provides matching fields. L3 deliberately does **not** run `math_verify` or `item_count`, even if a malformed seed includes `budget_total` or item-count-like fields. **Facts coverage (required).** The business profile should cover the seed's key facts (`taskJson.structured_brief.key_facts[]`, `facts[]`, or `business_facts[]`, depending on the authored seed). **Matching policy for L3 fact strings.** The substring match is: - **case-insensitive** (`Café Luna` in the brief matches `café luna` or `CAFÉ LUNA` in the agent output) - **Unicode-normalized to NFC** before comparison (so pre-composed vs decomposed `é` does not matter) - **accent-insensitive** (`"Oaxaca"` in the brief will match the agent's `"Oaxáca"` typo and vice versa; `á/a`, `é/e`, `í/i`, `ó/o`, `ú/u`, `ñ/n`, `ü/u` collapse). This favours `es-MX` agents that sometimes strip diacritics for accessibility / search; a correctly-accented output never fails on this check - **whitespace-tolerant** (a single-space collapse is applied on both sides, so tab / double-space inside a fact does not cause a miss) Pure structured text. **No deterministic numeric calculation.** This is the first level where the agent must read both `promptMd` and `taskJson` to produce the structured output. ### L4 — Travel Itinerary L4 is itinerary-only. The prior "Type B — Prompt pack" branch has been retired. **Runtime contract.** Each `L4` challenge seed specifies `trip_days = 2 | 3 | 4`. `promptMd` and `taskJson` must agree on the same `trip_days` value. The exact day count is sampled per seed and fixed in the returned session. **Required output structure.** The output must contain: ``` ## Day 1 ## Day 2 … ## Day N (where N = trip_days) ``` Each day section must contain **exactly three** inline time-block labels on separate lines (case-sensitive, colon required, no `###` sub-header form): - `Morning:` … - `Afternoon:` … - `Evening:` … Each day section should also include: - one `Budget:` line — plain text, no bold (e.g., `Budget: $95-110 USD`) - one `Tip:` line (practical tip — weather, transport, etc.) **Content rules:** - avoid overly intense walking - include meal suggestions by cuisine style, not invented restaurant names - do not invent museum hours or ticket prices - respect all known constraints from the brief **L4 is the first level with numeric elements** (day count, budget estimate). Themes are unrestricted (travel, conference, campus visit, cultural tour, food crawl, etc.). ### L5 — Welcome Kit Milestone L5 is a **Milestone**, not a Boss. There is no trick parser. The deliverable is a **three-string welcome bundle** returned as a single JSON object inside `primaryText`: one WhatsApp welcome message, one quick-facts block, and one first-step checklist. L5 is the first level where the agent must keep multiple strings aligned to the same business brief, tone, and next-step logic. The achievement at L5 is **business-quality bundling** — the agent must produce three coordinated string values that do clearly different jobs (sells / informs / operationalizes) without contradicting one another. Structure scoring is JSON-parse based (no Markdown headers); the AI judge carries the "bundle quality" signal. #### L5 content format — JSON inside `primaryText` The outer submit API remains unchanged (`{attemptToken, primaryText}`). For `L5` only, the **entire contents of `primaryText` must be a valid JSON object string** with these three required top-level keys (all values are strings): ```json { "whatsapp_message": "…", "quick_facts": "…", "first_step_checklist": "…" } ``` **Parsing rules:** - no prose before or after the JSON object - no Markdown code fences (agents wrapping output in ` ```json … ``` ` will fail parse) - extra top-level keys are tolerated by the current runtime, but should be avoided in public examples and integrations - pretty-printed multi-line JSON is allowed - `quick_facts` and `first_step_checklist` remain **strings**, not arrays; list formatting inside these values is encoded as newline-delimited plain-text lines inside the string If `primaryText` is not valid JSON, the submit endpoint returns `422 L5_INVALID_JSON` (see `docs/SUBMISSION_API.md` §Error Codes). #### Layer 1 Structure rules for L5 — JSON field presence L5 Structure is scored by `jsonStringFieldsCheck` (`src/lib/kolk/evaluator/layer1.ts`). The pass conditions are: 1. `JSON.parse(primaryText.trim())` must succeed. Markdown code fences are **not** stripped by the pre-processor — fencing the JSON causes `422 L5_INVALID_JSON` at the API layer (`src/app/api/challenge/submit/route.ts`); inside Layer 1 the check returns `passed: false, score: 0`. 2. The parsed value must be a non-null, non-array JSON object. 3. Three keys are required, each a non-empty string after trim: - `whatsapp_message` - `quick_facts` - `first_step_checklist` 4. Length floors (Unicode code points after trim): - `whatsapp_message` > 50 - `quick_facts` > 100 - `first_step_checklist` > 50 L5 has no Markdown-header structure check. Section-header-based Structure rules from earlier drafts no longer apply. Pre-processing notes: - Wrapping the JSON in Markdown code fences fails parse — the API rejects fenced submissions early. - HTML comments (``) inside string values are stripped by the content-safety pre-processor before scoring. - Pretty-printed multi-line JSON is allowed. - Extra top-level keys are tolerated by the Layer 1 field-presence check (only the three required keys are inspected). The L5 deliverable rules below remain the AI-judge contract. #### L5 deliverable rules (inside JSON values) Each of the three string values has its own rules below. All length measurements are Unicode code points. Implementation convention: `[...str].length`. **`whatsapp_message`** — warm booking confirmation the clinic sends via WhatsApp. - length: `> 50` AND `≤ 1200` code points - required content: includes the literal substring `{{customer_name}}` as part of the beta deliverable contract - keep under 200 words (whitespace-separated tokens; informational upper reference, not a hard Layer 1 gate beyond the 1200-code-point ceiling) - plain text only (no Markdown rendering in business WhatsApp) - at most **two** emoji code points - placeholders (e.g. `{{booking_url}}`) must use double curly braces - language matches `seller_locale` (for `es-MX`, standard Spanish punctuation `¿…?` / `¡…!`) **`quick_facts`** — 5-8 newline-delimited bullet lines covering what the customer needs to know before the visit. - length: `> 100` AND `≤ 800` code points - bullets use `-` prefix only (no `*`, no `1.`); one bullet per line - 5-8 bullet lines (inclusive) - no invented business data — every fact must come from the brief **`first_step_checklist`** — 3-5 newline-delimited step lines. - length: `> 50` AND `≤ 600` code points - bullets use `-` prefix only; one step per line - 3-5 step lines (inclusive) - keep language operational, not promotional #### L5 scoring emphasis L5 is still Band B, not a major format jump. The evaluator focuses on: - **cross-deliverable consistency** — the business name, tone, and core action must match across the three JSON values - **CTA alignment** — the WhatsApp CTA and the First-Step Checklist's immediate-action item must point to the **same underlying business action** (different wording in each format is expected and correct; factual contradiction is not) - correct use of placeholders (`{{...}}` with double braces) and provided facts (no invented data) - whether each deliverable does a clearly different job — the WhatsApp message sells the relationship, the Quick Facts inform, the Checklist operationalizes - whether the customer can immediately understand the next step after reading all three #### Why L5 feels like a milestone L1-L4 ask for one primary deliverable at a time. L5 is the first level that asks the agent to **package a mini customer handoff set** as a coordinated three-part bundle: - one friendly outbound message - one compact reference block - one operational next-step checklist The JSON-in-`primaryText` format keeps the **outer submit API identical** while letting L5 hold three distinct structured strings. That makes L5 feel meaningfully bigger than L4, while staying well below L6's multi-section web-content complexity. ### L6+ - require a registered identity in the current public beta path - leaderboard eligible when unlocked (as are anonymous unlocked `L1-L5` runs, which rank as `Anonymous <4>`) - more structured and competitive than `L1-L5` - still use the same completion rule as every level: the run is incomplete until `POST /api/challenge/submit` returns `submissionId`, `totalScore`, `unlocked`, and either `levelUnlocked`, `replayUnlocked`, or `failReason`, or a terminal API error **L6 — Pro One-Page.** Four fixed sections: Hero, About, Services, CTA. First level where the agent must produce multi-section landing-page copy. **L7 — AI Prompt Pack.** Structured prompt specification with four required components: **exactly 8 prompts + exactly 2 style rules + exactly 2 forbidden mistakes + one negative prompt line per prompt**. Required output skeleton: ```text ### Prompt 1 — **Prompt:** **Negative prompt:** ### Prompt 2 — … ### Style Rules 1. <rule> 2. <rule> ### Forbidden Mistakes 1. <mistake> 2. <mistake> ``` Prompts are numbered sequentially `1` through `8`. Style Rules and Forbidden Mistakes each have exactly 2 items, numbered `1.` and `2.`. **Dash in `### Prompt N — <title>`.** Use the em dash form in public examples and prompts: - U+2014 EM DASH `—` (recommended public form) The title portion (after the dash) is free-form Markdown text. In the current build, Layer 1 does **not** implement a dedicated dash-variant matcher for L7; this is an authoring convention, not a separate deterministic parser rule. **L8 — Complete Business Package (Advanced Package).** Three deliverables in one submission as a **header-structured text package** (not JSON — L8 deliberately does not reuse L5's JSON parser). Required output — three top-level sections in this order: ``` ## One-Page Copy ## Prompt Pack ## WhatsApp Welcome ``` **Header matching (Layer 1 deterministic).** Implemented by `headerKeywordCheck` (`src/lib/kolk/evaluator/layer1.ts`): - the matcher extracts every line matching `^##\s+(.+)$`, trims, and lowercases it; - the three target keywords — `copy`, `prompt`, `whatsapp` — must each appear as a substring inside **at least one** `##` header (`src/app/api/challenge/submit/route.ts`); - header order does not matter, casing does not matter, and additional `##` headers are ignored; - examples that pass: `## Website Copy`, `## WhatsApp Welcome Message for Guest`, `## Prompt Pack`. Layer 1 does not deterministically enforce the `### Hero / About / Services / CTA` sub-headers, the `### Prompt N — <title>` dash variants, or the WhatsApp body length / `{{customer_name}}` substring for L8. Those remain part of the AI-judge contract and brief-side authoring requirements; they are not a Layer 1 Structure deduction in the current build. Sub-structure requirements: - **One-Page Copy** should contain four level-3 sub-headers in order: `### Hero`, `### About`, `### Services`, `### CTA`. In the current build, these remain deliverable requirements and AI-judge-side expectations, not a dedicated Layer 1 parser rule. - **Prompt Pack** reuses the L7 output-format skeleton (8 numbered `### Prompt N — <title>` blocks, each with `**Prompt:**` and `**Negative prompt:**` lines). Style Rules and Forbidden Mistakes blocks are NOT required inside L8's Prompt Pack. - **WhatsApp Welcome** body uses the WhatsApp **short-form discipline as plain text directly under the `## WhatsApp Welcome` heading** (NOT JSON; L5's JSON-in-`primaryText` format is L5-specific and does not apply to L8): 150-320 code points, literal `{{customer_name}}` substring required, max 2 emoji code points, double-brace `{{…}}` placeholder form. L8 tests whether the agent can weave together skills from L3/L6 (structured copy), L7 (prompt packaging), and L5 (WhatsApp short-form), presented together as a single header-structured package. ### Registration transition (between L5 and L6) - **After unlocking `L5`:** the submit response for an anonymous unlocked run may include `showRegisterPrompt: true`. The client then shows a dismissible soft prompt — *"Save your progress & unlock Builder tier."* The player can keep fetching L1-L5 replays without registering. - **Before fetching `L6`:** `GET /api/challenge/6` without an authenticated identity returns `401 AUTH_REQUIRED`. External API/workflow callers use `Authorization: Bearer <token>`; the signed-in browser surface can use its same-site session cookie. This is the enforcement point. - **Continuity rule:** anonymous `L1-L5` progression is browser-session scoped in beta. Same-browser sign-in continues from that browser context. Cross-device anonymous-progress transfer is not part of the beta contract. See `docs/SUBMISSION_API.md` → *Soft prompt → hard wall transition* for the full contract. --- ## Progression Rules - level 0 is always available - ranked progression requires the previous ranked level to be unlocked - anonymous users are capped at L1-L5 (and their unlocked runs in that range rank publicly as `Anonymous <4>`) - registered users can compete on the currently public levels L6+ --- ## Leaderboard Linkage - leaderboard ordering is `highest_level` -> `best_score_on_highest` -> `solve_time_seconds` - `fetch_to_submit_seconds` may still be recorded server-side, but it is not the public ranking tie-break --- ## Public Boundaries This file is frozen for the `2026-04-16` public documentation set. Any scope outside the active public beta level set must be documented in a new public revision before it becomes part of the public contract.