subjects /

.

open opened · touched

# SUB-020 , Cosmos Weekly Board Product Spec (+ Glossary + Status Alignment)

> Ingested 2026-06-08 from the Confluence "Specs" index (eng 816906278) and its 3 linked pages. Author Sergey. This is the canonical product spec for the Cosmos (Cosmo v2) quota + weekly-board core. > Pages: > 1. Cosmos Weekly Board , Product Spec , eng 816906298 (v1, 2026-06-04). The definitive quota/board reference. > 2. Glossary , eng 816939017 (v2, 2026-06-04). Canonical terms. > 3. Status Alignment , Quota · Apollo Task · Orchestration , eng 816742434 (v1, 2026-06-04). The status-mapping technical reference. > 4. PG Operational Flows (802881537) , already ingested (SUB-017). > Significance: this RESOLVES our long-open C1 (lifecycle-vocabulary conflict) and C3 (revision origin-conflation) at the spec level, and gives us the full quota data model we never had.

---

Why it matters to us (the headlines)

1. C1 resolved , the canonical status vocabulary now exists, written down. The Status Alignment page gives the exact status sets for all three entities and the mapping. Our SUB-017 C1 flagged "Sergey's live UI labels vs our locked 13-status schema , which is ground truth?" Answer: there are THREE entities with THREE vocabularies, and they roll up. Our Playable-Schema's 13 statuses were conflating quota-level and work-item-level. See "The three vocabularies" below; reconcile Playable-Schema.md against this. 2. C3 resolved as a stated rule , "revision = client-returned only, company-wide." Internal rework is explicitly NOT a revision; pg-revision now routes to last-mile/Polishing, not "revision." This is the origin-conflation fix we said was needed, now Sergey's locked ruling (though still partially broken in live data). 3. The quota model is fully specified , we finally have the data model (commitment + wrapper, flavors, composition tiers, attach mechanisms, roll-up). Most of our pain clusters now have a spec-level "intended behavior" to design against. 4. Sergey ships his own "broken today" list , 11 rules tagged "⚠ broken today" = live divergences from intent. Many ARE our pain clusters, now confirmed by the author with root causes. 5. Scope boundary stated , the board core EXCLUDES Atlas (ideation), the LLM prioritization agent, Apollo build/delivery internals, and customer-facing surfaces. This is the seam between "what Cosmos owns" and "what we flagged as the dark stages."

---

The quota model (canonical)

World model nesting: client -> game -> quota -> work item -> idea.
  • Quota = the central unit. Two things at once: (a) a commitment to deliver one playable for a client; (b) a wrapper around the work items an auditor produces. The wrapper lets the slot survive idea churn. One quota = one game = one client, one week, (once on board) one auditor + priority position. Remembers the week it was FIRST created (so "dragging 3 weeks" survives rollovers).
  • Work item = one idea on its way to a playable; carries idea + game + auditor + live production status. The link between an idea and a quota.
  • Idea = creative concept, scoped to one game, flagged customer-request / high-priority, typed version or concept/core.
  • Game carries a tier (VIP / FDE / Tier 1/2/3) + a monthly target.
  • Scale today: 30+ auditors, 5 teams (sized 3-8), ~46 games/week, ~27 clients/week, ~32 auditors on board.
Two quota flavors: Version quota (~60% of active) vs Revision quota (~40%, but inflated by mislabeled internal rework). Revision = client-returned only, created automatically when a client-returned playable re-enters the pipeline, carries exactly that one playable. Composition tiers (the spine), ranked: Customer-request -> Last-mile -> High-priority -> Regular. | Kind | Holds | Why | |---|---|---| | Customer-request (CR) | 1, solo | client asked for this exact playable | | Last-mile (LM) | 1, solo | falls out of submit behavior | | High-priority (HP) | 1, solo | important enough to stand alone | | Regular | bundle (currently 2) | auditor can drop a weak idea, another queued |
  • Bundle size = 2 today, intended to become admin-controlled (maybe per-game). Regular never grows past bundle size. Solo quotas (CR/HP/LM) never absorb a re-homed item.
