コホート B: アクティブなオプトイン Beta
背景
Cohort B は、Protocells 上で実際の日次アクティブユーザーに関する経験を得る最初のコホートです。Cohort A (インフラの検証に焦点を当てた非アクティブな Free ユーザー) とは異なり、Cohort B はアクティブなワークフロー、実際の顧客の期待、そして Security と Trust and Safety の準備態勢の必要性を導入します。目標は、Cohort C (上位 1,000) およびそれ以降へとスケールする前に、小規模で厳選された低リスクのアクティブな organization のセットから学ぶことです。
適格基準
Protocells への Organization データ移行に関する Cohort B の適格性は、アクティブでオプトインのベータ organization に焦点を当てています。より大きなコホートへスケールする前に移行のリスクを低減するため、登録、プロファイル、Trust and Safety の各基準を定めます。
| 属性 | 値 |
|---|---|
| コホート名 | Active Opt-In Beta |
| ターゲット規模 | 最大 1,000 organization (最初は厳選した ~10 〜 50 から始め、1,000 までスケール) |
| 可視性 | プライベートのみ |
| エンゲージメントモデル | オプトイン、ガイド付き (human-in-the-loop による審査) |
| 前提条件 | Cohort A の移行が検証済みであること。ユーザーの現在の機能セットをサポートしたまま TLG を org に転送できること |
| 想定されるインパクト | Organizations と Cells の実世界での採用に関するイテレーション。WAL、LWLocks、データベースサイズへのわずかな影響 |
1. 登録とエンゲージメントの基準
1.1 ガイド付きオンボーディングを伴うオプトイン
organization は、厳選された登録プロセスを通じて明示的にオプトインする必要があります。このコホートにはセルフサービスのサインアップはありません。
Tenant Scale、Protocells Steering Committee、Security が、承認前に各候補をレビューします。
顧客は、移行中の短時間の読み取り専用ウィンドウが生じる可能性、転送が一方向である性質、そしてまだ採用していない特定の機能が利用できなくなる可能性を含め、この体験がベータ版である性質を認識する必要があります。
1.2 段階的なランプアップ
- フェーズ 1 (最初の波): 厳選された 10 〜 50 の organization。専任サポートとともに重点的に監視します。
- フェーズ 2 (拡大ベータ): フェーズ 1 での学びから確信が高まるにつれて、最大 1,000 の organization までスケールします。
2. Organization プロファイルの基準
2.1 可視性と namespace 構造
- プライベート namespace のみ。namespace をまたぐ可視性や公開向けの機能領域に関する複雑さを避けるため、パブリック namespace は除外されます。
- organization ごとに単一のルート namespace (単一の TLG から org への転送)。統合が必要な複数の TLG を持つ organization は、後のコホートに延期されます。
- namespace をまたぐ相互作用がないこと。organization のユーザーは、主に単一のルート namespace 内で操作している必要があります。organization の外にある他のルート namespace に大きく貢献しているユーザーは除外されます。
2.2 ライセンスティア
- Free または有料 (Premium または Ultimate) の organization が適格であり、審査レベルは異なります。
- Free の organization: 含めるためのハードルが低くなります。期待値が低く契約上の SLA を持たないアクティブなユーザーで、Organizations の体験全体を検証するのに有用です。
- 有料の organization: ハードルが高くなります。Customer Success の明示的な承認と、ベータプログラムに関する文書化された理解が必要です。機能の使用状況の互換性について審査済みの有料顧客のみを含めます (下記のセクション 3 を参照)。
- トライアルサブスクリプションは対象外。トライアル顧客は過渡的な状態にあり、一方向の移行には適しません。
2.3 ユーザー数とアクティビティレベル
- アクティブなルート namespace: 過去 30 日間に少なくとも 1 名のアクティブユーザーがいること (ログイン、Git、または API のアクティビティによる)。
- 小規模から中規模のユーザー数: ブラストラジアスと移行の複雑さを抑えるため、500 名以下のユーザーを持つ organization をターゲットにします。大規模なエンタープライズ (1,000 名以上のユーザー) は Cohort C または D に延期されます。
- 中程度のアクティビティレベル: データベース時間で上位 1,000 の namespace (Cohort C) を除外します。アクティブだがデータベース負荷が不釣り合いに重くないロングテールの organization をターゲットにします。
3. Trust and Safety とセキュリティのリスク低減基準
Matt Coons および Ruby Nealon との Security と Protocells の同期ディスカッションに基づき、以下の基準によってセキュリティと信頼の観点から Cohort B のリスクを低減します。
3.1 厳選され審査されたリスト
- Cohort B は、移行前に Security Operations と Trust and Safety のリーダーシップによってレビューされた、厳選された organization のリストでなければなりません。
- Matt Coons は次のように述べました。「信頼された org であれば、私はもっと自信を持てるだろう」「厳選されたリストであればリーダーシップの賛同を得やすいかもしれないし、その場合はいくらかのカバレッジのギャップを受け入れることができる」
- 各 organization は、登録前に Trust and Safety の基準に照らして審査されるべきです。
3.2 アカウントの状態と不正使用の履歴
- organization 内に BAN または フラグ付けされたユーザーがいないこと。
- namespace またはそのメンバーに対する不正使用報告の履歴がないこと (レガシーセル上の Omamori データで検証)。
- organization のメンバーに関連付けられた使い捨てメールドメインがないこと。
- アカウント年齢の要件: 一時的またはボット駆動のアカウントを除外するため、organization のオーナーアカウントは少なくとも 6 ヶ月以上前のものであること。
- 過去 90 日間に直近の Trust and Safety の介入がないこと。
3.3 セル上で新規ユーザーのサインアップを許可しない
- Protocell 上で新規ユーザーの登録を許可してはなりません。すべての新規サインアップはレガシーセル上で継続します。これにより、Trust and Safety の完全なカバレッジがないセルに、未知または信頼されていないユーザーが到達するのを防ぎます。
- 移行された organization 内のユーザーは、既存の認証済みセッションを通じてセルにアクセスします。
- organization の管理者は、新規ユーザーを自分の organization に明示的に招待または追加する必要があります。
結果
- Cohort B は小規模でプライベートな低リスクの organization の厳選されたセットに限定されます。これによりブラストラジアスは抑えられますが、実世界での検証の幅も制限されます。
- すべての候補 organization は、登録前に Security Operations と Trust and Safety のリーダーシップによる手動審査が必要であり、運用上のオーバーヘッドが増加します。
- セルフサービスのサインアップは利用できません。すべての登録はガイド付きであり、これによりスケールは制限されますが制御は高まります。
- パブリック namespace と namespace をまたぐ相互作用は除外され、複雑さは後のコホートに延期されます。
- 段階的なランプアップ (最初は 10 〜 50、その後最大 1,000) は段階的に確信を高めますが、これは Cohort B を完全に実行するのにより長い時間がかかることを意味します。
- Protocells 上では新規ユーザーの登録がブロックされるため、Trust and Safety のツールのカバレッジが十分になるまで、すべてのユーザーの増加はレガシーセル上で継続します。
- 有料顧客には Customer Success の明示的な承認が必要であり、調整の依存関係が増加します。
c955a93f)