# SUB-018 , PG Pain Correlation + Sergey-Doc Contribution
> Deep-research synthesis, 2026-06-07. Fanned out 5 parallel readers across the PG corpora (problem catalogue, JTBD/users, meeting notes, SUB-012/015/017, specs), then correlated pains by root cause, then assessed what Sergey's "PG Operational Flows" doc contributed to our PG-experience + JTBD understanding, then a where-can-we-contribute pass.
> Companion visualization: cosmo-design/designs/pg-pain-map.html (served locally).
> Raw workflow output: 8 agents, 821k tokens. This file = the durable distillation.
---
The narrative (where the leverage is)
Across five independent corpora the same PG pains keep landing on a small number of architectural roots, which makes the high-leverage moves unusually clear. The two deepest roots are a trust failure (no single source of truth, so revision and quota counts diverge across pages and viewers and conflate internal with client revisions) and an integration void (Cosmo goes dark for four of the eight lifecycle stages because it never syncs status, names, or failures with Apollo, Atlas, Slack, and the build pipeline). Layered on top: a missing PG-scoping model (no my-games default, the reason PGs have the lowest adoption of any role), rules + vocabulary that live in people's heads instead of the product, and the absence of time/SLA as a first-class signal on Ready to Send (the surface three separate PG sources independently name as their primary workspace).
---
12 pain clusters (by root cause)
| ID | Cluster | Severity | Sources | Root cause (short) | |----|---------|----------|---------|--------------------| | C1 | Cross-system status invisibility (Cosmo goes dark) | critical | 5 | Cosmo never syncs/displays status from Apollo/Atlas/Slack/Build, which own 4 of 8 lifecycle stages | | C2 | Numbers nobody trusts | critical | 6 | No single source of truth / data dictionary; each view applies unlabeled filters + different counting | | C3 | Revision model conflates origin/quality/lifecycle-state | high | 6 | One undifferentiated revision concept; 6-type taxonomy specced, never built | | C4 | No PG-scoped view (my-games) | high | 5 | No ownership/scoping model surfaced to PG; stale rosters | | C5 | Tool fragmentation forces PGs out of Cosmo | high | 5 | One job spread across Atlas/Apollo/Monday/Slack/Logos/ACK, no bridges | | C6 | Naming / provenance / sync breakage | high | 5 | Names assigned in many systems, no freeze-point, no propagation | | C7 | No core-awareness; pre-core pollutes views + quota math | medium | 5 | Cores never modeled in Cosmo | | C8 | Ready-to-Send lacks SLA / aging / priority logic | high | 5 | Time never modeled as first-class signal on the primary PG surface | | C9 | Manual labor where automation expected | medium | 5 | Weekly quota, demand chain, prompt dispatch all manual; logic in heads | | C10 | Quotas mutate invisibly; actions cryptic + irreversible | high | 4 | State changes with no audit trail; no confirm/undo; raw backend errors | | C11 | Priority rules + lifecycle vocab live in heads | high | 6 | Operational rules + stage vocabulary not encoded in model/UI | | C12 | Surfaces built without a defined job | medium | 5 | Designed around delivery, not the real PG job (land-and-expand) |
Full member-pain lists (each tagged with source: Pnn / SUB-015 #n / SUB-017 / speaker+date / spec) live in the viz and the raw workflow output.
---
9 cross-source signals (3+ independent sources , highest confidence)
1. Internal corrections counted in the same pool as client revisions , 5 sources. Mechanism behind the 34/104/181/244 discrepancy AND why Harel's revision-rate + fix-type catalogue can't exist. 2. Counts differ across pages + across viewers (unlabeled filters) , 4 sources. Duskin's own diagnosis confirmed by live support screenshot-comparisons. 3. Cosmo goes dark for 4 of 8 lifecycle stages , 5 sources. Support channel adds the concrete cause (5MB build fails, Apollo failures never surfaced). 4. No filter-by-my-games / PG-scoped view , 4 sources. #1 reason PG adoption is lowest; Sergey sharpens it to a hard gate. 5. Naming diverges across Atlas/Apollo/Cosmo/zip, no freeze-point , 4 sources. Harel's #1-ranked pain; Sergey supplies the mechanism (zip name sticks, inner files revert). 6. Revisions-before-new-work rule exists only in heads , 4 sources. JTBD verbatim "the list doesn't tell me that" + unresolved PG-vs-TL authority conflict. 7. Pre-core games pollute views + quota math , 5 sources. Eng-acknowledged; Sergey escalates display-noise -> data-integrity. 8. Ready to Send is THE PG surface, yet aging/SLA absent , 3 sources. Three separate PG interviews land on the same primary surface. 9. PGs work across many disconnected tools, no bridges , 4 sources. Topology only became visible via Sergey's doc; tax quantified at 20-30 min per feedback event.
---
6 root causes (ranked by leverage)
1. [highest] No single source of truth / data dictionary for counts. Dissolves C2, C3, C10. [UPDATE 2026-06-07: C2's revision-count half is now mechanism-resolved , see [[SUB-019]]. Sergey's team reconciled Cosmo-vs-Cosmos item-by-item: the two pages count different objects (orchestrations vs quotas), and the entire gap decomposes into 5 SQL-checkable problems (detached/no-quota, advanced-to-build, prior-week, fake-revision-quota, bundling). The fix is normalize-to-one-grain + a standing validation agent, not "make them match." Our opportunity #2 sharpens accordingly: label which object each count counts + surface the reconciliation bridge + flag the anomalies inline.]] 2. [highest] No integration/sync/provenance layer with external tools (the "goes dark" void). Dissolves C1, C5, C6. 3. [high] No ownership/scoping model surfaced to the PG. Dissolves C4. 4. [high] Operational rules + lifecycle vocabulary live in heads, not the model/UI. Dissolves C3, C7, C11. 5. [high] Time/aging/SLA never modeled first-class; no confirm/undo. Dissolves C8, C10. 6. [medium] Surfaces designed around delivery, not the real PG job; core workflows left manual. Dissolves C9, C12.
---
What Sergey's doc contributed (PG experience + JTBD)
One-line verdict: Sergey's doc gave us the PG's actual end-to-end operating system across Atlas, Apollo, Monday, Slack, ACK, Logos, and Helix, turning many symptom-level pains into named mechanisms (build failure at 5MB, zip-name-vs-inner-file revert, Mark-as-Sent quota choice) while adding whole new job classes (knowledge authoring, pre-send QA, network-rejection recovery, ID matching) and a fresh set of ground-truth reconciliations we now owe eng and the PGs.6 experience insights (the lived PG reality)
1. The PG day is a multi-tool relay race, not work inside Cosmo. Onboard in Monday, write rules in Logos, document in Monday again, ideate in Atlas, review/QA in Apollo, send in Slack, read knowledge in ACK; Cosmo is a thin slice in the middle. 2. PGs do not trust the product, and distrust is earned by invisible mutation. Board changes under them, no audit trail; destructive actions fire with no confirm/undo. 3. The PG is blind for most of the lifecycle and learns about failure by accident. Build fails (5MB) -> playable just disappears; eng cleared 82 abandoned builds, still no alert reaches PG. 4. Knowledge capture is a manual translation tax paid after every revision. No clean write path to ACK; new knowledge never re-applies to prior ideas. 5. Concept-at-scale is gated by two humans (Shahaf + an asset manager), not the product. 6. Pre-send QA is a real manual checklist run dozens of times/week, unsupported by the product.8 new PG jobs the doc revealed (we had none of these)
1. Ingest/author game knowledge into ACK (onboarding + over time). 2. Verify a build is shippable before sending (replay, zip, naming, triggers, networks). 3. Ad-network rejection recovery (strip Sett AL analytics + rebuild). 4. Match partner-ID to SETT-ID for a delivery (no owner today). 5. Choose whether a Mark-as-Sent counts toward this month's quota. 6. Create an NC against a valid build/Helix core (build_id/core prereq chain). 7. Send into the partner Slack channel from Cosmo + recover when no channel exists. 8. Triage the Apollo PG-review outcome (Approve -> Ready to Send vs Add-a-feedback -> internal fix to auditor).9 jobs sharpened, 19 new entities, 7 resolved unknowns, 9 still-open
(Full detail in the viz. Highlights: my-games sharpened from convenience-filter to hard gate; pre-core sharpened from display-noise to data-integrity; resolved "Rebuild Without Sett AL Analytics" = AppLovin rejection recovery; resolved "where the monthly quota lives" = Game page not Weekly Pools. Still-open: lifecycle-vocab conflict, revision-rate 28% vs 21% gap, who sets quota, taxonomy-ship decision.)---
Where WE can contribute (9 opportunities, ranked)
| # | Opportunity | Addresses | Leverage | Effort | |---|-------------|-----------|----------|--------| | 1 | My-Games default scope (PG portfolio = home, not org board) | C4, C7 | highest | medium | | 2 | Trust-first number contract (labeled counts, visible filters, hover-to-explain) | C2, C3 | highest | medium | | 3 | Time as first-class signal on Ready to Send (aging, SLA bands, going-quiet) | C8 | highest | medium | | 4 | Pre-send QA checklist surface (guided gate for the manual ritual) | C6, C12 | high | medium | | 5 | Confirm-and-undo + plain-language errors for cryptic states | C10 | high | quick-win | | 6 | Consolidated playable timeline + cross-system status display | C1, C5, C12 | high | large | | 7 | Encode unwritten rules (revisions-first weight + revision-type classifier) | C3, C11 | high | medium | | 8 | Batch + derived-value UX (multi-select Send-to-Apollo, derived weekly quota, demand-gap) | C9 | medium | medium | | 9 | In-Cosmo knowledge-write path + save-on-revision prompt | C5, C12 | medium | large |
The pattern: opportunities 2, 5, 6, 7 are all UX expressions of data/integration roots we cannot fix in the backend, but we OWN the display contract, the capture moment, and the empty/failed/stale state design. Build the designed home; the moment eng pipes truth in, it has somewhere to land.