The 3 (and only 3) ways work enters a quota , NO manual assign exists: 1. Fill on creation , filled per composition tiers, priority order CR -> LM -> HP -> regular. Shortfall is visible (missing quotas just aren't created). 2. Refill on cancel , quota heals itself; pulls one more same-game/same-auditor item, else refills from scratch, else marked unfillable. 3. Reattach , a freed-but-live item re-homes to another same-game/same-auditor/same-week quota with room. Dead items never relocate. CR/HP/LM never absorb. Detach on submit , on submit, quota flips to last-mile, siblings detach + try to reattach. Last-mile = exactly 1 item. PG-accept -> quota completed, accepted item stays, siblings detach.

---

The three vocabularies (Status Alignment , resolves C1)

Three entities, each its own status set, rolling up. One Apollo Task <-> one Orchestration; one Quota <-> one-or-more Orchestrations.

  • Apollo Task (root signal): queued · running · waiting_input · pending_team_lead · pending_pg · succeeded · failed · canceled.
  • Orchestration (Cosmos wrapper for one work item; has a stage ideation->apollo->build->delivery->done + a status): queued · in_progress · tl_review · pg_review · completed · sent_to_customer · customer_approved · customer_declined · revision · failed · blocked · cancelled · archived.
  • Quota (the slot, rolled up): open · in_progress · last_mile · completed · canceled · unfillable. Only last_mile is rollup-specific; it carries 3 sub-states Pending TL / Pending PG / Polishing.
Mapping (Apollo Task -> Orchestration): queued/running/waiting_input -> in_progress; pending_team_lead -> tl_review; pending_pg -> pg_review; succeeded -> completed; failed -> failed; canceled -> cancelled. Roll-up (work item -> quota), most-advanced-wins: any accepted -> Completed; any submitted -> Last mile (solo); any working -> In progress; all cancelled + no refill -> Unfillable; else Open. The 5 quota statuses (user-visible):
  • Open , committed, nothing moving (chip suppressed on assigned-lane + backlog cards).
  • In progress , >=1 item actively worked (still cancellable, no ship promise).
  • Last mile , submitted, "very likely to finish soon" (the most important business signal). Solo. Sub-states Pending TL / Pending PG / Polishing. A kickback STAYS in last-mile.
  • Completed , PG-accepted ("ready to send"), build kicked off. Solo. Completed != delivered , stays completed through build, build-failure, even customer decline. The board is an auditor-production view, not a delivery tracker.
  • Unfillable , nothing left to fulfill the slot. Dead, does not roll over.
Key caveat , Completed != delivered. A quota turns completed at PG-accept, long before (sometimes without) reaching the customer. In a recent week only a small fraction of completed quotas were actually sent; most were in build/delivery; some had their build FAIL after PG-accept and still read completed. Intended. Reading the board as a delivery tracker over-counts shipped. (This is the mechanism behind our SUB-019 divergence: the board counts quotas at auditor-production grain, the delivery page counts orchestrations at delivery grain.) Invalid combinations to catch (anomaly checks):
  • Orchestration at build/completed while its task still pending_tl/pending_pg/waiting_input = premature build.
  • Quota completed while its task still in review/in-progress.
  • Quota last_mile holding >1 item.
  • CR or HP quota holding >1 item.
  • Regular quota holding > bundle size.
---

Sergey's own "broken today" list (11 divergences from intent) , maps to our pains

| # | Broken rule | Our cluster | |---|-------------|-------------| | HP not solo | weekly auto-fill bundles 2-3 HP ideas (10 over-stuffed HP quotas wk of Jun 1: monster-legends x3, two-dots x3, etc). Root: two creation paths (dominant weekly auto-fill ignores solo rule; smaller on-demand Allocate obeys it). | C11 (rules-in-heads) | | grow-to-3 relic | regular quota can still grow to 3 instead of bundle size 2. | C10 | | refill empty-path | empty quota doesn't reliably refill (goes unfillable, evaporating a commitment) + when it does, pulls a whole bundle not one item. | C10 / SUB-015 #5 | | saved-vs-live status lag | saved quota status only refreshes on Apollo callback, NOT on user action (e.g. send-to-Apollo). Board re-derives truthful status on the fly; the card disagrees with the saved value (real case: saved "open" vs board "in-progress" for 1h45m). Risky for rollover/reports/automations reading the saved value. | C2 (trust) | | premature build/completed | orchestration reads build/completed while task still in review. | C2 | | version-count pollution | Manage Quotas stepper start + floor wrongly count revision quotas as versions (match-factory: 15 assigned, only 1 real version). | C2 / quota math | | revision conflation | internal rework historically labeled "revision" (same chip/round/age/column). pg-revision fixed (-> Polishing); other internal turn-backs still surface as "revision." | C3 | | revision-age-from-latest-round | age counted from latest round not first request; detail panel shows no age; age-filter buckets key off latest. | C3 / C8 | | rollover dead-logic | rollover rule references "pending review" quota statuses never actually written (harmless today, misleads readers). | C11 | | two creation paths disagree | weekly auto-fill vs Allocate follow different rules, dominant one wrong. | C11 | | canonical-status divergence | the saved-vs-live split above; fix = make saved value always-current. | C2 |

---

What this ADDS that we did not have (net-new)

  • The complete quota data model , we had fragments (SUB-017 mentioned quota/orchestration/Apollo-task as 3 grains via SUB-019). Now the full model: composition tiers, bundle mechanics, 3 attach mechanisms, detach-on-submit, roll-up algorithm.
  • The canonical status vocabularies + mapping table , directly usable to reconcile our Playable-Schema.md (which mixed quota + work-item statuses into one 13-status list).
  • Scale numbers , 30+ auditors, 5 teams, ~46 games/week, ~27 clients/week, bundle=2, ~60/40 version/revision split.
  • The Manage Quotas planning panel spec , 6 columns (Game w/ delivered-this-month/monthly-target badge, Revisions, Ideas pool w/ Atlas+detached split, Assigned all-types, Rolled, editable Quota stepper). Stepper rules (can't go below assigned, can't exceed idea pool, clamps on concurrent assignment). This is the surface our weekly-board spec should converge on.
  • The card anatomy (game name primary, playable title under, status chip + duration, type chip + revision age, rolled-over marker, tier chip, HP crown + CR megaphone, difficulty chip, quota id, assignee avatar).
  • Rollover rules , what rolls (live work: not-started/in-progress/last-mile/revisions) vs what doesn't (completed/cancelled/unfillable). Renumber to clean 1..N on roll-in.
  • "Polishing" as a named LM sub-state still being built , the visible home for internal/PG send-backs.
  • Why Cosmos exists , original Cosmo was engineer-built, no product oversight, accreted into patchwork; rebuilt from scratch, weekly board first (strongest link between business priority and the floor).
---

Cross-file actions (flagged, not yet done)

  • Reconcile vault/04-Concepts/Playable-Schema.md against the canonical 3-vocabulary model. Our 13-status list conflates quota + work-item levels. (Big job , confirm with Ishai before editing the locked schema.)
  • Update SUB-018 , C1 + C3 can now be marked spec-resolved (link SUB-020). C2's quota-math + saved-vs-live pieces now have Sergey's named root causes.
  • Update the entity glossary (vault/98-References/Cosmo-PG-entity-glossary.md) , the quota/work-item/idea/composition-tier/bundle/orchestration terms now have canonical definitions. (Done this session.)
  • Open-Questions/PG.md , several of our open items are now answered (revision = client-returned, status vocab, completed!=delivered). Mark resolved.

Still-open per Sergey (his own homework)

  • Abnormal orchestration states (blocked/archived/disabled) , real meaning or status bloat? No quota-level meaning yet.
  • Apollo task failure during auditor work , quota status left unchanged for now; frequency/recoverability/owner still open with eng.
  • The distinct NAME for internal rework (non-pg-revision cases) , not yet settled.
  • Revision-age canonical definition + where it lives (card vs detail panel) , still being settled.
  • Customer-decline -> billing/learnings impact , separate business/ops question.
context-shift paste this id into chat to resume on this thread