Workstream
The repo already supports a credible suite story: one platform, visible tools, and a built-in trust layer. The missing step is to translate that architecture into a beta sell-sheet that clearly separates what is saleable now, what is included infrastructure, and what is directional proof of the broader business unit.
Why this matters
Without a crisp commercial map, a multi-SKU story reads like ambition rather than a business. Buyers need to know what they are actually buying now.
This is also the workstream that protects the founder's suite ambition while stopping beta from overclaiming readiness or collapsing back into 'just a survey tool'.
Current state
The strategy stance is already suite-first, not point-solution first. The current launch posture points to a visible product suite, while the website, ideas log, and naming work add trust-layer products and Research Architect to complete the workflow story.
The beta-visible rule is now simpler: for brand-name beta customers, the full designed product set can be made available in beta. The open issue is turning that curated beta rule into something operationally clean through entitlements, usage limits, and repeatable packaging.
Research Architect is no longer excluded from curated beta access, but its product architecture is still open and should be described honestly as beta scope rather than mature GA packaging.
Checklist
Foundation
The minimum decisions and assets needed so the launch story is coherent rather than aspirational.
The beta-visible product map is now defined: brand-name beta customers can be given access to the full designed product set, with honest caveats about maturity and a quote expectation.
Private preview
The hardening work required for founder sharing, pilot conversations, and limited buyer-facing use.
Runtime entitlement checks exist conceptually, but plan definition, usage limits, and metering are still underbuilt.
Early selling beta
The repeatable selling and operating layer needed to move beyond one-off founder conversations.
The website and decision log already give us a defensible platform-first story if we stay explicit about maturity and launch scope.
What exists
The product portfolio, strategy context, and founder rationale already support a Research OS or suite posture rather than a single point solution. The launch posture even names the visible product set.
The website architecture, decision register, and ideas log already show how products, trust capabilities, and platform language can be expressed without collapsing back into a single-tool story.
The repo includes shared services, entitlements, and readiness notes that matter for a separate BU with multiple products and controlled commercial access.
What is missing
Open strategic questions
Decisions to be made
Appendix briefs
Source evidence