SignalRashin logo

SignalRashin

English

方法論

各検証は、製品に登録された公式 URL から取得した文書から始まります。Discovery の際、AI サービス候補の公式ページが別ホストへ転送された場合、その候補は登録しません。

各項目の観測は、後から書き換えられない項目アサーションとして保存し、次のいずれかの状態を持ちます:
・確認済み (Verified): 引用した公式の根拠で値を確認した (根拠を引用する)
・不明 (Unknown): 値を確立する根拠が無い (根拠を引用しない)

不明 (Unknown) は「無料」「対応なし」「0 円」と同義ではありません。本レジストリは推測で値を埋めません。根拠の無い項目は Unknown のままにし、公開する Claim は、保存した公式スナップショット内の文言を引用しなければなりません。項目メタデータは現在の項目ポインタから投影したもので、新しい値は新しいアサーションとして記録し、ポインタを切り替えて公開します。適用済みの Review ルール変更は、内部の経路からロールバック (rollback) でき、以前のルーティング版に戻ります。

監視は予定に従い、新しく取得した公式ページの料金と機能の事実を、同じページの前回のスナップショットと比較します。差分があれば製品を変更検知 (Change detected) にし、再検証で、引用した根拠がすべて残っていれば公開状態に戻し、そうでなければ Needs recheck として保留します。検知した変更 (料金または機能の追加・削除) は Watch と照合し、Watch している利用者へ通知します。既知のエンティティについてレジストリ一覧で新しいバージョンを観測した場合は、バージョン変更の Change Event として記録し、Watch と照合します。

Discovery（候補発見）と Verification（検証）は別の段階です。候補として発見しただけでは項目を確認済みにしません。Verification は製品の公式 URL から根拠を取得し、各項目に対応付け、公開前に Claim を検証します。「調査対象の候補サービス」は、その探索実行の Candidate Set に記録され、適合・除外・評価エラーのいずれか一つに評価された製品を指します。対象地域、言語、情報源には限界があり、Candidate Set は世界中のサービスの完全な一覧ではありません。

Search Audit: 検索 API、検索結果ページ、チャットからの探索実行は、Candidate Set を Search Audit として保存します。候補ごとに理由付きの判定を一つ持ち、候補数、結果数、除外数、エラー数と、除外理由ごとの件数を記録します。除外理由は理由ごとに計上するため、理由別件数は重複し得て、その合計は除外された候補数以上になります。評価できないデータを持つ候補は、探索を止めずに評価エラーとして記録します。

検索の解釈と順位: 自然言語の質問は、まず規則に基づいて構造化条件 (引用符で囲んだ必須条件や価格の上限など) とキーワードに解釈します。キーワード検索 (検索 API とチャットのキーワード検索) では、候補をキーワード一致で順位付けし、データベースが全文索引を提供する場合は、同じ候補に対する BM25 順位を Reciprocal Rank Fusion で統合します。この統合は順位を入れ替えることはあっても、キーワード順位に無い候補を追加することはありません。

同一性 (Identity) は、その公式ドメインから取得した根拠でエンティティの公式ドメインが裏付けられているかを記録します。状態 (Status) は製品のライフサイクル状態であり、状態機械による遷移を状態履歴に記録します。鮮度 (Freshness) は、各項目の現在のアサーションを情報源から記録した時刻で、項目ごとに公開します。エンティティページのリスク (Risk) は、確認済みのセキュリティ関連の項目から導きます。

取得の安全性: クローラーは、非公開アドレスに解決される宛先を要求の送信前に拒否し、ウェブページについては robots.txt に従います。文書化された公開 API の決まったホストは robots.txt の確認対象外です。リダイレクト先は、追跡する前にあらためて検証します。

Watch の需要は、製品の優先度 (priority) の区分 (HOT・WARM・COLD) を引き上げます。

収録対象と供給探索: AI Service、Agent Skill、MCP Server、Open-source AI Tool を同じレジストリの第一級 Entity として扱います。探索は毎日自動実行し、source、cursor、取得結果、candidate outcome、取得の失敗を run ledger に保存します。特定地域や現在件数を完成条件にはせず、source の coverage gap は保留中のタスクとして記録し、探索を継続します。

更新ライフサイクル: 候補発見、同一性確認、登録、検証、公開、監視、変更検知、再検証 (公開状態への復帰または再確認待ちの保留)、Watch 照合、通知の順に処理します。公開後も監視が予定に従って公式の情報源を再取得し、その事実を比較します。再検証で公開中の Claim を確認できない場合は製品を Needs recheck として保留し、根拠の無い項目は Unknown のままにします。推測せず Unknown / Needs recheck を保持し、Human Review のタスクは定義済みの例外理由でのみ作成できます。

Evidence と Freshness: 確認済みの各項目は、根拠、その根拠内の位置、アサーションを記録した時刻を保持します。最新の公式スナップショットが再確認間隔より古い製品は、実行ごとの上限の範囲で再取得し、事実が変わっていれば確認済みのままにせず再検証へ送ります。ランキングは広告および商業上の関係から独立しています。

AI 自動運用と Human Review の区別: 候補発見、抽出、検証、監視は人手の工程を挟まずに実行し、根拠の確認を通過した Claim を公開します。Human Review は Entity Merge、Pricing、Capability、Security Warning、Vendor Dispute の自動処理で安全に確定できない例外案件のみを対象とし、通常 Claim の全件人手承認は行いません。異なる Entity Kind をまたいで同一性を統合することはありません。

訂正または異議申立ての方法: /correction の受付フォームから、対象、訂正内容、根拠となる公式 URL、連絡先を送信してください。受付済み (Received) の状態で内部のレビュー待ち行列に保存します。

公開仕様（正本要件）

以下は SignalRashin が従う正本要件の原文です。掲載は実装完了を意味しません。実装状況は独立した本番受入検査で判定します。

原文中の旧リリース表示名だけは［旧リリース表示名］に置き換えて掲載し、該当する要件にはその旨を付記しています。

1.1 一文定義
  • 世界中のAIサービス、Agent Skill、MCP Serverを継続的に発見・正規化・検証し、「何が存在し、何ができ、何が変わり、自分の条件なら何が候補になるか」を根拠付きで検索・比較・監視できるAI Ecosystem Intelligence Registry。
1.2 原点となるユーザー課題
  • ChatGPT、Perplexity、Claude等へAIサービスを尋ねると、5件、10件、20件の推薦は得られる。しかしユーザーには次が見えない。
  • AIが実際に何サービスを調べたのか
  • より広い候補母集団がどのようなものだったか
  • 他に候補が存在するのか
  • 何が、なぜ除外されたのか
  • 公式情報を確認したのか
  • 情報がいつ確認され、現在も有効なのか
  • 地域・言語・情報源の探索にどのような偏りがあるのか
  • Google検索中心の時代には、複数ページを見て検索空間を自分の目で探索できた。生成AIは答えを便利に圧縮する一方で、その探索空間を隠す。ユーザーは「ほかには？」「欧州系は？」「日本語対応は？」「最近出たものは？」と何度も根掘り葉掘り質問しなければならない。それでも、十分に調べた回答かは分からない。
  • 本サービスが解決するのは、単なる推薦精度ではなく、AIによって圧縮された検索過程の不可視性である。
1.3 価値の中心は「監査可能な市場探索」
  • 本サービスは「AIが良いツールを選んでくれるサイト」ではない。
  • AIサービス市場を、人間が検証可能な形で観測する基盤
  • である。
  • ユーザーは最低限、次を自分で確認できなければならない。
  • この質問に対して候補として何件を確認したか
  • その候補はRegistryのどの探索範囲から形成されたか
  • なぜ各結果が条件に合うのか
  • なぜ他の候補が除外されたのか
  • 各重要情報の根拠と鮮度は何か
  • Registryが把握していない可能性や探索上の限界は何か
1.4 三つの中心ユースケース
  • 導入候補の網羅的確認: 自社でAI導入を検討するとき、世界中の候補をできるだけ漏れなくチェックしたい。
  • 市場・業務可能性の把握: ある業務を自動化できるAIが、現在どれくらい存在するかを確認したい。
  • 継続監視: 現在使っているAIスタックに代わる新サービスや、価格・機能・提供状態の変更を定期的に知りたい。
1.5 五つのプロダクト柱
  • | DISCOVER | 世界に何が存在するかを継続的に発見する |
  • | VERIFY | 実在・運営主体・稼働状態・主張の根拠・鮮度・リスクシグナルを確認する |
  • | COMPARE | 目的と条件に合うサービスを比較する |
  • | WATCH | 代替候補、価格、機能、連携、言語、規約、終了等を監視する |
  • | AUDIT | 何を調べ、何を根拠に採用・除外したかを利用者が検証できるようにする |
  • VERIFY + WATCH + AUDITが、一般的なAI Tool Directoryから大きく離れる差別化領域である。
1.6 非交渉原則
  • 一覧件数を価値の中心にしない。 件数ではなく、Entity、Evidence、Change、探索過程の品質を資産とする。
  • 推薦だけを返さない。 Candidate Setと絞り込み過程を可視化する。
  • 世界全体を見たと誤認させない。 網羅を目指すが、未知の母集団に対する100%完全性を主張しない。
  • 重要な事実には根拠を持たせる。 Evidenceを削りすぎて通常の比較DBにしない。
  • 変更履歴の記録を初日から始める。 過去データは後から回収できない。
  • 公式・有料をランキング優遇と同一視しない。 Identity Verification、Data Verification、品質評価、検索順位、商業契約を分離する。
  • 危険性をAIの印象で断定しない。 客観的なStatus/Risk Signalと理由を表示する。
  • AI中心で運用する。 人手を通常フローの前提にせず、例外・争議・高リスク・低確信へ限定する。
  • DiscoveryとVerificationを分離する。 第三者情報は候補発見に使えても、重要な主張は原則として公式情報へ戻って確認する。
  • MVPを狭めてもコアの垂直断面を残す。 Registry、Evidence、候補母集団、監査、Change記録、Watchの初期価値を切り落とさない。
  • 不明なら推測せずUnknownにする。 Unknownは欠陥や例外ではなく、根拠不足を正しく表す通常状態である。登録・公開を急ぐための強制推測を禁止する。
  • Entity Kindを混同しない。 AI Service、Agent Skill、MCP Serverを同じProductとして統合せず、型をまたぐEntity Mergeを禁止する。
  • Verificationで外部コードやToolを実行しない。 SkillのInstall、Script実行、MCP Tool呼び出しは通常の収録確認に不要であり、Manifest、Repository、Documentation、署名・Package metadataをEvidenceとして確認する。
  • Human Reviewを自動化改善へ戻す。 人間の判断を一回限りの運用コストで終わらせず、評価データ、ルール、Prompt、Model Routingの改善へ還流させ、同種例外の再発率を下げる。
2.1 運用前提
  • CONFIRMED: Registry運用は、基本的にAIによる自動チェックで行う。
  • 人が全サービスを定期確認するモデルは前提にしない。
  • 発見、正規化、項目抽出、変更検知、再分類、検索インデックス更新、定期再確認の大部分を自動化対象とする。
  • 人手は、異議申立て、重大リスク、AIの低確信、重複統合の難例、契約・法務に関わる重要変更などへ絞る方向とする。
  • AI抽出結果を無条件にDBへ直接公開しない。Validation Gateを設ける。
  • 人間が通常Claimを全件承認するL1運用は採用しない。Human Reviewは自動検証で安全に確定できない例外だけに限定する。
  • Human Reviewへ送らない低確信項目は、現在値を維持してNEEDS_RECHECKにするか、誤更新リスクが高い場合はUNKNOWNへ落とす。
  • Human Reviewの各判断は、入力Evidence、適用ルール、最終Labelとともに保存し、自動化率の継続改善へ利用する。
2.2 検索結果の基本表示
  • CONFIRMED: 通常表示は次の形を基本とする。
  • 20は条件に一致した検索結果数。
  • 154は当該検索に対して評価対象となったSearch Candidate Set。
  • 154は世界中に存在するサービス総数ではない。
  • 数字は消さず、世界全体の完全性と誤認させない注記を「もっと見る」内に表示する。
  • 推奨注記:
  • 当Registryが現在発見・収録している範囲から算出しています。世界中の全サービスを保証する数字ではありません。
2.3 「もっと見る」の役割
  • CONFIRMED: 通常画面を複雑にせず、監査したい利用者が詳細を展開できるようにする。
  • Candidate Set総数
  • 条件一致数
  • 公式情報確認済み数
  • Freshness SLA内の数
  • 情報不足・要確認数
  • 地域・言語・情報源の探索範囲
  • 最終探索時刻
  • 除外理由別の件数
  • 除外理由例:
  • 複数理由に該当する場合があるため、合計方法と重複表示ルールは実装時に定義する。
2.4 多軸分類とAI検索
  • CONFIRMED: 1サービスを1カテゴリへ固定しない。AIが多角的に検索できる内部表現を持つ。
  • 用途・業務目的
  • Capability
  • 対象部署
  • 入力・出力
  • 自動化レベル
  • Interface
  • ノーコード性・必要スキル
  • Integration
  • 対応言語・地域
  • Pricing
  • Deployment
  • Security
  • 商用利用可否
  • 対象ユーザー
  • 「画像」「動画」「文章」「自動化」のようなカテゴリは、人間向けの入口・ナビゲーションとしては利用できるが、データ構造の正本にはしない。
2.5 自然言語検索
  • CONFIRMED: ユーザーに毎回細かな条件入力や追加質問を強制しない。
  • Zoom会議を日本語でまとめてNotionにタスクを自動追加したい。月30ドル以下。
  • 内部で、meeting automation、transcription、Japanese、task extraction、Notion、no-code、budget等へ分解する。不明な条件はUnknownのまま検索を継続する。
  • 内部検索表現には以下を含める。
  • Canonical Capability
  • Synonym
  • 公式用語
  • 一般利用者の表現・口語
  • 業務表現
  • 検索キーワード
  • Semantic Embedding
  • 構造化属性
  • キーワードだけにもEmbeddingだけにも依存せず、構造化条件・語彙・意味類似性を組み合わせる。
2.6 Evidence
  • CONFIRMED: Evidenceは中核機能である。
  • 概念例:
  • 重要情報は「値」だけでなく、出典、観測日時、適用時点、出典種別、確信度を持つ。
2.7 状態・疑わしさの表示
  • CONFIRMED: 更新停止、実体不明、危険URL等を自動チェックし、差別化要素にする。
  • ただし「詐欺」「Fraud」等をAIのみで断定しない。状態とリスクを分離し、根拠となる客観シグナルを示す。
  • 推奨表示:
  • Identity: Verified / Unverified
  • Status: Active / Stale / Unavailable / Unknown
  • Evidence: High / Medium / Low
  • Freshness: 確認時刻または期限超過
  • Risk: None observed / Caution / Security warning
  • Risk Signal候補:
  • Malware / phishing情報
  • SSL/TLS異常
  • 連続する404・サービス本体停止
  • 公式Productページ・Pricing・Docsの消失
  • 公式ドメインを確認できない
  • 不自然な大量Redirect・突然の別ドメイン誘導
  • 運営主体とドメイン情報の不整合
  • 公式更新が長期間確認できない
  • Domain ageは単独の警告根拠にしない。新しいドメインは事実として保持し、他シグナルとの組合せにのみ利用する。
2.8 My Stack / Watch Alternatives
  • CONFIRMED: 現在利用中のサービスを登録し、新しい代替候補を定期監視できる機能は重要である。
  • 通知候補:
  • 新しい代替サービス
  • 値上げ・値下げ・Plan変更
  • 機能追加・削除
  • Integration追加・削除
  • 対応言語・地域変更
  • 規約変更
  • サービス終了・障害・Security warning
  • Watch Alternativesは継続利用・有料化の中核候補とする。
2.9 ログイン
  • ADOPTED: 検索開始時にはログインを要求しない。
  • 未ログイン: 検索、基本結果、Product閲覧、基本比較、Candidate Set表示
  • アカウント要求: 保存、検索履歴、My Stack、Watch、通知、詳細比較等を使う時点
  • 価値を体験する前に会員登録を要求しない。
2.10 Unknownを通常状態として扱う
  • CONFIRMED: 根拠が不足・矛盾・不鮮明である場合、システムは値を推測せず、明示的にUNKNOWNを返す。
  • 空欄、未処理、取得失敗、Not Applicable、否定値とUnknownを混同しない。
  • FALSEは公式Evidence等により非対応と確認できた状態、UNKNOWNは対応有無を確認できない状態とする。
  • Entity ResolutionはSAME_PRODUCT / NEW_PRODUCT / UNKNOWNを返せる。
  • 各Claimは少なくともvalue / verification_status / confidence / evidence / last_checked_atを持ち、value = UNKNOWNを許容する。
  • Unknownが含まれていても、最低公開基準を満たすProductは公開できる。分からないことを見せること自体を信頼性の一部とする。
  • Search / CompareではUnknownを条件不一致と断定せず、必須条件への影響と情報不足を区別して表示する。
  • Search需要またはWatch需要が高いUnknownはRegistry Quality Priorityを上げ、優先的に再確認する。
  • 人手不足を理由に推測値を入力しない。Human Reviewでも判断不能ならAllowed DecisionとしてUNKNOWNを選べる。
3.1 Registryの基本データモデル
  • ADOPTED: 基本構造は次とする。
  • Publisher / Company: 運営企業・団体・個人Publisher
  • Registry Entity: 検索・比較・監視の共通単位。必ずentity_kindを持つ
  • AI_SERVICE Product: 利用者が契約・利用する製品。従来のProductは互換性のためこの型を指す
  • AGENT_SKILL: Agentへ手順・能力を追加する配布可能なSkill package。Package identifierとManifestをIdentityの主軸とする
  • MCP_SERVER: Model Context Protocolを介してTool / Resource / Promptを提供するServer。Server identifier、Package、Endpoint、TransportをIdentityの主軸とする
  • Capability: Entityができること。検索マッチングの主要単位
  • Offering: AI ServiceのPlan、価格、地域、提供形態、Enterprise条件等
  • Change Event: 機能、価格、連携、言語、規約、名称、所有、終了等の変化
  • Notion、Canva、Adobe、Google、MicrosoftのようにAIが製品の一部である場合も、ProductとCapabilityを分離することで扱う。
Product.service_summary / Product.service_detail
  • CONFIRMED: Productは構造化属性とは別に、利用者向けのサービス概要とサービス詳細を持つ。
  • | service_summary | 検索結果、一覧、比較の短い説明 | 1〜3文を目安に、何のサービスか、主な対象者、主要な価値・用途を簡潔に説明する |
  • | service_detail | Product詳細ページ | 主要機能、基本的な使い方・Workflow、対象ユーザー、代表Use Case、公式に確認できる強み・制約を詳しく説明する |
  • 生成ルール:
  • 公式Homepage、Features、Documentation、Help Center等の公式SourceだけをGroundingとしてAI生成する。
  • 公式情報で確認できない事実を、一般知識、第三者レビュー、類似Product、モデルの推測で補完しない。
  • 情報不足部分は省略するかUNKNOWNとして扱い、断定的なMarketing表現へ変換しない。
  • service_summaryとservice_detailはCapability、Pricing、Language、Integration等の構造化Claimの代替ではない。構造化Claimと矛盾してはならない。
  • 各生成物に、参照したEvidence ID / Source URL、生成日時、生成器・Prompt version、対象Source snapshotを紐付ける。
  • Vendor提供文をそのまま中立的なRegistry説明として扱わない。Vendor Claimであることを区別し、公式Evidenceに基づき中立化する。
  • 再生成ルール:
  • 初回Verificationで説明に必要な公式Evidenceが揃ったときに生成する。
  • 主要Capability、対象ユーザー、主要Workflow、提供形態、重要な制約、Availabilityに意味のあるChange Eventが確定した場合に再生成候補とする。
  • 価格変更等が説明文に含まれる場合は、影響する文だけを再生成・再検証する。
  • ページの装飾や文言が変わっただけでは再生成しない。Semantic Diffが説明内容へ影響すると判定された場合だけ行う。
  • 再生成後は前版との差分を保存し、構造化Claimおよび現行Evidenceとの整合性Validationを通過してから公開する。
  • 再生成の根拠が弱い場合は現行説明を維持してNEEDS_RECHECKとし、古い断定が危険な場合は該当文を削除またはUNKNOWNへ落とす。
3.2 AI Ecosystem Universe
  • ADOPTED: 対象範囲は少なくとも次のTierに分ける。
  • | A | AIが中心価値のエンドユーザー製品 | ON |
  • | B | 既存SaaSだがAI機能が重要な製品 | ON |
  • | C | AI Automation / Agent / No-code製品 | ON |
  • | D | API、モデル、ML基盤、開発者専用ツール | 原則OFFまたは低優先度 |
  • AI Product UniverseとDeveloper Extension Universeを区別する。非エンジニアの業務利用を標準検索の中心としてAI_SERVICEをDefault ONにする。一方、AGENT_SKILLとMCP_SERVERはRegistryの第一級収録対象とし、標準検索ではDefault OFF、明示的なKind filterまたは開発者向け検索ScopeでONにする。API、基盤、モデル等のTier D全般を無制限に収録する判断とは分ける。
3.3 最新情報はChange Eventで持つ
  • ADOPTED: SaaSには明示的なバージョン番号がない場合が多いため、latest_versionを中核にしない。
  • Change Event例:
  • launch
  • feature_added / feature_removed
  • pricing_changed / plan_changed
  • model_changed
  • integration_added / integration_removed
  • language_added / language_removed
  • region_changed
  • terms_changed
  • renamed
  • acquired
  • sunset
  • 公式Versionがある場合のみChange Eventの属性として保存する。
3.4 Change Historyは「表示を後回し、記録は初日」
  • ADOPTED: 高度な履歴画面は後回しにできるが、SnapshotとChange Eventの記録はMVP開始時から行う。
  • 理由:
  • 過去の価格・機能・連携状態は後から取得できない。
  • 長期的な差別化資産になる。
  • Watchと代替検知の基盤になる。
3.5 Evidenceの優先度
  • ADOPTED: Evidenceを削除せず、運用コストに応じて層別化する。
Critical Evidence
  • 検索条件や導入・契約判断を直接左右する項目。優先確認する。
  • Pricing
  • Availability
  • Language
  • Integration
  • Commercial use
  • Plan restriction
  • Deployment
Functional Evidence
  • 原則として公式Features / Docs等から抽出する。
  • Capability
  • Automation behavior
  • Input / Output
Descriptive Metadata
  • AI生成を許容するが、事実と推定を区別する。v0.3では公式SourceをGroundingとし、確認できない内容を推測で補わない。
  • 一言説明（service_summary）
  • service_detail
  • Keywords / Synonyms
  • Department
  • Use Case
3.6 項目単位のFreshness
  • ADOPTED: Product全体の「最終更新日」だけでは不十分。項目・Claim単位で確認日時と期限を持つ。
  • Pricing checked
  • Availability checked
  • Language checked
  • Integrations checked
  • Features checked
  • Terms checked
  • Security signal checked
  • Freshness SLAの具体値は運用実験で決める。
3.7 DiscoveryとVerificationの分離
  • ADOPTED: 情報源の役割を分ける。
Discoveryに利用できる情報源
  • AI Directory
  • Product Hunt等のローンチサイト
  • 検索エンジン
  • ニュース、プレスリリース、SNS
  • GitHub / App Store
  • ユーザー・Vendor投稿
  • 他の比較サイト・レビューサイト
Verificationの優先情報源
  • Vendor Verified Submission
  • 公式サイト
  • 公式Pricing
  • 公式Documentation
  • 公式Changelog / RSS / API
  • 公式Status
  • 公式GitHub / App Store
  • 第三者Directoryやレビューだけを根拠に重要Claimを確定しない。
3.8 Update Priority Engine
  • ADOPTED: 全Productを同頻度で再確認せず、AIが更新優先度を算出する。
  • CONFIRMED: v0.3ではこれをRegistry Quality Priorityとして明示し、需要駆動でVerificationとFreshnessの資源を配分する。
  • 入力候補:
  • Watch数
  • Product名・Company名の検索頻度
  • 検索結果への出現頻度
  • Comparison数、保存数、My Stack登録数
  • 過去の変更頻度
  • 前回確認からの経過時間
  • RSS、Sitemap、ETag、Last-Modified、Changelog等の変更シグナル
  • Productの利用・市場上の重要度
  • Evidence Confidenceの低下
  • Critical Evidenceの期限超過
  • ユーザー・Vendorからの訂正報告
  • セキュリティ・停止シグナル
  • 原則:
  • すべてを同じ頻度で見に行くのではなく、見る必要が高いものから見に行く。
  • 特に、Search需要とWatch需要の増加はVerification Priorityを直接引き上げる。 Unknown、期限超過、低ConfidenceのProductに需要が集中した場合は、新規収録件数を増やすより先に、そのProductのCritical Claimと説明を再確認する。
HOT / WARM / COLD
  • | HOT | Search / Watch / Compare需要が高い、直近変更が多い、重要Change・Risk Signalがある、需要の高いClaimがUnknownまたはStale | 軽量チェックと必要なDeep Verificationを最優先。Critical Claimの短いFreshness SLAを適用 |
  • | WARM | 継続的な利用需要がある標準Product、または中程度の変更履歴・期限超過がある | 標準頻度で軽量監視し、SignalまたはSLA到来時に深層確認 |
  • | COLD | Long tail、需要と変更が少ない、長期間安定している | 低頻度の軽量確認を基本とし、需要・変更Signal発生時に昇格 |
  • Tierは固定属性ではない。次の閉ループで随時再計算する。
  • 具体的なScore式、閾値、各Tierの時間間隔はMVPのコスト・品質実験で決める。Priority TierをProductの人気ランキングとして利用者へ誤表示しない。
3.9 更新方式
  • ADOPTED: 深いブラウザ取得を毎回行わない。
  • API、RSS、Sitemap、ETag、Last-Modified、Changelog等の軽量シグナルを確認
  • 変更可能性が高いProduct・ページだけ深く取得
  • Claimを再抽出
  • 前回Snapshotと比較
  • Change Eventを生成
  • Capability、Keywords、Embedding、検索Indexを必要に応じて更新
  • 高頻度対象はWatch対象、主要Product、直近で変更が多いProduct。Long tailは低頻度とする。v0.3では検索・比較需要が高いProductも高頻度対象へ明示的に加える。COLDでも需要Signal、Vendor dispute、Security Signal、サービス停止兆候が入れば即時に昇格できる。
3.10 公式確認とランキングの分離
  • ADOPTED: 「公式」を一つのバッジや優遇にまとめない。
  • Identity Verified: 管理主体の身元を確認した
  • Data Verified: 特定Claimを公式情報で確認した
  • Product Quality / Popularity: 別評価
  • Organic Ranking: 検索関連性・条件適合等で決定
  • Commercial Relationship: 別表示
  • 公式登録や有料契約だけでOrganic順位を上げない。有料掲載を行う場合はSponsoredとして明確に分離する。
3.11 Correction / Dispute Flow
  • ADOPTED: 自動システムの誤りを前提に、次の導線を設ける。
  • Report incorrect information
  • Report missing product
  • Vendor correction request
  • Vendor identity verification
  • 修正・申立て・判定の履歴保存
  • Vendor申告は即時に事実化せず、Vendor Claim → Evidence確認 → Publishedを原則とする。MVPで固定の対応時間SLAは約束しない。
3.12 Search Quality Benchmark
  • ADOPTED: 検索品質を感覚で評価しない。
  • 代表的な100問程度から始め、各Queryに次を蓄積する。
  • 必ずCandidate Setへ入るべきProduct
  • 検索結果へ出るべきProduct
  • 上位に来るべきProduct
  • 出てはいけないProduct
  • 必須条件と除外理由
  • 日本語の議事録AI
  • Notion代替
  • HubSpot連携の営業AI
  • 画像から動画を作るAI
  • PDFを読み込んで調査するAI
  • 営業メール自動化
  • Canvaに近いAIデザイン
  • 海外向けSNS動画制作
  • Ontology、抽出器、Embedding、Rankingの変更ごとに回帰評価する。
3.13 Search Confidence
  • ADOPTED: 「もっと見る」のクリック率だけを監査価値のKPIにしない。
  • 重視する問い:
  • 利用者は、利用可能な候補を十分に確認できたと感じたか。
  • 評価候補:
  • Search Confidenceの自己評価
  • 同一目的で「他には？」相当の再検索を繰り返したか
  • 外部検索へ同じQueryを探し直しに行ったか
  • Compare、保存、My Stack、Watchへ進んだか
  • 重要な候補漏れ・誤った除外があったか
3.14 Methodology Page
  • ADOPTED: Transparencyを価値にする以上、自サービスの方法も公開する。
  • 最低限説明する内容:
  • サービス発見方法
  • DiscoveryとVerificationの違い
  • 「候補として確認したサービス」の定義
  • 探索地域・言語・情報源の限界
  • EvidenceとFreshnessの考え方
  • Rankingと広告・商業契約の分離
  • 自動抽出・自動判定の限界
  • 訂正・異議申立て方法
3.15 Public Layer / Intelligence Layer
  • ADOPTED: 公開Webの情報を完全にコピー不能にはできない。公開範囲とRegistry内部資産を分離する。
Public Layer
  • Product名、公式URL
  • 主用途、基本Capability
  • 概算料金、対応言語
  • 簡易Status、確認日
  • 基本検索・比較
Intelligence Layer
  • 詳細Evidence
  • Change History
  • 内部Ontology、検索辞書
  • 詳細Capability・類似Product Graph
  • My Stack / Watch
  • 高度比較・市場分析・大量検索
  • Export / API
  • 内部Ontologyや検索キーワードをHTMLへ全露出せず、検索はサーバー側で行う。API認証、Rate Limit、bot制御、scraping検知を組み合わせる。
3.16 自社クローラーの安全設計
  • ADOPTED: 外部コンテンツは命令ではなくUntrusted Dataとして扱う。
  • 外部ページ内の指示を実行しない
  • AI抽出と公開・権限処理を分離
  • 静的HTTP取得を原則とし、JavaScript実行は必要時のみ隔離環境で行う
  • Private IP / localhostへのアクセス禁止
  • Redirect、File size、Content-Type、Timeoutの制限
  • 取得物をプログラムとして実行しない
  • robots.txtおよびサイト利用条件を尊重する
  • WebからDBへ直接更新しない
3.17 Entity Resolution
  • ADOPTED: Company名、Product名、旧称、ドメイン、ローンチ時名称等による重複を前提とする。
  • AI・ルールで同一候補と確信度を算出
  • 自動統合と統合候補を区別
  • False Mergeの方が深刻な場合は保守的に扱う
  • 改名、買収、ドメイン移行の履歴を保持
  • 難例のみ人手レビューへ送る
  • 完全自動化はMVP要件にしない。
3.18 1 ProductのLifecycle
  • CONFIRMED: Productは次のLifecycleを正本とする。
  • DISCOVER → IDENTIFY → REGISTER → VERIFY → PUBLISH → MONITOR → DETECT CHANGE → RE-VERIFY → UPDATE → WATCH MATCH → NOTIFY
  • これは論理順序であり、変化がなければMONITORで終了し、低確信・矛盾・リスク等があればUNKNOWN、NEEDS_RECHECK、または例外的なHUMAN_REVIEW_REQUIREDへ分岐する。すべてのProductが毎回全工程を通るわけではない。
3.18.1 DISCOVER
  • Search、Directory、Launch site、News / Press release、Vendor registration、User report、Changelog、既存ProductのIntegration・競合情報等から新しいProduct候補を発見する。この段階ではRegistry本体へ公開しない。
  • Candidateの最小情報:
3.18.2 IDENTIFY
  • 既存Company / Productとの重複・別名・改名・Domain移行を確認する。
  • Canonical domain、Redirect先、Company、Product名等の決定論的照合
  • 未解決の場合だけ、Entity Resolution workerによるEvidence付き判定
  • 結果はSAME_PRODUCT / NEW_PRODUCT / UNKNOWN
  • SAME_PRODUCT: 既存ProductのSourceまたはChange候補として扱う。
  • NEW_PRODUCT: REGISTERへ進む。
  • UNKNOWN: Candidateを保留し、強制Mergeも新規確定もしない。Search / Watch需要が高い場合はPriorityを上げて再確認する。
3.18.3 REGISTER
  • NEW_PRODUCTと確認できた場合、未完成のProduct skeletonを作る。
  • Pricing、Language、Integration、Commercial use等の未確認属性も空欄ではなくUNKNOWNから開始する。
3.18.4 VERIFY
  • 公式Homepage、Pricing、Features、Documentation、Help Center、Changelog、Status、Terms、Security等を特定し、安全に取得してClaimを抽出・検証する。
  • LLM出力を直接Product DBへ公開しない。
  • Source URLだけでなく、該当Sectionと抽出Evidenceが実在することを確認する。
  • 公式Sourceで確認できない場合はUNKNOWNとする。
  • Second CheckでもCritical Claimの矛盾が解消しない、高リスク公開判断が必要等の例外だけHuman Reviewへ送る。
  • service_summary / service_detailは、必要な公式Evidenceが揃い、構造化Claimとの整合性を確認してから生成する。
3.18.5 PUBLISH
  • 最低公開基準を満たしたProductを検索対象へ公開する。全Fieldが埋まっている必要はない。
  • Unknown、Evidence Confidence、Freshnessを隠さず、Product詳細から確認できるようにする。公開基準と必須ClaimはMVP技術設計で定義する。
3.18.6 MONITOR
  • Registry Quality Priorityに基づき、まず低コストな変更Signalだけを確認する。
  • HTTP status
  • ETag / Last-Modified
  • Page / section hash
  • RSS / Changelog
  • Sitemap
  • Redirect先
  • 公式API等の更新情報
  • 変化がなければlast_light_check_atを更新して終了する。意味のある変化の可能性がある場合だけDeep Verification Queueへ送る。
3.18.7 DETECT CHANGE
  • 前回Snapshotと今回Snapshotを比較し、変更されたSectionとSemantic Diffだけを抽出する。全文を毎回モデルへ渡さず、装飾・順序・Cookie banner等のNoiseを除外する。
  • 出力例:
  • 意味のある変更がなければChange Eventを生成しない。
3.18.8 RE-VERIFY
  • 変更種別ごとの公式Sourceへ戻って確認する。検出元ページだけで足りない場合は別の公式SourceでCross-checkする。
  • Pricing change → 公式Pricing、Billing Help
  • Integration change → 公式Docs、Integration directory
  • Language change → 公式Help、対応言語一覧
  • Terms change → 公式Termsと発効日
  • Security / Availability → 公式Status、HTTP履歴、信頼できるSecurity Source
  • 検証不能なら誤更新せず、現行値を維持してNEEDS_RECHECKまたはUNKNOWNとする。
3.18.9 UPDATE
  • Validation Gateを通過した変更だけをCurrent Registryへ反映し、同時にChange Eventを保存する。
  • 変更がCapability、対象者、Workflow、重要制約等へ影響する場合は、service_summary / service_detail、Keywords、Synonyms、Embedding、Search Indexの再生成・更新候補を作る。再生成物も個別にValidationする。
3.18.10 WATCH MATCH
  • 確定したChange Eventまたは新Productを、次へ照合する。
  • Productを直接Watchしている利用者
  • My Stackに登録している利用者
  • 保存済み必須条件を新たに満たす利用者
  • 現在利用中ProductのAlternativeをWatchしている利用者
  • 全Product総当たりではなく、Hard Filter、Capability overlap、Semantic similarity等で近傍Candidateを作る。
3.18.11 NOTIFY
  • Event significance、利用者条件、通知設定、Evidence Confidence、重複通知を評価して通知する。
  • High: 値上げ、終了、Security warning、重要な代替、必須Integrationの追加・削除
  • Medium: 主要Capability、Language、Regionの変更
  • Low: 軽微な文言・UI変更等。原則として即時通知しない
  • 通知には、何が変わったか、利用者に関係する理由、確認日時、Evidenceへの導線を含める。未確定Changeを確定事項として通知しない。
3.18.12 State Machine
  • Lifecycle stageと永続Stateを混同しない。最低限、次の状態を持つ。
  • | Candidate | DISCOVERED | DISCOVER直後。IDENTIFYへ |
  • | Candidate | IDENTIFYING | 重複判定中 |
  • | Candidate | IDENTITY_UNKNOWN | 同一性不明。Priorityに応じ再確認 |
  • | Candidate | DUPLICATE | 既存Productへ関連付けて終了 |
  • | Candidate | NEW_IDENTIFIED | REGISTERへ |
  • | Product | VERIFYING | 初回Verification中 |
  • | Product | ACTIVE | 最低公開基準を満たし公開中。MONITORへ |
  • | Product | ACTIVE_PARTIAL | 公開可能だが一部ClaimがUnknown / Stale |
  • | Product | CHANGE_DETECTED | 意味のある変更候補あり。RE-VERIFYへ |
  • | Product | REVERIFYING | 変更を再確認中 |
  • | Product | NEEDS_RECHECK | 自動確認不能だが、直ちにHuman Reviewを要しない |
  • | Product | HUMAN_REVIEW_REQUIRED | 例外条件を満たしReview Packet作成済み |
  • | Product | UNAVAILABLE | 現在利用不能と確認。監視継続の可否を別途保持 |
  • | Product | SUNSET | 終了が確認済み。履歴とEvidenceは保持 |
  • | Claim | UNKNOWN | 根拠不足・矛盾・未確認 |
  • | Claim | PROPOSED | 新しい抽出値。未公開 |
  • | Claim | VERIFIED | Validationを通過した公開値 |
  • | Claim | STALE | Freshness SLA超過。過去値と期限超過を区別表示 |
  • | Claim | DISPUTED | Vendor / User異議申立て中 |
  • 主要遷移:
  • Human DecisionがUNKNOWNの場合、対象ClaimをUNKNOWNにし、Productは公開基準に応じてACTIVE_PARTIALまたはNEEDS_RECHECKへ遷移する。
3.19 Human Review PacketとReview UX
  • CONFIRMED: Human Reviewは通常工程ではなく、自動処理で安全に確定できない例外のためのEscalationである。レビュー担当者へ「調べてください」とだけ渡してはならない。システムが、何が問題で、どのSourceのどこを見て、どの定義で、何を決めるかまで準備する。
3.19.1 Human Reviewへ送る条件
  • 代表条件:
  • 決定論的照合とSecond Check後も、False Mergeリスクの高いEntity Resolutionが解けない
  • 複数の公式SourceがCritical Claimについて矛盾し、自動ルールで解決できない
  • Security warning、契約・法務、重大なAvailability等、誤公開の損失が高い
  • Vendor dispute / correction requestで、現行EvidenceとVendor提出Evidenceが競合する
  • 自動Validationの同一例外が繰り返され、現在のRule / Promptでは安全に処理できない
  • 単なる低Confidence、取得失敗、Long-tailの情報不足は原則としてUNKNOWN / NEEDS_RECHECKへ置き、直ちに人へ送らない。Review Queueには優先度、影響範囲、期限を付け、月間上限を監視する。
3.19.2 Formal Human Review Packet
  • すべてのHuman Review Taskは最低限、次のPacketを持つ。
  • | 1 | Product | Product ID、名称、Company、公式Domain、現在Status |
  • | 2 | Review reason | なぜ自動確定できず、人間判断が必要か |
  • | 3 | Current value | 現在公開中のRegistry値とVerification / Freshness |
  • | 4 | Proposed value | 新しい抽出値、変更候補、Vendor Claim等 |
  • | 5 | Confidence | 各自動CheckのConfidenceと不一致状況。単一の総合値だけにしない |
  • | 6 | Relevant source URLs | 確認対象となる公式・外部Source URL |
  • | 7 | Exact relevant sections | Page heading、Plan名、Table row、Paragraph、Anchor等、見るべき正確な位置 |
  • | 8 | Extracted evidence | 前後文脈を含む必要最小限の抽出Evidenceと取得日時 |
  • | 9 | Diff / conflict | 旧・新、Source A・B、Registry・Vendor申告の差分または矛盾 |
  • | 10 | Decision rule | 適用する定義、Threshold、含める・除外する条件 |
  • | 11 | Allowed decisions | レビュー担当者が選択できる列挙済みDecision。必ずUNKNOWN相当を含める |
  • 運用上、review_packet_id、Review type、Priority、影響するWatch / Search件数、作成日時、使用したRule / Prompt / Model version、関連Evidence IDも保存する。
3.19.3 共通UX原則
  • 1画面でCurrent / Proposed / Evidence / Diff / Decision Ruleを比較できる。
  • 各Sourceは該当AnchorまたはSectionへDeep linkし、Heading、Table row、強調表示等で見る場所を示す。
  • ReviewerがWeb全体をゼロから調査し直す前提にしない。
  • 「怪しいと思うか」「同じに見えるか」等の主観質問を避け、定義に沿う具体的なDecisionを求める。
  • Source取得日時とSnapshotを示し、ページ更新後も判断時点のEvidenceを再現できる。
  • Decision送信前に、選択が現在値、公開表示、Change Event、Watch通知へ与える影響を短く表示する。
  • UNKNOWNを正当なDecisionとして常に用意し、無理な二択を強制しない。
3.19.4 Entity Merge Review
  • Reviewerが確認するもの: Product A / Bの公式Domain、Redirect chain、Company、Logo、公式説明、旧称、買収・改名Evidence、共通・相違点、自動判定理由と疑問点。
  • 見る場所: 各公式HomepageのProduct名・Footer運営主体、About / Legal、Redirect最終URL、改名・買収Announcementの該当Section。
  • Decision rule: 同一の利用契約・Product identityの継続かを判定する。機能が似ているだけ、同じCompanyであるだけ、White-labelの可能性だけではMergeしない。False Mergeを保守的に避ける。
  • Allowed decisions: SAME_PRODUCT / DIFFERENT_PRODUCTS / RELATED_BUT_DISTINCT / UNKNOWN
3.19.5 Pricing Review
  • Reviewerが確認するもの: Current Registry値、新しいPlan / 金額 / 通貨 / 税 / Billing周期 / Seat条件 / 年払い換算 / Region条件、旧・新Evidence、公式PricingとBilling Helpの矛盾。
  • 見る場所: 公式Pricing tableの対象Plan row、Billing toggle、脚注、FAQ / Help Centerの対象Plan Section、発効日。
  • Decision rule: 同じPlan、地域、通貨、Billing周期、Seat条件を比較する。月払いと年払い、税込と税別、Introductory price等を単純な金額差として扱わない。
  • Allowed decisions: ACCEPT_PROPOSED / KEEP_CURRENT / DIFFERENT_BILLING_CONDITIONS / SET_UNKNOWN / NEED_MORE_EVIDENCE
3.19.6 Capability Review
  • Reviewerが確認するもの: 対象Capabilityの定義、現在値、新しく検出した公式文、対応Plan / Region / Interface、単なる関連機能との違い。
  • 見る場所: 公式Features / Docsの具体的な操作説明、入力・出力、利用可能Plan、制約が書かれたSection。
  • Decision rule例: Video Generation = TRUEは、ユーザーがProduct内または公式提供Workflowで動画を生成できる場合。動画解析、動画検索、将来予定、第三者連携だけを含めない。
  • Allowed decisions: CAPABILITY_PRESENT / CAPABILITY_ABSENT / LIMITED_OR_CONDITIONAL / UNKNOWN
3.19.7 Security Warning Review
  • Reviewerが確認するもの: 発火したSecurity / Availability Signal、検出回数、初回・最終日時、HTTP / TLS / Redirect履歴、公式Status、信頼できる外部Security Source、現在の公開表示、誤警告時の影響。
  • 見る場所: 外部Security Sourceの対象URL・判定Section、公式Status incident、Redirect先、証明書・HTTP履歴の該当時点。Domain ageやAIの印象だけを根拠にしない。
  • Decision rule: 公開警告は事前定義した客観SignalとThresholdに基づく。Product品質の低さ、人気のなさ、新規性をSecurity warningへ混ぜない。
  • Allowed decisions: PUBLISH_WARNING / KEEP_MONITORING / CLEAR_SIGNAL / PRODUCT_UNAVAILABLE / UNKNOWN
3.19.8 Vendor Dispute Review
  • Reviewerが確認するもの: Vendor identity、申告全文、対象Claim、Current value / Evidence、Vendor提出Evidence、Source authority、両者の差分、自動Evidence比較、過去の修正履歴。
  • 見る場所: Vendor提出の公式Page / Docsの該当Section、現行Evidenceの該当Section、必要なら公式Domain ownershipまたはVendor identity verification記録。
  • Decision rule: Vendor申告だけで上書きせず、同じ公開Evidence基準を適用する。Ranking、広告、商業契約を事実判定へ混ぜない。
  • Allowed decisions: ACCEPT_CORRECTION / KEEP_CURRENT / PARTIAL_CORRECTION / REQUEST_EVIDENCE / SET_UNKNOWN / REJECT_CLAIM
3.19.9 Review完了時の更新
  • Human Decisionは、対象Claim / Entity / Risk状態、Evidence、Change Event、必要なSearch Index、Watch通知へTransactionとして反映する。通知が必要な変更でも、Review完了前の未確定値を送らない。後からDecisionが覆った場合は、上書きではなくCorrection Historyとして残す。
3.20 Human DecisionをTraining / Evaluation Dataへ還流する
  • CONFIRMED: Human Reviewを運用コストだけで終わらせず、自動化率を上げる教師・評価データにする。
  • 各判断について、少なくとも次をLabel付きで保存する。
  • Review type、Product / Claim type
  • Human Review Packetの入力Snapshot
  • Candidate decisionsと最終Decision
  • Reviewer rationaleまたは適用したDecision rule
  • Evidence IDs、Source authority、Source取得日時
  • Review前のCurrent / Proposed value、各Confidence
  • Rule、Prompt、Model Adapter、Model、Extractor version
  • Review日時、覆されたか、後続Correctionがあったか
  • 同種例外を識別するFailure taxonomy
  • 改善ループ:
  • 要件:
  • 同じHuman Labelを学習と最終評価の両方に使わず、Train / Validation / Holdoutを分離する。
  • 高リスクTypeはレビュー件数削減だけを目的に自動化しない。False Merge、False Security Warning等の失敗コスト別に評価する。
  • 覆されたDecision、Rule変更前の古いLabel、Evidenceが後から無効になった例を追跡し、無条件に教師データへ混ぜない。
  • モデル再学習に限定せず、決定論的Rule、Source selection、Prompt、Schema、Model routing、Confidence thresholdの改善へ使う。
  • 改善前後でAccuracy / Precision / Recall / Calibration、Human escalation rate、同種例外再発率、Review時間、Product / Claim単価を測る。
  • UNKNOWNの減少だけを成功としない。誤った断定を増やさず、Evidence付き自動確定率を上げる。
4.2 対象範囲
  • ADOPTED: 画像・動画・文章だけの3カテゴリMVPにはしない。
  • 初期Universeは、Business / Creator向けで、非エンジニアがGUIから直接利用できるAIサービスを中心とする。
  • 少なくとも次の用途群をまたぐ。
  • General AI / Research
  • Automation / Agents
  • Office / Knowledge / Meeting
  • Marketing / Sales
  • Image / Design
  • Video / Audio
  • Notion、Google Workspace / Gemini、Microsoft 365 / Copilot、Canva等の「AI専業ではないがAI機能が重要な製品」も除外しない。
4.3 初期件数
  • WORKING: 500〜1,000 Productは目安として妥当だが、件数を完成条件にしない。
  • Completion Gateは、代表Queryに対して十分なCandidate Setを形成できることである。全体件数が多くても重要Queryで候補漏れが多ければ未完成であり、逆に主要Queryの探索品質が高ければ目安件数未満でも検証可能である。
4.4 初期Discovery範囲
  • WORKING: 英語圏と日本語のDiscovery Channelを中心に始める。ただし企業の本社所在地は限定しない。
  • 英語または日本語で情報公開しているフランス、台湾、韓国等のProductも発見対象
  • 将来、繁体字、韓国語、仏語、独語、スペイン語等を追加
  • 未開拓地域・言語は「未開拓」または「一部」と表示
  • 「日本のAIツールだけ」は採用しない。
4.5 MVPに含める機能
  • Publisher / Company / Registry Entity / Capability / Offeringの基本Registry
  • AI_SERVICE、AGENT_SKILL、MCP_SERVERの型別Schema、Identity、検索Filter
  • Product service_summary / service_detailの公式Source Grounding生成・再生成
  • 多軸OntologyとAI検索用内部表現
  • Discovery Sourceからの候補発見
  • DISCOVERからNOTIFYまでのLifecycle / State管理
  • 公式情報を優先するVerification
  • Critical Evidenceの抽出・保存
  • Functional Evidenceの初期対応
  • 項目単位Freshness
  • 自然言語検索
  • Hybrid Search（Structured + Keyword + Semantic）
  • 検索結果とCandidate Set表示
  • 「もっと見る」による探索範囲・除外理由の監査
  • Entity詳細とEvidence表示。SkillはManifest・Version・License・Permissions・対応Client、MCPはTransport・Auth・Tools / Resources / Prompts・Data accessを表示
  • 基本Compare
  • Status / Risk Signalの初期版
  • Snapshot / Change Eventの記録
  • My Stack
  • Watch Alternativesの初期版
  • Update Priority Engineの初期版
  • HOT / WARM / COLDの需要駆動Freshness Queue
  • 検索品質Benchmark
  • Unknown / Needs Recheckを通常状態として扱うValidation
  • 例外条件に限定したHuman Review QueueとFormal Review Packet
  • Entity Merge、Pricing、Capability、Security Warning、Vendor DisputeのReview UX
  • Human DecisionのLabel保存とBenchmark / Rule / Prompt / RoutingへのFeedback基盤
  • Methodology Page
  • Report incorrect information / Vendor correction requestの受付導線
  • 安全なFetch → Extraction → Validation → Publicationパイプライン
4.6 MVP画面
  • Search — 自然言語で目的を入力
  • Results — 結果数、Candidate Set、条件一致・除外理由
  • Entity Detail — 共通Summary / Detail、Capability、Evidence、Freshness、Status/Riskと型別Metadata
  • Compare — 同一Kindを原則とする条件別比較。Cross-kind比較は用途比較として明示した場合だけ許可
  • My Stack / Watch — 使用中Product、代替・変更監視
  • Universe / Search Scope — 探索範囲と方法論
  • Internal Review — 例外案件のHuman Review Packet、Source該当箇所、Diff、Decision Rule、Allowed Decisions
  • 高度な市場分析画面は後回しにできるが、Universe / Search Scopeは本サービスのコア画面である。
  • Internal Reviewは一般ユーザー向け画面ではないが、AI中心運用の安全性と自動化改善に必要なMVP運用画面である。
4.8 MVP完了・成功判定
  • 代表Queryで重要な候補がCandidate Setへ入り、明らかな無関係Productが抑制される
  • 結果と除外理由がEvidenceに基づき説明できる
  • 利用者が「何度も他には？と聞かなくても、十分な範囲を確認できた」と感じる
  • My Stack / Watchから実用的な変更・代替通知が生まれる
  • AI自動運用時のProduct・Claim・有用検索あたりコストが測定できる
  • 誤抽出、誤更新、False Merge、誤警告を検出・訂正できる
  • Unknownが推測で埋められず、需要の高いUnknownがPriorityによって優先再確認される
  • Human Reviewが例外へ限定され、Review Packetだけで指定箇所と判断基準を確認できる
  • Human Decisionを再現可能なLabelとして保存し、Worker改善前後の例外率と品質を測定できる
1. 仕分け表（15項目 → 正本の既存箇所 → 処置）
  • | 1 | Requirement Profile（自然言語→条件構造化） | §2.5（内部で条件へ分解） | 既存の別名 | M1後に別名注記1行 |
  • | 2 | MUST/PREFER/NOT_REQUIRED/EXCLUDE/UNKNOWN | §2.3、§8.4 Open Q#24（必須/推奨条件） | 既存の別名 | M1後に別名注記 |
  • | 3 | Requirement Match（MATCH/PARTIAL/NO/UNKNOWN） | §2.2/2.3（条件一致数）、§2.10 | 既存の別名 | M1後に別名注記＋§4参照 |
  • | 4 | Why this product | §1.3、§4.8 | 既存の別名 | M1後に別名注記 |
  • | 5 | Why not / Exclusion Reason | §2.3（除外理由）、§8.2 Open Q#10 | 既存の別名 | M1後に別名注記 |
  • | 6 | Requirement Save | §2.8、§3.18.10 | 既存の別名 | M1後に別名注記 |
  • | 7 | Requirement Watch | §3.18.10 WATCH MATCH（保存条件を満たす通知） | 既存の別名 | M1後に別名注記 |
  • | 8 | Selection→My Stack→Watch 導線 | §2.8 ＋ Watch 群 | 既存（UX 束ね） | M1後に導線注記 |
  • | 11 | Missing Product Report | §3.11 Correction/Dispute Flow | 既存の別名 | M1後に別名注記 |
  • | 12 | Incorrect Information Report | §3.11 Correction/Dispute Flow | 既存の別名 | M1後に別名注記 |
  • | 13 | Community Signal → Registry Quality Priority | §3.8 Update Priority Engine（訂正報告が既に入力） | 既存の拡張 | M1後に §3.8 へ1段落追記 |
  • | 14 | Competitive Parity と Differentiation の区別 | §1 原則 | 原則の明文化 | M1後に §1 へ注記 |
  • | 15 | Selection は入口・Registry は土台の明文化 | §1、§20 相当 | 原則の明文化 | M1後に §1 へ注記 |
R8. 正本・ER・Production・監査器を再突合した正式版完成命令
  • この節はR7以下より優先する。R7は実行姿勢を修正しただけで、正本とERに対する未実装監査を再固定していなかった。直前の不具合だけを直す方式を禁止し、以下の監査基準と欠落を全件実装対象に戻す。
R8.1 今回のAuthority範囲 — 直前だけを読んではならない
  • 実装者は最低でも次を同時にAuthority / Evidenceとして読む。どれか一つだけを読んでscopeを縮小しない。
  • ai-service-intelligence-registry-canonical-v0.5.md — 唯一の正本
  • ai-service-intelligence-registry-fitgap-triage-v0.1.md — 採否済みFitGap
  • 本書R3の過去18項目 — 少なくとも直近10件以上のUSER指摘を統合した非削除要件
  • 本書§5のER — 正本の関係を実装へ落とすTarget domain model
  • 本R8 — 正式リリース後にUSERが明示した追加Authorityと2026-09-18再監査
  • 現在のProduction実測、最終main、migration head、deploy identity
  • ai-service-intelligence-registry-requirements-v0.3.mdはSUPERSEDEDであり正本に使わない。docs/release-readiness.mdの古い［旧リリース表示名］判定、docs/definition-of-done.mdのLocal MVP非目標、過去のPASS artifactは、現在の正式リリース完成条件を縮小するAuthorityではない。(原文中の旧リリース表示名を伏せています。原文は正本で確認できます)
  • 本書は正本を置換しない追加USER authorityである。正本のCORE / CONFIRMED / ADOPTEDを保持したうえで、正式リリース済みという現在状態、完全Registry List、Open-source AI Tool、日次Global Discovery、共通Shell、GEO、Production completionを追加する。
R8.3 現行Discovery実装は根本要件を満たさない
  • 「件数を価値の中心にしない」は、少数固定でよいという意味ではない。件数をhard-codeした完成Gateにはしないが、世界供給を継続発見・登録・検証・公開するDISCOVERが非交渉である。87件が動かないことは、現在の閉ループが動いていない結果指標である。
  • 現行codeの次の問題をすべて修正する。
  • EntityKind、Pydantic型、candidate / product DB CHECKがAI_SERVICE / AGENT_SKILL / MCP_SERVERの三Kind限定である。live_discovery.pyがOPEN_SOURCE_AI_TOOLを渡しても型・DBで登録不能。型、schema、migration、API、UI、search、detail、compare、watch、sitemap、JSON-LDまで一貫して第四Kindを実装する。
  • LIVE_SOURCESは実質4 source、各Kindほぼ1 sourceだけ。これはGlobal supply discoveryではない。正本と§5.3のsource family、用途群、language、region、Kindをcoverage matrixで管理し、複数独立sourceを持つ。
  • GitHub searchがper_page=30固定で次page / cursorを取得しない。他sourceもpagination / resume cursor / ETag / Last-Modifiedがない。全pageまたは永続backlog / cursorまで取得する。
  • schedulerはWeb process内asyncio loopであり、正本が要求するdurable external scheduler、lease、catch-up、retry / backoff、dead-letter、multi-instance排他を満たさない。process restart、deploy、crash、複数instanceでも日次実行を保証する外部scheduler + durable jobへ置換する。
  • discovery_run_ledger一表のJSONへSource / Run / raw item / outcomeを埋めているだけで、ERのDISCOVERY_SOURCE / DISCOVERY_RUN / DISCOVERED_ITEM / DISCOVERY_CANDIDATE / DISCOVERY_COVERAGE_CELLがquery可能な第一級modelになっていない。
  • outcomeはnew / existing / error程度で、正本のduplicate / excluded / pending / published / failedおよびchanged / rejected / deferred / unprocessedを表現できない。
  • raw artifactの全件保存、source別Terms / robots / authority / locale / region / cadence / last success / failure / next run、disable理由 / 再開条件がない。
  • new candidateをREGISTERした後、official-source Verification、Publication、Search index、sitemap、Watch matchまで完走した実績がない。候補数の増加だけでも、candidate ledgerだけでも未完了。
  • REGISTRY_ALLOW_FIXTURE_INPUT=1がProduction設定に残る。Production ingestionへfixtureを混入できないようfail-closedにし、test環境だけへ限定する。
  • source障害、0件parse、pagination途中停止を新規0件の成功へ変換できる。集合保存とfail-closed判定を実装する。
  • Discovery完成のProduction証拠は固定総数ではなく、次の閉ループで判定する。
  • source inventoryに全enabled sourceとcoverage cellが存在
  • 各Kind・複数source familyで実HTTP取得、pagination / cursor進行、raw item全件保存
  • candidate outcome集合一致と未処理backlog可視化
  • Entity Resolution後、new / changedがVerification / Publicationへ流れる
  • liveで新規発見した各Kindの代表EntityがList、Search、Detail、Evidence、sitemap、Watchへ現れる
  • 連続2 runで重複登録せず、source変更時はChangeへ進む
  • schedulerの次回実行、missed-run catch-up、failure / retryをProductionで証明
  • backlogが存在する間、公開件数とverified fieldが実処理結果として更新される。件数をコードへ固定しない
R8.4 ER実装差分 — JSONで存在を擬装するな
  • §5のERに対し、現行schemaは多数の第一級modelを欠く。名称は変更してよいが、下記関係・制約・query可能性を実装する。
Registry / Identity / Distribution
  • PUBLISHER
  • REGISTRY_ENTITYとKind別AI_SERVICE_PROFILE / AGENT_SKILL_PROFILE / MCP_SERVER_PROFILE / OPEN_SOURCE_TOOL_PROFILE
  • ENTITY_IDENTITY（canonical、alias、redirect、rename、acquisition history）
  • DISTRIBUTION_ARTIFACT / ARTIFACT_RELEASE（repository、package、container、desktop app、hosted serviceを区別）
  • CAPABILITY / ENTITY_CAPABILITY
  • OFFERING / OFFERING_PRICE。Unknown amountと0、currency、period、region、seat、tax、billing conditionを列で区別
  • ENTITY_RELATIONSHIPの完全なrelationship vocabulary。現行PROVIDES / INTEGRATES / UNKNOWNだけで全関係を代用しない
Discovery / Evidence / Change
  • DISCOVERY_SOURCE / DISCOVERY_RUN / DISCOVERED_ITEM / DISCOVERY_CANDIDATE / DISCOVERY_COVERAGE_CELL
  • CLAIM_FRESHNESSとfield別SLA / next check / stale transition
  • ENTITY_SNAPSHOT / CHANGE_EVENT / RISK_SIGNAL
  • Claim↔Evidence、Change↔EvidenceをJSON ID配列だけにせずFK / joinで整合させる
  • Current pointerがEvidence、validator、Freshness、publication stateを満たさないassertionへ向かないDB制約 / transaction
Search / Selection / Audit
  • ANONYMOUS_SESSION
  • REQUIREMENT_PROFILE / REQUIREMENT_PROFILE_REVISION / REQUIREMENT_CONSTRAINT
  • SEARCH_AUDIT_RUN / CANDIDATE_DECISION / MATCH_REASON
  • Requirement revisionはimmutable、AuditはRegistry / index / ontology / model / ranking revisionへ固定
  • Candidate Set全件をincluded / excluded / errorへ一意分割し、各decisionがEvidenceを引用
  • conversation row内のrequirement_profile_jsonや、response内だけのWhy / Why notで上記を代用しない。
Account / Retention / Watch / Notification
  • SAVED_ENTITY / SAVED_SEARCH / STACK_MEMBERSHIP / WATCH
  • WatchはEntity直指定とRequirement Profile指定を区別
  • WATCH_MATCH / NOTIFICATION_OUTBOX / NOTIFICATION_DELIVERY / NOTIFICATION_RECEIPT
  • SENT / VISIBLE / READ / ACKを単一candidate rowのnullable timestampだけで潰さず、delivery attempt、channel、failure、retry、receipt、idempotencyを保存
  • Account FK、ownership、retention、deletion、legal holdをDBとworkflowで保証
Review / Correction
  • REVIEW_PACKET / REVIEW_DECISION / EVALUATION_LABELをCurrent / Proposed / exact Evidence / Diff / Rule / allowed decision / affected search-watchまでquery可能にする
  • Correctionはsubmitter / vendor identity、current evidence、submitted evidence、decision、history、affected publicationへ接続
  • Decision適用をClaim、Change、index、Watchへtransaction / durable outboxで反映
  • 各modelにFK、unique、CHECK、index、append-only / immutable規則、state transitionを持たせる。metadata_json、packet_json、outcomes_jsonだけへ意味関係を隠してはならない。
R8.5 Search / Chat / Selectionの根本要件
  • Chatは単語guardで拒否するbotではない。曖昧な業務要求から目的、Must / Prefer / Nice-to-have / Indifferent / Exclude、制約、Unknownを抽出し、不足時だけ最小限のclarificationを行う。
  • AI ServiceだけでなくAgent Skill、MCP Server、Open-source AI Tool / GitHub toolを同一会話から探索できる。Kindを決め打ちせず、利用者意図からscopeを説明する。
  • Candidate Setは現在の公開Registry全件を起点に、query / Kind / region / language / source scopeを記録する。少数のcurated候補だけを検索したように見せない。
  • Structured + Keyword + SemanticのHybridを実装し、semantic index revisionとfallback modeをAuditへ残す。文字列包含だけでHybridと呼ばない。
  • Resultsは結果N、評価対象M、included / excluded / error、除外理由、Unknown、探索範囲、最終探索時刻、未開拓coverageを同一Auditから表示する。
  • Why / Why notは実Requirement constraintとClaim / Evidenceから生成する。推測や説明テンプレで埋めない。
  • Compareは検索結果やSavedから2〜5件を比較するflowにし、全Entity checkbox wallを廃止する。同一Kind原則とcross-kind用途比較の区別を表示する。
  • Search history、conversation、Requirement revision、Auditをlogin後も同一所有権で復元する。anonymous→signup / login attachを安全に行う。
  • Gold queryは現在のProduction結果から自己生成せず、独立expected、holdout、重要候補recall、無関係抑制、Unknown fidelity、Why citationを評価する。
R8.6 Evidence / Freshness / Change / Publication
  • Critical / Functional / DescriptiveのEvidence強度を分け、Critical Claimは原則official sourceへ戻す。
  • EvidenceはURL、source type / authority、immutable snapshot、exact locator、excerpt、observed_at、hash、adapter / parser versionへ接続する。publicは利用者向け引用と確認日に変換し、内部SHA / offset / locatorを漏らさない。
  • Claim stateはUNKNOWN / VERIFIED / FALSE / NOT_APPLICABLE / FETCH_FAILED / PARSE_FAILED / UNPROCESSED / DEFERRED / STALE / DISPUTEDを意味どおり区別する。
  • field単位Freshness、HOT / WARM / COLD、demand / risk / change signalによるPriority Queue、light check→deep verificationを実装する。
  • Summary / DetailはVerified Current Claimから再生成し、定型placeholderやLLM自由文を公開しない。
  • typed Changeにold / new、detected / verified / effective time、Evidence、publication stateを持たせ、更新前後を保存する。
  • Public API、Home count、List、Search、Results、Detail、Compare、Universe、sitemap、JSON-LDは一つのpublication predicate / read modelを共有する。
  • rollback可能なpublication runを実装し、誤公開時にCurrent pointer、index、sitemap、Watchを一貫復旧する。
R8.7 Account / Watch / Retention閉ループ
  • login / signup / logout / expiry / rotation / return URL / CSRF / session continuityをProductionで確認する。
  • 未ログインのSave / Watchからlogin後に元操作へ戻る。
  • Favorites、Saved Search、Stack、Watchの意味をUIで分離する。意味不明なMy Stackラベルだけを置かない。
  • Watch create / list / edit / pause / resume / delete / historyを認証済みProductionで実行する。
  • Changeまたは新Entity→Watch match→outbox→in-app delivery→VISIBLE→READ→ACKを一つのtraceで完走する。
  • test account A / Bで所有権分離、IDOR、推測ID、存在非露出を確認する。
  • retention / deletion / export / legal holdをAccount、Session、Conversation、Search history、Saved、Stack、Watch、Notification、Correction、Auditごとに定義・実装する。
  • anonymous 401 / 404、endpoint存在、local unit testだけをこのGateのPASSにしない。
R8.8 正式版UI / Global / GEO / Trust
  • 必須surfaceを削除・吸収・文字列だけで代用しない。
  • Home / Chat entry
  • Search
  • Results + Search Audit
  • Explore AI Tools / complete Registry List
  • Entity Detail
  • Compare
  • Saved / Stack / Watch
  • Universe / Search Scope
  • Login / Signup / Account
  • Methodology
  • Correction / Missing Entity submission
  • Terms / Privacy / About / Contact
  • role-protected Internal Review
  • 全routeを一つのApplication Shell、navigation、auth state、locale stateで描画する。JA / ENは本文、navigation、form、validation、error、metadata、canonical、hreflang、Open Graph、JSON-LDまで一言語で完結させる。responsiveで必須menuを消さずaccessible menuへ畳む。
  • Registry Listは全Kindをfilter、複合facet、sort、paginateし、URLへstateを保持する。Universeは円の壁や意味不明なcoverage%ではなく、Kind / source family / use case / language / region / verification / freshnessの収録範囲と未開拓領域を監査可能にする。
  • GEOはcrawler許可だけではない。各Entityと比較・用途landingに、SSR / prerenderされた引用可能な名称、定義、Capability、Evidence、確認日、Unknown、方法論、canonical identity、structured dataを提供する。AI crawlerと検索engineへ同一public truthを返し、cloakingしない。
R8.9 AI中心運用 / Human Review / Safety
  • 通常Claimを人が全件承認する運用へ戻さない。AI / ruleがDiscovery、Extraction、Validation、Change、Priority、Publication候補を処理し、人は例外だけをReviewする。
  • Entity Merge、Pricing、Capability、Security Warning、Vendor Disputeの5 Review typeを、正本のPacket、allowed decisions、exact Evidence、Diff、Rule、影響表示どおり実装する。
  • Human Decisionをlabel、failure taxonomy、rule / prompt / model / adapter versionとともに保存し、train / validation / holdout分離、regression、routing改善、例外率 / unit costへ還流する。
  • Skillをinstall / executeせず、MCP Toolをcallせず、repository codeを実行しない。Manifest、package metadata、documentation、signatureをEvidenceとして検証する。
  • Safe Fetch、SSRF、DNS rebinding、redirect、size、content type、timeout、robots / Terms、credential redaction、rate limit、kill switchをProductionで実証する。
R8.10 正式リリース状態へ運用文書を訂正する
  • docs/release-readiness.mdの［旧リリース表示名］、Feature-complete pending deploy、accounts / Evidence viewer非搭載等の古い判定を現Production監査へ更新する。(原文中の旧リリース表示名を伏せています。原文は正本で確認できます)
  • docs/definition-of-done.mdは正本の履歴を消さず、現在の正式リリースoverlayと未達Gateを追加する。Local MVPの完了を正式版完成と混同しない。
  • runtime title、package description、health / version、public copy、runbookからMVP / Alpha / Preview / ［旧リリース表示名］を正式版状態として使わない。歴史記録内だけは残してよい。(原文中の旧リリース表示名を伏せています。原文は正本で確認できます)
  • 正本のOPEN / DEFERRED（料金境界、高度Market Intelligence、Vendor Dashboard等）を勝手に必須課金画面へ変えない。monetization hypothesisとunit economics計測は保持するが、コアRegistry完成よりbilling laneを優先しない。
R8.12 完全Gate — 監査器ではなくProduct意味論で判定
  • Gate A Authority: 三authorityの全IN_SCOPE clauseが固有実装・test・Production assertionへ接続
  • Gate B Global Supply: 四Kind、複数source family、durable daily discovery、cursor、raw item、coverage、registration、verification、publicationがProductionで連続実行
  • Gate C Registry Truth: ERの第一級model、Identity / dedupe、Claim / Evidence / Freshness / Change / Unknown、単一public集合
  • Gate D Selection: Chat clarification、五値Requirement、immutable revision、Hybrid Search、Candidate Set全件decision、Why / Why not、Search Audit
  • Gate E Account / Retention: session continuity、Save / Stack / Watch、Change→Notification→READ / ACK、二アカウント分離、retention / deletion
  • Gate F Complete UX: 必須13 surface、完全List、Detail、Compare、Universe、shared shell、JA / EN、responsive / accessibility
  • Gate G Trust / GEO / Safety: Methodology、Correction、Legal、SSR / structured data、citation、crawler集合一致、Safe Fetch、non-execution
  • Gate H One Production Truth: final main、clean integration、migration、deploy identity、backup / restore / rollback、全artifact hash、全Gate同一deployment
  • Gate Bは「500件以上をhard-codeしたか」では判定しない。しかし、世界には多数の供給が存在し、未処理backlogがあるのに87 / 95件が動かず、四Kind・複数source・cursor・公開閉ループのEvidenceがない状態は明確にFAILである。
R8.13 実装終了禁止条件
  • 次のいずれかが残る間、commit表、pytest件数、設計判断、Chrome手順、owner deploy依頼だけを返して終了してはならない。
  • Home / List / API / Search / sitemap / JSON-LDの集合またはcount意味が不一致
  • Open-source / GitHub toolを登録・検索・表示・監視できない
  • 日次Discoveryの次回実行、cursor進行、raw reconciliation、new / changed publicationを証明できない
  • ER第一級model、Search Audit、Watch delivery / receiptのいずれかをJSONだけで代用
  • 正式版の必須surfaceまたはJA / EN / GEO / Legal / Reviewが未接続
  • requirements manifestがUSER authorityを含まず、generic keyword probeでcovered扱い
  • final mainとProduction revision / schemaが不一致
  • A〜HのどれかがFAIL / SKIPPED / UNKNOWN / NOT_RUN
R7.3 直ちに完成させる実体
  • 認証sessionがlogin後のChat、Search、Results、List、Detail、Compare、Universe、Saved / Watch、locale切替、reloadで維持される。
  • 全routeが同一Application Shellと同一権限・locale状態を使う。
  • Chatが条件を構造化し、確認質問、Search Audit、候補、Why / Why notへ接続する。
  • AI Service、MCP Server、Agent Skill、Open-source AI Toolの世界供給を、複数の実source familyから毎日自動探索し、cursor、再試行、重複解決、Evidence、Freshness、Change、公開まで完走する。
  • Registry List、Search、Results、Entity Detail、Compare、Universeが同じpublic Entity集合を表示し、件数をhard-codeしない。
  • Saved / WatchとChange通知が認証済みProductionで作成・一覧・更新・削除・VISIBLE・READ・ACKまで完走し、二アカウント間で隔離される。
  • Human Review、Correction、GEO、JA / EN、Legal / Safety、運用復旧を正本どおり接続する。
  • 各項目はUIだけ、APIだけ、DBだけ、testだけでは未完了である。UI→API→domain→DB / scheduler→再表示・通知まで接続し、Productionで確認して初めて完成とする。
R4.2 認証session continuityをデータ・表示・操作の三層で直す
  • Homeのcookie検出JSを修正するだけでは不十分である。次を一つの認証契約として実装する。
  • rr_sessionはHttpOnly / Secure / SameSite / Pathを維持し、client JSでtokenを読まない。
  • 全HTML requestでserverがsessionを一度だけresolveし、AuthContext(user_id, authenticated, csrf, locale, return_to)をshared shellへ渡す。
  • Homeをstatic templateへの文字列差込みとclient cookie推測から外し、他routeと同じserver-rendered shared shellへ統合する。client bootstrapが必要なら、credential付きsame-originの/v1/me相当からboolean / profileだけを受け、tokenを返さない。
  • ログイン済みheaderは保存・ウォッチ / Account / ログアウト、未ログインheaderはログイン / 新規登録を表示する。実sessionと表示が一件でも食い違えばFAIL。
  • /v1/chat、Search、Results、List、Detail、Compare、Universe、Methodology、Saved / Watch、locale切替、back / reloadを行ってもsessionを失わない。chat fetchはcredentials: same-originを明示する。
  • session cookieを削除できる経路は明示logout、expiry、server revocation、account closureだけ。通常navigation、chat失敗、off-topic、locale変更、404 / 422で削除しない。
  • ログイン前のquery、conversation、compare tray、save / watch intent、locale、return URLを安全なsame-origin return_toとして保持し、login / signup後に元操作へ復帰する。open redirectを拒否する。
  • account作成時に匿名conversationを引き継ぐ場合は明示同意、ownership transfer、retentionを実装する。暗黙に別accountへ紐付けない。
  • session lookup失敗時は、expired / revoked / invalid / DB errorを区別する。DB errorをanonymousへsilent downgradeしない。
  • 見た目上ログアウトしただけか、実session rowが消えたかを必ず分けて調べる。UI screenshotだけでは合格にしない。
R4.3 全routeを一つのApplication Shellへ統合する
  • 次のpublic / account routeは、例外なく同一render_pageまたは同等のsingle shell componentを使用する。
  • Internal Reviewは同じdesign token / locale / accessibility foundationを使うが、role-protected internal navigationへ分離する。
  • 共通shellの契約:
  • logo、primary nav、auth slot、locale switch、footer、skip link、focus、responsive menuを一箇所だけで生成する。
  • primary navの項目、順序、label、hrefは同一locale / auth stateなら全routeで同一。active stateだけが変わる。
  • JA routeはJA、EN routeはENで完結する。固有名詞を除き二言語併記しない。
  • query、selected Entity、compare tray、return URLを壊さずlocaleを切り替える。
  • /compare、/universe、/results、/stack、trust pagesにある独自<!DOCTYPE html> / header / nav / tokenを削除し、共通shellへ移す。
  • responsive時にmenu項目を勝手に削除せず、accessible menuへ畳む。
  • auth stateはserver truthから描画し、DOM内cookie推測、localStorage user key、routeごとの独自判定を禁止する。
  • navigation contract testは、全route × anonymous / authenticated / expired / revoked × ja / en × 6 viewportを走査し、同一stateのnav link集合・順序・auth control・locale controlが一致することをassertする。HTML文字列だけでなく、login→chat→results→detail→compare→watch→reloadの実navigationで検証する。
R4.4 Chatは拒否botではなくRequirement clarificationへ直す
  • crmを使う、CRMを導入したい、営業管理をAI化したい等、AI tool選定へ合理的に展開できる入力はin-domainとして扱う。
  • 曖昧な入力は、対象業務、利用者、必要機能、既存tool、integration、language、budget等を一度に1〜3問だけ確認する。即off_topicで終了しない。
  • 明確なoff-topicでも、選定対象外である理由とAI tool選定へ言い換える例を、そのrouteの一言語だけで返す。
  • user message、assistant message、Requirement Profile revision、Search Audit runを同一conversationへ保存する。reload / auth後も所有権とretention規則に従い再開できる。
  • 同じ入力を二重送信・二重表示しない。network retryはidempotency keyを持つ。
  • bot responseのhits / checked / modeというdebug表記を利用者向けの結果数、候補として確認した数、探索説明へ置き換える。内部classifier modeはpublicへ出さない。
R4.5 Global Discoveryをbootstrapからlive productionへ置換する
  • 既存seed / curated policyは移行開始点としてだけ保持できる。Discovery完成の証拠には使わない。
  • 最低限、次のlive source familyをproduction schedulerから実行する。
  • AI Service: launch feeds、marketplace / directory、public search / approved search API、vendor sitemap / RSS / changelog、official product pages、integration / competitor pages、Missing Product submissions
  • MCP Server: official MCP Registry、GitHub MCP Registry、maintained catalogs、package registries、GitHub repository discovery、vendor / maintainer sources
  • Agent Skill: official / public skill catalogs、manifest discovery、supported client listings、package registries、publisher repositories
  • Open-source AI Tool: GitHub / GitLab search / topics、release feeds、package / container registries、official project sites
  • 実装条件:
  • durable external schedulerで毎日一回以上実行する。Web process startup、memory timer、手動commandをdaily operationと呼ばない。
  • source inventoryへkind、language、region、source family、authority、Terms / robots、cursor、pagination、incremental key、cadence、rate limit、last success / failure、next runを保存する。
  • 初回は各enabled sourceをpagination終端または明示的で永続化されたresume cursorまで取得する。任意の1 page / max_new / 87件capで打ち切らない。
  • raw item全件をimmutable run artifactへ保存し、candidate / duplicate / excluded / pending / failedへ一意にreconcileする。
  • source横断Entity Resolutionを行い、duplicate、alias、rename、acquisition、repository / hosted service関係を正しく扱う。
  • 新規Entityだけでなく、既存Entityのrelease、pricing、capability、integration、language、region、license、permission、auth、transport、archive、sunsetをchange candidateへ送る。
  • Critical Claimはofficial sourceへ戻ってVerificationし、第三者sourceやGitHub starだけでVerifiedにしない。
  • missed runはcatch-upし、retry / backoff / dead-letter / idempotency / lease / concurrency controlを持つ。source障害をnew 0 successへ変換しない。
  • search index、List、count、sitemap、JSON-LD、Universe coverage、Watch matchをpublication後に更新する。
  • source別fetch数、raw数、new / existing / changed / duplicate / rejected / failed / deferred / unprocessed、cursor、cost、duration、next runをproduction ledgerへ表示する。
  • 500件をhard-codeした初回投入Gateにはしない。しかし、live fetch未実行でbootstrapの87 / 117件に留まる状態も合格ではない。全enabled sourceの実fetchとcursor進行を証明し、live runで発見した供給を実際に登録・検証・公開した結果として件数が動的に変わらなければGate BはFAILである。
Auth continuity probe
  • test account Aでloginし、session cookie hashとuser IDをserver側で記録。
  • Home、chat送信、Results、List、Detail、Compare、Universe、Methodology、Saved / Watch、JA / EN切替、reloadを順に操作。
  • 各responseで同一user ID、同一有効session、authenticated nav、所有データだけが維持されることを確認。
  • account BでAのSaved / Watch / conversationへ到達不能を確認。
  • logout後だけsession row / cookieが失効し、全routeがanonymous navへ変わることを確認。
Navigation identity probe
  • 全routeのheader DOMを取得し、locale / auth stateごとにordered href + visible label + auth control + locale controlを比較する。Compare / Universeだけ項目が少ない、Methodologyだけfooter nav、Homeだけclient判定ならFAIL。
Live discovery probe
  • fixture / seedを無効にした隔離production-equivalent runと本番runの両方で、複数source familyのlive HTTP取得を証明する。
  • sourceごとにpage 1だけでなくcursor終端 / resume状態を証明する。
  • raw items = resolved + duplicates + excluded + pending + failedの集合一致を確認する。
  • 二連続runで初回new、二回目existing / unchanged、source更新時changedが記録されることを確認する。
  • liveで新規に発見した各Kindの代表EntityがDB、List、Search、Detail、sitemapへ現れ、Evidence / Freshnessを持つことを確認する。
  • ledgerにnetwork_fetch: pending、bootstrap only、fixture sourceが一つでも残ればFAIL。
  • 上記三probeをGate E / F / Bへそれぞれ追加し、旧probeのPASSを再利用しない。
R3.2 必須surfaceと機能の非削除マトリクス
  • route名や画面統合は変更してよいが、次の利用者能力を削除・stub化・別worktree放置してはならない。各行は、productionで人間が操作でき、同じdomain dataへ接続され、独立probeが必要である。
  • | Ask / Home | JA / EN自然言語入力、匿名開始、3件以内の例、完全Registry Listへの導線、Evidence / Freshness / continuous discoveryの簡潔な価値説明 | 巨大logo、固定件数、内部状態統計、debug prompt、Methodology linkだけ |
  • | Results / Conversation | conversation継続、Requirement Profile五値の確認・編集・版管理、Candidate結果、Why / Why not、Unknown、Evidence、Freshness、Search Audit展開、Compare / Save / Watch | 一回POST、文字列marker、上位数件だけ、No matchesだけ |
  • | Explore AI Tools / Registry List | 全Kind、name / capability / integration / use case検索、多軸filter、sort、server pagination / cursor、URL state、Evidence / last checked、Compare tray、Save、Correction / Missing Product | Universeへの吸収、Kind tabと名前検索だけ、全件DOM描画、bubble、固定件数 |
  • | Entity Detail | Summary / Detail、型別metadata、Capability、Offering / Pricing、Language / Region / Integration、Claim Evidence、field Freshness、StatusとRisk、Change timeline、Compare / Save / Watch / Correction | raw JSON、SHA、内部state、generic summary、別read model |
  • | Compare | Results / List / Detailから2〜5件を追加、同一Kind原則、Requirementを行、Entityを列、Match / Why / Evidence / Freshness / Unknown / 差分、候補入替、Watch引継ぎ | 全件checkbox wall、異Kind無説明混在、Unknownを差異・敗北扱い |
  • | Saved / Currently using / Watch | Favorites、保存検索、利用中Entity、direct / alternative / requirement / stack watch、CRUD、履歴、frequency / channel、Change / new Entity通知、READ / ACK | 説明なしのMy Stack、認証なしuser_key、作成のみ、no-op sender |
  • | Universe / Search Scope | Kind×6用途×language / region×source family、explored / partial / unexplored / failed、run ID、last / next run、discovered / registered / public / eligibleの分離、drill-down | 世界母数不明のcoverage%、bubble wall、117件をGlobal coverageと呼ぶこと |
  • | Methodology | DiscoveryとVerification、Candidate定義、scope限界、Evidence / Freshness、rankingと商業分離、自動化限界、Correction | 免責文だけ、Human Reviewを通常工程として説明 |
  • | Login / Sign up / Account | 未ログイン検索、価値体験後auth、return flow、session expiry / logout、履歴・所有権、account closure / export / deletion | 保存ボタン非表示だけ、偽Login画面、別accountデータ参照 |
  • | Correction / Missing Product | Entity / field単位の誤情報報告、Vendor correction、Missing Product→Discovery queue、受付番号、状態、Evidence、履歴 | contact linkだけ、DB保存なし、固定SLAの捏造 |
  • | Internal Review | role保護、5種Packet、Current / Proposed / exact source / diff / rule / allowed decision / Unknown、transaction反映、feedback label | public nav露出、一般利用者アクセス、自由文だけの審査、通常Claimの全件人手承認 |
  • | Trust / Legal | About / Contact / Terms / Privacy、実在情報、security / abuse窓口、retention / takedown / dispute導線 | placeholder、架空連絡先、循環link |
  • 画面を統合する場合も、上表の能力を同じ権限・同じ到達性で維持し、旧routeをcanonical redirectする。routeを消して404にする、navから外して到達不能にする、backendだけ残す、画像だけ作る行為は機能削除である。
R3.3 正本機能をUIへ接続する横断契約
  • Discovery / Registry: Universeでscopeとrunを監査でき、Listで公開Entityを直接探索でき、Methodologyで取得・検証方法を理解できる。
  • Selection / Search Audit: Home入力からResultsのProfile、Candidate partition、Why / Why not、Evidenceへ一つのtraceで進める。
  • Evidence / Freshness: Results、Detail、Compareに同じCurrent Claimを表示し、利用者向けlocatorと確認日時へ辿れる。内部hash / offsetは出さない。
  • Change Intelligence: verified ChangeだけをDetail timeline、Search index、Watch matchへtransactionally反映する。
  • Account / Watch: 未ログイン操作→auth→元操作復帰→保存→Watch→通知→READ / ACKを一つのE2Eで閉じる。
  • Human Review: 自動処理で安全に確定できない例外だけをInternal Reviewへ送り、DecisionをClaim / Change / Search / Watchへ反映する。
  • Skill / MCP / OSS: List、Search、Detail、Change、Watchで発見可能にし、型固有metadataを表示する。Verificationでinstall / executionしない。
  • GEO / Global: JA / EN各routeの本文・metadata・structured dataを単一言語で完結し、canonical / hreflang / sitemap / JSON-LDを同一public Entity集合へ接続する。
  • UI担当がbackend契約をmockし、backend担当がUIを未接続にしたまま各自PASSを出すことを禁止する。上記横断契約はintegration E2Eが通るまで未実装である。
Home
  • 現在登録済みのAIサービス: 87件のままで、Global supplyの動的成長を示していない。
  • 確認済み0 / 部分確認66 / 不明21と古いsnapshot時刻を前面へ出す。
  • 価値説明が重複し、chat-first Selection Engineではなく中央寄せ説明文と固定統計が主役のまま。
  • /search、/list、/compare、/universeでheader構造とnav項目が統一されていない。
Search / Results
  • JA routeなのにSearch Registry、Must / Prefer、Universe、Search、Requirement Profile、No matches、Whyが混在する。
  • ProfileはMUST / PREFER / NOT_REQUIRED / EXCLUDE / UNKNOWN五値を扱わず、実質Mustと単一Prefer inputだけ。
  • budgetをPython dict文字列{'max_amount': 30.0, ...}として表示している。
  • Query例では0 hits / 66 entities checkedとなり、87件・95件・117件との集合関係を説明できない。
  • Notion / Zoom等のRequirementを編集・保存・再実行できない。
  • もっと見るによるCandidate Set、除外理由集計、region / language / source scope、Freshness内訳がない。
  • Otter.ai、Zoom AI Companion等の未確認価格をUSD 0 は予算内としてWhyへ採用している。Unknownを0円 / MATCHへ変換する正本違反である。
  • Search Audit ID、Registry / index revision、evaluated / excluded / error集合、Evidence参照が利用者から監査できない。
Registry List
  • Kind tabと名前検索だけで、Use case、Capability、Pricing、Language、Region、Integration、Verification、Freshness、Risk、License、Hosting、Auth / Transport等のfilterがない。
  • sort、URL state、server-side pagination / cursor、compare tray、Save、last checked、Evidence actionがない。
  • OPEN_SOURCE_AI_TOOLがない。
  • total 95、AI Service 66、Agent Skill 16、MCP 13で、Home / Compare / Universeと値が不一致。
  • 95件を一括描画し、世界規模Registryを扱える設計ではない。
  • Skill / MCP説明が公式情報を確認済みですというgeneric placeholderで、意思決定情報にならない。
  • ACTIVE / ACTIVE_PARTIAL等の内部state名を利用者説明なしに露出している。
Entity Detail
  • State: ACTIVE_PARTIAL、raw JSON、internal field名、section locatorL0163、SHA、adapter / provenance version、ISO timestampをpublic UIへ露出している。
  • productionでNotion AIのPricing表示はUNKNOWNなのに、Field ProvenanceではEnterprise / amount 0.0 / period NONEを検証済みとして保持し、Searchでは0ドルとして使う。read modelが分裂している。
  • Company / Delivery / PricingがUnknownでも、ページ上部説明は料金・planを断定的に列挙し、structured claimとsummaryの整合がない。
  • human-readable Evidence、Freshness、Risk、Change、Correction、Compare、Save / Watchの利用者導線が不足。
  • 「内部ID露出0」という報告はproduction DOMと明確に矛盾する。
Compare
  • 87 AI Service、17 Skill、13 MCPを最初からcheckbox wallへ全列挙している。
  • ChatGPTが2件、Claudeが2件あり、Entity Resolution未解決。
  • Compare候補をSearch / Results / List / Detailから追加するpersistent trayがない。
  • Requirement Profile、Match、Why / Why not、Evidence、Freshness、Unknownを行軸にした比較ではない。
  • compare pageはshared web_layoutを使用せず、独自header / CSSを持ち、language switch、login、methodology等が消える。
  • header logoがSだけに崩れ、UI統一という報告に反する。
Universe / Search Scope
  • 117 Total Entities、256 Verified Fields、48% Coverageのまま。未知の世界母集団に対する48%の意味が定義されていない。
  • 87 / 17 / 13のstatic collectionをbubble wallで表示するだけ。
  • region、language、source family、use case、explored / partial / unexplored / failed、last / next runがない。
  • ChatGPT / Claude重複を含む。
  • shared shell、language switch、Methodology導線がなく、独自headerのまま。
Data / integration
  • 同じproductionでHome=AI Service 87、List=AI Service 66 / total 95、Search=66 checked、Compare=87+17+13、Universe=117という複数の母集団が併存する。
  • public_read_modelまたは単一publication predicateが全surfaceへ適用されていない。
  • Discovery ledgerは117 NEW_IDENTIFIEDを返すだけで、live source / cursor / run / outcome / next runを証明しない。
  • Global daily discoveryが実装されておらず、87 / 117付近のstatic seed状態を維持している。
  • 作業branch HEADは48336dc、mainは1c1fb85であり、35ファイル・約21,563追加行がmain未統合。これをlandedまたはGate H PASSと呼ばない。
R2.5 UIは文言patchではなく主要surfaceを再実装する
  • 次のファイル群を、個別inline HTML / CSSの寄せ集めから一つのshared product shellと共通componentへ統合する。
  • registry_mvp/static/index.html
  • registry_mvp/src/registry_mvp/web_layout.py
  • search_page.py
  • results_page.py
  • list_page.py
  • detail_page.py
  • compare_page.py
  • universe_page.py
  • stack_page.py
  • login / signup / trust pages
  • compare_page.pyやuniverse_page.pyが独自<!DOCTYPE html>、独自header、独自tokenを返す状態を廃止する。すべて共通shell、locale、auth state、navigation、footer、design token、focus / error / loading semanticsを使う。
  • UIの合格は「文字列を変えた」「タブを追加した」ではなく、次の6タスクをproduction実データで完遂できることとする。
  • Homeで自然言語条件を入力し、五値Requirement Profileを確認・編集する。
  • ResultsでCandidate Set、Why / Why not、Unknown、Evidence、Freshness、除外内訳を監査する。
  • Registry Listで全Kindを多軸filter / sort / paginateし、URL stateを共有する。
  • Results / List / Detailから2〜5件をcompare trayへ追加し、Requirement軸で比較する。
  • Entity Detailでhuman-readable Evidence、Freshness、Change、Riskを確認し、Correction / Save / Watchへ進む。
  • Login後、保存したRequirementまたはEntityのWatchを作成し、Change通知をREAD / ACKする。
  • この6タスクを満たさない限り、UI GateはFAILである。
  • §7.1の5枚のUI画像を情報設計・視覚階層の必須参照として実装する。画像を見た、HTMLを試作した、別worktreeに置いた、screenshotを生成しただけでは成果ではない。Home / Results / Full Registry List / Detail / Compare / Universe / Watchをproduction URLで撮影し、参照画像の目的と次の禁止構造が解消されたことをroute別artifactで示す。
  • hero中央の巨大logo、説明文の重複、内部運用統計の主役化
  • 全Entityのbubble wall / checkbox wall / 一括DOM描画
  • 複数種類の独自header、崩れたlogo、JA / EN混在
  • raw dict / JSON / SHA / DB state / adapter / locator / internal timestampのpublic表示
  • 固定件数、意味不明なcoverage率、重複Entity、generic placeholder summary
  • 主要機能を削って見た目だけ簡素化すること
R2.6 一つのPublic Entity集合へ統合する
  • 同一revisionでは次を完全一致させる。
  • Kind別countも一致させる。未公開Entity、候補、重複、stale cache、旧seedを混在させない。ChatGPT / Claude等のduplicateをEntity Resolutionで解消し、削除 / merge / alias / redirect historyを保存する。
R2.7 Unknown / Pricingのproduction blocker
  • 次を同時に直す。
  • amount不明を0.0へ変換しない。
  • included feature / trial / credit / enterprise custom priceをFree planと解釈しない。
  • period NONEと月額予算を比較しない。
  • Detail、Search、Compare、APIが同一verified current claimを読む。
  • summary / detailとstructured claimが矛盾する場合、公開またはMatchへ使用しない。
  • QueryのWhyに使ったpricing / language / integration / capabilityから、利用者がEvidenceへ辿れる。
  • Unknown pricingを含むgold caseを作り、予算MUSTに対してUNKNOWNになり、MATCHや予算内にならないことをproductionで証明する。
3. 正本全章の実装・検収対応
  • 各atomic clauseへ固有のimplementation evidence、test、production probeを割り当てる。章を読んだ、generic testがある、routeが200を返した、という説明はcoverageではない。
  • | §1.1〜1.6 Product Core | Global Registry、監査可能な探索、三Use Case、五柱、非交渉原則 | Ask→Results→Audit→Compare→Watch E2E、Unknown、ranking中立性、安全境界 |
  • | §2.1 Automated Operation | AI自動Discovery / Extraction / Validation / Monitor、例外Review | 二連続scheduled run、retry / DLQ、通常Claim人手承認0 |
  • | §2.2〜2.5 Search | Result N / Candidate M、もっと見る、多軸、自然言語 | 五値Requirement、Candidate集合整合、除外理由、Hybrid search寄与 |
  • | §2.6〜2.10 Trust / Retention | Evidence、Status / Risk、Stack / Watch、Login、Unknown | Detail / Compare / Watch / Authの実操作、EvidenceとFreshness表示 |
  • | §3.1〜3.7 Registry | Entity schema、summary / detail、Universe、Change、Evidence、Freshness、Discovery / Verification分離 | public DTO、snapshot、source authority、全surface集合一致 |
  • | §3.8〜3.9 Priority | HOT / WARM / COLD、Light / Deep check | 需要・変更・SLAによる実queue配分、昇降格、cost telemetry |
  • | §3.10〜3.17 Neutrality / Safety | ranking分離、Correction、Benchmark、Confidence、Methodology、Public / Intelligence、crawler安全、Entity Resolution | commercial invariance、100 query回帰、internal leak 0、SSRF fail-closed |
  • | §3.18 Lifecycle | DISCOVER→IDENTIFY→REGISTER→VERIFY→PUBLISH→MONITOR→DETECT CHANGE→RE-VERIFY→UPDATE→WATCH MATCH→NOTIFY | 三Kindの正常・失敗・再実行・重複・rollback trace |
  • | §3.19〜3.20 Human Review | Formal Packet、5専用UX、Decision、Label / Feedback | role protected UI、allowed decision、transaction、holdout分離 |
  • | §3.21 Architecture | multi-worker、交換可能adapter、version / trace / cost | typed task、timeout、fallback、DLQ、versioned trace |
  • | §4.1〜4.8 Minimum product | 六用途群、global / JA discovery、全機能、七画面、account境界、成功判定 | route / locale / auth inventory、代表Query、Watch、cost |
  • | §5 Deferred | 後回し項目を勝手に完了要件へ混ぜない | OUT_OF_SCOPE理由をsource lineへ接続 |
  • | §6 Rejected / Corrected | 60〜90件限定、全件週次、特定技術固定、公式優遇等を復活させない | negative regression |
  • | §7 Rationale | 普通のdirectoryへ退行しない | Search Audit / Change / Watchが実UIとデータに存在 |
  • | §8 Open | 推測で確定しない | UNRESOLVEDとdecision recordを分離 |
  • | §9 Economics | Product / Claim / useful search / Watch / notification単価 | 実telemetry。欠測を0円にしない |
  • | §10 Drift Check | 全項目をrelease gate化 | probeとartifact |
  • | §11 Summary | Entity + Evidence + Change + Search / Coverage資産 | UI / API / DB / log整合 |
  • | §12 Technical Decisions | routing、infrastructure、publication boundary | raw/model直接公開0、rollback、outbox idempotency |
  • | §13 Baseline | local canaryをproduction完成と誤表示しない | environment / revision provenance |
  • | §14〜16 Roadmap / DoD | 過去DONEを正式製品完成へ読み替えない | exact main SHA、migration、deploy、cache、全Gate |
  • | §17 Skill / MCP | 型固有Identity、Evidence、Change、安全境界 | cross-kind merge拒否、install / tool call 0、型別Gold set |
  • | FitGap | Requirement Profile、重要度、Match、Why / Why not、保存、Watch、Correction | Profile→Compare→Watch E2E |
  • | USER Global Supply | 毎日世界供給を再調査し追加・更新 | live sources、二連続run、cursor / catch-up / ledger |
  • | USER UI / GEO | global JA / EN UI、AI crawler可読性、全Registry一覧 | SSR本文、structured data、visual / accessibility、List操作 |
5. Target domain model
  • 名称は現行実装へ合わせてよいが、意味と関係を削ってはならない。
  • このERは「概念がどこかのJSONに入っている」ことを許可する図ではない。Identity、Kind固有profile、Capability、Offering / Price、Discovery raw itemとcoverage、Claim / Evidence / Freshness、Requirement revision、Candidate decision、所有権、Watch / Delivery / Receipt、Review / Correctionは、外部キー、制約、index、state transitionを持つquery可能な第一級モデルとして実装する。可変なsource payload等をJSONへ保持してよいが、正本上の関係・状態・一意性をJSONだけへ隠してはならない。
  • 少なくとも次のDB制約を持つ。
  • canonical identityとalias / redirect history、Kindを跨ぐmerge拒否
  • Offering priceのamount不明と0の区別、currency / billing period / region / seat条件
  • Claim Current pointerは公開可能な一つのassertionだけを参照し、Evidence / validator / Freshnessなしに更新できない
  • Requirement revisionはimmutable、Search Auditは実行時revisionとRegistry / index revisionへ固定
  • Candidate decisionはeligible集合をincluded / excluded / errorへ一意分割
  • Watch、Saved、Stack、Correction、NotificationはAccount FKで所有権を保証
  • Outbox / delivery / receiptはidempotency keyと状態遷移を持ち、SENT / VISIBLE / READ / ACKを混同しない
  • Review decisionはCurrent Claim、Change、Search index、Watch影響を同一transactionまたは再実行可能outboxで反映
5.1 Entity Kind
  • 最低限、次を区別する。
  • AI_SERVICE
  • AGENT_SKILL
  • MCP_SERVER
  • OPEN_SOURCE_AI_TOOL
  • 正本互換性のため、open-sourceをAI_SERVICEのdistribution subtypeとして実装する判断も許容する。ただしGitHub repository、package、container、desktop app、hosted service等のdistribution artifactを表現でき、一覧・検索・detail・Evidence・Change・Watchで発見可能でなければならない。
  • 異Kind mergeは禁止する。ServiceとSkill、MCP endpointとVendor SaaS、repositoryとhosted productはlinkできるが同一Entityへ潰さない。
  • Entity Resolutionの判断は最低限SAME_PRODUCT / NEW_PRODUCT / UNKNOWNを持ち、alias、rename、acquisition、canonical domain移行履歴を保存する。機能類似や同名だけでmergeしない。
  • 型固有metadata:
  • AI_SERVICE: offering、pricing、delivery / hosting、language / region、integration
  • AGENT_SKILL: manifest、version、license、permissions、supported clients、runtime、install source
  • MCP_SERVER: version、transport、hosting、auth、tools、resources、prompts、data access
  • OPEN_SOURCE_AI_TOOL: canonical repository、homepage / docs、license、latest release、package ecosystem / identifier、platform / runtime、installation、maintenance / archived state
  • Star、download、third-party catalogはPopularity / Discovery signalであり、Verified capabilityの根拠ではない。
5.2 Claim / Evidence / Freshness
  • Factはfield / claim単位で持つ。
  • UNKNOWN、NEEDS_RECHECK、CONFLICTを正規状態として持つ。
  • Evidenceはsource URLだけでなく、source type、authority tier、snapshot、locator、excerpt、observed time、hashへ接続する。
  • Freshnessはentity単位の一個の日付ではなくfield / claim単位で持つ。
  • Changeはold / new、change type、detected / verified / effective time、Evidence、publication stateを持つ。
  • raw snapshotと内部locatorをPublic APIへ漏らさない。
  • Claim stateは意味に応じてUNKNOWN / VERIFIED / FALSE / NOT_APPLICABLE / FETCH_FAILED / PARSE_FAILED / UNPROCESSED / DEFERRED / STALE / DISPUTEDを区別し、取得失敗をUnknownやFalseへ潰さない。
  • 単一のpublic_read_modelまたは同等のpublication predicateを、公開API、List、Detail、Search、Compare、count、sitemap、JSON-LDの唯一の集合定義にする。
  • Public Layerは名称、official URL、主用途、基本Capability、概算料金、言語、簡易Status、確認日、基本比較等のallowlistとし、raw snapshot、内部ontology / similarity graph、locator、pipeline metadataは権限・rate limitされたIntelligence Layerへ隔離する。
5.3 Discovery
  • DISCOVERY_SOURCEとDISCOVERY_RUNを永続化する。
  • 最低限のsource family:
  • AI Service: official directories / marketplaces、product launch feeds、vendor sitemap / changelog / RSS、official company / product pages、reliable third-party discovery sources
  • MCP: official / maintained registries、package registries、GitHub topics / search、vendor docs、client catalogs
  • Agent Skill: official repositories / marketplaces、manifest locations、package registries、publisher catalogs
  • Open-source AI Tool: GitHub / GitLab repositories and topics、release feeds、package / container registries、official project sites
  • 各sourceはlocale / region / kind / authority / robots / terms / fetch policy / cursor / cadence / last success / failure / next runを持つ。
  • 正本の六用途群General AI / Research、Automation / Agents、Office / Knowledge / Meeting、Marketing / Sales、Image / Design、Video / Audioと、language / region / Kind / source familyのcoverage matrixを持つ。固定1 sourceをGlobal coverageと呼ばない。
  • Discoveryに第三者sourceを使ってよいが、Critical ClaimのVerificationは原則公式sourceへ戻す。
5.4 Daily operation
  • 毎日一度以上、世界供給の再調査を実行する。固定seedの再読込ではない。
  • due sourceをlease付きで取得
  • cursor / ETag / Last-Modifiedで差分取得
  • raw responseをimmutable snapshotへ保存
  • candidate抽出
  • entity resolution / dedupe
  • new / existing / ambiguous / rejected / failedへ分類
  • newはREGISTER、existingはchange candidate、ambiguousはReviewへ送る
  • official sourceでVerification
  • publication gate
  • search index / sitemap / structured data更新
  • watch match / notification
  • ledger、cost、latency、failure、next run保存
  • missed runはcatch-upする。重複実行しても冪等である。複数instanceでも二重登録・二重通知しない。
  • raw itemはcandidate / duplicate / excluded / pending / published / failedへ一意に突合し、candidate outcomeは最低限new / existing / unchanged / changed / rejected / failed / deferred / unprocessedを区別する。source未取得、pagination途中停止、fixture空結果を新規0件の成功にしない。resource上限で止める場合は永続backlogとresume cursorへ残す。
  • source disableには理由、影響範囲、再開条件、Verifier承認を保存する。Terms / robots違反を避けるためのpauseは必要だが、Gate回避のためのsource削除は禁止する。
6. 画面・UI surface inventory — Authorityを混同しない
  • 画面要件を次の三層に分ける。三層とも今回の実装対象だが、すべてを「正本§4.6に列挙された画面」と報告してはならない。
6.1 正本§4.6が明記する7画面
  • 正本ai-service-intelligence-registry-canonical-v0.5.md:1208-1220の列挙を、そのまま保持する。
  • Search — 自然言語で目的を入力
  • Results — 結果数、Candidate Set、条件一致・除外理由
  • Entity Detail — Summary / Detail、Capability、Evidence、Freshness、Status / Risk、型別Metadata
  • Compare — 同一Kindを原則とする条件別比較
  • My Stack / Watch — 使用中Entity、代替・変更監視
  • Universe / Search Scope — 探索範囲と方法論
  • Internal Review — 例外案件のFormal Review Packetと専用判断
  • Internal Reviewは正本の必須運用画面だが、一般ユーザー向けPublic screenではない。role-protected internal surfaceとして実装し、public navigation、sitemap、検索indexから除外する。
  • SearchをAsk / Home、ResultsをConversation / Resultsとして実装することは情報設計上の表現であり、正本の画面を削除・追加したという意味ではない。
6.2 その後の明示USER要件として追加されたPublic画面
  • Explore AI Tools / Registry List — AI Service、Agent Skill、MCP Server、open-source AI toolの全Registryを直接検索・filter・sort・paginateできる独立画面
  • この一覧画面は正本§4.6の7画面に明記されていない。したがって「§4.6に元から書かれていた」と偽ってはならない。一方、今回までのUSER要件で明示的に要求され、Global Registryを利用者が直接確認する正式版画面としてIN_SCOPEになっている。Search / ResultsまたはUniverseへ吸収して削除してはならない。
6.3 正本の機能要件と正式公開運用から必要になるsupport surface
  • 次は§4.6の画面列挙ではないが、該当する正本要件または正式公開production要件を実行可能にするUI / routeである。
  • Login / Sign up / Account — 正本§2.9、§4.7のaccount境界、session、ownership、return flow
  • Methodology — 正本§3.14および§4.5に明記されたMethodology Page
  • Correction / Missing product — 正本§3.11、§4.5、FitGapトリアージで確認された訂正・不足報告
  • Saved / History — 正本§4.7の履歴、お気に入り、保存検索。My Stack / Watchと同一画面内のtabでも独立routeでもよい
  • About / Contact / Terms / Privacy — 正式公開productionのtrust / legal surface。正本§4.6の製品画面ではない
  • support surfaceを独立ページにするか、account / methodology等へ統合するかは情報設計で決めてよい。ただし機能、説明責任、法的導線、到達性を失わせない。
6.4 Non-deletion invariant
  • UI密度を下げる場合、初期表示を簡潔にし、詳細を展開・遷移させる。
  • 正本機能、Evidence、監査情報、Filter、List、Compare、Watchを削除・非表示・到達不能にしてはならない。
  • mobileでは折り畳むが、機能・意味・操作を失わせない。
  • authが必要な操作はloginへ導き、完了後に元の操作へ戻す。単にボタンを消さない。
7. UI実装基準
  • 画像は情報設計と視覚階層の基準であり、完成コードでも固定データでもない。画像内の製品名、件数、日付、割合をhard-codeしない。
7.1 採用する視覚基準
  • outputs/ui-concepts-v2/01-global-chat-first-home.png SHA-256: f0dafa5d2120a261112115852d3044cdb50dcea007a82e64d6b9edd1c17912aa
  • outputs/ui-concepts-v2/02-progressive-results.png SHA-256: ea098d0edfba25e78cc69066a46cbd587f97f2c036d6a43c0b741769bb7a6f49
  • outputs/ui-concepts-v2/03-full-registry-list.png SHA-256: f41b25a7db78520299f8c3404a7f878f6d1c48b22b140f670def910b7139f7f9
  • outputs/ui-concepts/02-registry-explorer.png — advanced evidence / detail densityの補助基準 SHA-256: e6646c4fa64cda9c7f399199e370db72d157dbec9fc1dab714ed9321f0a1276f
  • outputs/ui-concepts/03-compare-watch-responsive.png — Compare / Watch / responsiveの補助基準 SHA-256: 47a9a8509dfd98eb50bc18546c2c872f7a310360fd2094bffcda87a3faff203a
  • 旧01-home-selection-engine.pngは機能の棚卸しにのみ使用し、情報量をそのままHomeへ戻さない。
7.2 Global shell
  • desktop / tablet / mobileで共通header、type scale、spacing、color、focus、button、status semanticsを使う。
  • primary navは利用者タスクに合わせ、例としてAsk / Explore / Methodology。Compareはtrayまたはselection後に出現させる。
  • 保存・Watchはログイン後に明示し、未ログインでは操作時にauthへ接続する。
  • Resultsを固定navへ置かない。
  • My Stackという語を説明なしに使わない。JAは保存・利用中・ウォッチ等、利用者に意味が分かるlabelにする。
  • locale switcherを常に到達可能にし、一画面に二言語を混在させない。
  • Englishは完全な第一級locale。日本語だけを本文、英語だけをnavにする実装は禁止。
7.3 Ask / Home
  • 初回画面は簡潔にする。
  • 一文で価値を伝える: 世界のAI toolsを、根拠付きで探す。
  • 中心は自然言語入力。
  • 例文は最大3件程度。内部debug promptを並べない。
  • Explore all toolsへの明示導線を置く。
  • ロゴをheroの中心に巨大表示しない。
  • entity countは補助情報。固定値・誇大なcoverage率・拡大中免責を置かない。
  • Search Audit、Evidence、Freshnessの価値を短い説明で示す。
7.4 Conversation / Results
  • 会話を通じてRequirement Profileを確認・修正できる。
  • 重要度は正本互換のMUST / PREFER / NOT_REQUIRED / EXCLUDE / UNKNOWN。UI文言を変える場合もこの意味と保存値を変えない。
  • MatchはMATCH / PARTIAL / NO_MATCH / UNKNOWN。
  • 候補カードはWhy、制約、Evidence、last checked、Unknownを簡潔に表示。
  • 詳細は展開またはDetailへ遷移。
  • 検索結果N / 候補として確認Mを同一Search Runから表示。
  • もっと見るでCandidate総数、公式確認済、SLA内、要確認、region / language / source scope、最終探索時刻、除外理由別件数を表示。
  • Candidate全件がevaluated / excluded / errorへ一意分類される。
  • Explore、Compare、Save、Watchへ自然に接続する。
7.5 Explore AI Tools / Registry List — 第一級必須画面
  • この画面を削除、Universeへ吸収、Homeの小さな一覧だけへ縮小してはならない。
  • 必須要素:
  • page titleと、AI Service / MCP / Skill / OSSを世界から探せる説明
  • name、capability、integration、use caseを対象にした検索
  • tabsまたは明確なKind filter: All / AI Services / MCP Servers / Agent Skills / Open-source Tools
  • filters: Use case、Capability、Pricing、Language、Region availability、Integration、Verification、Freshness、Status / Risk、License、Hosting、Auth / Transport、updated time
  • sort: relevance、recently verified、recently changed、name。人気順を根拠なく既定にしない
  • row / compact listを基本とし、最低限Name、Kind、Summary、Verification state、Last checked、Evidence、Compare、Saveを示す
  • Unknown / Partialを色だけでなくtext / icon / accessible labelで示す
  • query、filter、sort、pageをURLへ保持し、share / back / reloadできる
  • server-side paginationまたはcursor。全件DOM描画、固定25件だけ、無限scrollのみは禁止
  • totalはfilter後の実集合と一致
  • 2〜5件のpersistent compare tray
  • row clickとbutton操作を競合させない
  • mobileではfilter drawer、sticky compare tray、意味単位のrow折り畳み
  • empty / error / loading / partial source failureを区別
  • Entity Detail、Correction、Missing product、Methodologyへの導線
  • Listは大量供給を直接探索したい利用者、既知名で探す利用者、検索結果を横断確認したい利用者のために存在する。chat-firstを理由に削除しない。
7.6 Entity Detail
  • canonical name、Kind、Publisher、official URL、availability
  • official-source grounded service_summaryとservice_detail
  • use cases、capabilities、pricing、languages、regions、integrations
  • 型固有metadata
  • Claim-level Evidence、source authority、observed time、Freshness、Unknown / Conflict
  • StatusとRisk Signalを分離
  • Change timeline
  • Compare / Save / Watch / Correction
  • summary generation versionとsource snapshotへの内部trace。内部IDはpublicへ出さない
7.7 Compare
  • List / Results / Detailから2〜5件を追加する。最初に全件checkbox wallを出さない。
  • 同一Kind比較を原則とし、cross-kindは用途比較と明示する。
  • Requirement Profileを行、Entityを列にする。
  • 重要度、値、Match、Why / Why not、Evidence、Freshness、Unknown、差分を表示。
  • Unknownを差異・不合格と断定しない。
  • autocompleteで入替可能。
  • duplicate canonical entityを出さない。
  • WatchへRequirementごと引き継ぐ。
7.8 Universe / Coverage
  • world completeness percentageを捏造しない。
  • Kind × use case × discovery language / region × source familyのcoverage matrix。
  • explored / partial / unexplored / failed、run ID、last success / failure、next run。
  • discovered / registered / public / search eligibleを分ける。
  • verification比率を出す場合、分子・分母・対象field集合・算式を表示。
  • bubble chartは補助のみ。表、検索、filter、drill-downを主にする。
7.9 Saved / Stack / Watch
  • Saved、Currently using、Requirement Watch、Entity Watchを利用者に分かる用語で分離。
  • target、conditions、event types、frequency / channel、statusを表示。
  • edit / pause / resume / delete / history / READ / ACK。
  • pricing、capability、integration、language、status、terms、new alternative、security-sensitive changeを型付きで扱う。
  • watchはRetention Engine。organic rankingやEvidenceの独立性を壊さない。
7.10 Accessibility / responsive
  • keyboardのみでAsk、filter、list、compare、auth、watchを完遂。
  • visible focus、semantic headings、label、error association、status text、contrast。
  • 320 / 375 / 768 / 1024 / 1440 / 1920pxでoverflow、clipping、locale切れなし。
  • reduced motion、touch target、screen reader summary。
8.1 Requirement Profile
  • 自然言語を構造化し、利用者が訂正できる。
  • use case / workflow
  • user / team / company context
  • MUST / PREFER / NOT_REQUIRED / EXCLUDE / UNKNOWN
  • budget / billing unit / currency
  • language / region / data residency
  • integrations / input / output
  • deployment / security / privacy / compliance
  • skill / MCPの場合のclient、runtime、permission、transport、auth
  • user / company type、company size、department、job / purpose、existing tools、required / preferred capabilities、no-code、commercial use、other constraints
  • Profileを保存、再利用、再実行し、前回結果との差分と新規一致を確認できる。Free accountで検索履歴、お気に入り、保存検索、利用中Entity、少数Watchが実動する。
8.2 Hybrid search
  • structured filters
  • keyword / full-text
  • semantic retrieval
  • kind-aware ranking
  • evidence / freshness / availability gate
  • deterministic post-filter
  • semantic index revision / embedding model versionをRegistry revisionへ結び、keyword非一致の同義語queryでsemantic経路が候補生成へ寄与することを証明する。semantic停止・index不整合時はHybridと表示せずGateをFAILにする。
  • 正本の六用途群、JA / EN、全Kind、exclusion、Unknown、非AI専業だがAI機能が重要な製品を含む約100件の代表query benchmarkをVerifierが事前freezeする。各queryに重要候補、許容候補、明確な誤混入、MUST条件、Unknown期待を持たせ、expectedを現行production outputから生成しない。
  • commercial契約、vendor verification、sponsorshipでorganic順位を変えない。Sponsoredを将来実装する場合も明確に分離する。
8.3 Search Audit
  • 各Search Runへ保存する。
  • normalized query / locale / timestamp
  • Requirement Profile version
  • registry snapshot / index version
  • search space / source scope
  • candidate IDs
  • filter / retrieval / rerank version
  • evaluated / excluded / error partition
  • exclusion reasons
  • results and score components
  • Evidence / Freshness state
  • Search Confidence signal
  • trace ID
  • Search Confidenceはクリック数だけではない。「十分な候補を確認できたか」、再検索、他には?、外部再検索、Compare / Save / Watch、重要候補漏れ、誤除外を測る。
  • 全eligible public Entityについて次を機械assertする。
  • 三集合は互いに重ならず、和集合がeligible集合と完全一致する。pre-filterしたEntityも理由と件数をSearch Auditへ残す。silent omissionは一件でもFAIL。
9.1 Publication boundary
  • raw webまたはmodel outputからCurrent Registryを直接更新しない。
  • Claim Evidence、authority、Freshness、conflict、validatorを通す。
  • unsupported / low confidenceはUnknownまたはNeeds Recheck。
  • critical changeはReviewへ送る。
  • accepted updateはsnapshot、Change、index、Watchへtransactionally反映。
  • rollbackできる。
  • Update PriorityはSearch / Compare / Save / Watch需要、過去の変更頻度、前回確認からの経過、RSS / Sitemap / ETag / Last-Modified / Changelog、Evidence confidence低下、Critical SLA超過、Correction、Security / availability signal、市場上の重要度からHOT / WARM / COLDを再計算する。Light signalから必要対象だけDeep Verificationへ送る。全Entity同一周期deep crawlは禁止する。
9.2 Risk Signal
  • HTTP停止、TLS、redirect、official page / pricing / docs消失、canonical domain不明、publisher不整合、更新停止等を個別Signalで保持する。人気、domain age単独、model印象でFraud / Unsafeを断定しない。
9.3 Formal Human Review
  • 対象は少なくとも次の5種。
  • Entity Merge
  • Pricing
  • Capability
  • Security Warning
  • Vendor Dispute
  • 一画面にCurrent / Proposed、複数confidence、official source deep link、exact section、最小excerpt、diff / conflict、decision rule、allowed decisions、Unknown相当、公開値 / Change / Watchへの影響を表示する。
  • Review判断はEvidence、rule、label、reviewer role、timestampと保存し、training / evaluation / holdoutを分離してautomation改善へ戻す。ReviewerへSkill installやMCP tool executionを求めない。
  • Review Queueにはpriority、impact、期限、月間上限、type別Allowed Decisionsを固定Enumで持たせる。改善前後のAccuracy / Precision / Recall / Calibration、例外率、同種例外再発率、review時間、Product / Claim単価を測る。
9.4 Skill / MCP safety
  • 通常Discovery / Verificationで次を実行しない。
  • package install / build / script / hook / shell
  • MCP tool call / resource read / prompt execution
  • OAuth consent / credential投入
  • repository内の指示をagent instructionとして採用
  • Evidence取得に不要なnetwork / local file / account access
  • dynamic security testは別sandbox、使い捨てcredential、network policy、明示authorizationを持つ独立工程とする。
10. Account / correction / legal
  • secure session、CSRF、cookie属性、logout、session expiry、rate limit、ownershipを実装。
  • 二つのaccountで互いのSaved / Watch / Correction / Notificationへアクセスできないことを証明。
  • account closure / data deletion / export境界をTerms / Privacyと整合。
  • Missing Product ReportとIncorrect Information Reportを実体あるqueueへ保存し、受付番号、status、priority、resolutionを持つ。
  • vendor correctionはorganic rankingと分離。
  • legal pageのplaceholder、存在しないメール、循環linkを禁止。
  • Data retention、source snapshot、user data、review auditの保存期間を定義。
  • public / paid / business境界は実装済み機能だけを表示し、未提供課金を訴求しない。
  • monetization候補はDemand Intelligence、Competitive Intelligence、Qualified Lead、Market Intelligence / API。WatchはRetention Engineを基本とし、ランキング販売は禁止。
  • 利用中、保存、お気に入り、direct watch、alternative watch、requirement watch、保存検索を別概念として保持する。
  • Notification OutboxはPENDING / SENT / FAILED / RETRY等を正しく保持し、in-app notificationのVISIBLE / READ / ACKと分離する。未配信をSENTにしない。
  • Correctionはvendor identity、submitted Evidence、Current Evidence、decision、historyを持ち、正本にない「通常3営業日以内」等の固定SLAを勝手に約束しない。
  • legal文面は実在運営主体、連絡先、法域、承認者、承認時刻、公開versionと結び、架空情報を生成しない。Privacy / deletion、Correction、Vendor dispute、takedownを別request typeで追跡する。
10.1 Crawler / application safety
  • robots / Terms、per-host throttle、timeout、size / MIME、redirect先再検査、private IP / metadata endpoint拒否、DNS rebind対策、denylist / kill switch、JS隔離。
  • Retry-After、conditional request、admin / task auth、direct origin bypass防止。
  • dependency / container vulnerability scan、SBOM、severity gate。
  • Skill / MCPのparserがlibraryやnative extension経由でcode executionしないOS-level isolationまたは構造的fail-closed。
  • security / abuse / privacy連絡先を公開し、実在性を確認する。
10.2 Unit Economics / Observability
  • Product単価、Claim単価、有用検索単価、Watch / notification単価をproduction telemetryから測定する。
  • 分子、分母、通貨、集計期間、billing / resource source、欠測処理、有用検索の定義をAcceptance lock時に固定する。
  • source別成功率、records、candidate outcome、queue lag、retry、dead-letter、fetch / model costを観測する。
  • human escalation rate、同種例外再発率、Watch match / delivery outcomeを観測する。
  • 定数、fixture、根拠のない0、欠測を実測値としない。0円ならinvoice / resource telemetryと処理量で証明する。
  • spend guard、queue alert、scheduler heartbeat / failure alertを実動させる。
14. 固定Release Gates
  • Gate名と意味を途中で変えない。A〜HがすべてPASSしなければ「完了」と報告しない。
Gate B — Global supply
  • static seedではないlive source adapters
  • Service / Skill / MCP / OSSのsource coverage
  • 二連続scheduled daily run成功
  • cursor / dedupe / retry / catch-up / next run
  • new / existing / ambiguous / rejected / failed outcome
  • coverage matrixとledgerがproduction UI / APIで一致
  • raw item / candidate outcome集合一致、unprocessed backlog可視化
Gate C — Registry truth
  • target domain migrations適用
  • entity identity / cross-kind rejection
  • claim Evidence / field Freshness / Unknown / Conflict
  • snapshot / typed Change / Risk
  • summary / detail grounding
  • public DTO allowlist、internal leak 0
Gate D — Selection / Search / List / Compare
  • chat Requirement Profile五値
  • Hybrid search
  • Result / Candidate集合整合
  • Why / Why not / もっと見る
  • full Explore Listの全filter / sort / pagination / URL state
  • 2〜5 Compare、duplicate 0、Unknown semantics
  • representative global JA / EN query benchmark
  • semantic index / model / Registry revision整合、約100 query回帰
Gate E — Account / Watch closure
  • login / signup / logout / expiry / return flow
  • two-account ownership isolation
  • Save / Stack / Watch CRUD
  • Change / new Entity→match→outbox→in-app→READ / ACK
  • duplicate notification 0
Gate F — Complete UX
  • 正本§4.6のPublic 6画面とrole-protected Internal Reviewが、それぞれ正しい権限で到達可能
  • USER authorityの完全なExplore AI Tools / Registry Listが到達可能
  • account / methodology / correction / saved / legalのsupport surfaceが機能として到達可能
  • Home簡潔、List完全、Universe監査可能、Compare非checkbox wall
  • JA / EN一言語完結
  • six viewport visual / interaction tests
  • keyboard / screen reader / contrast / error states
  • required feature deletion 0
Gate G — Trust / Legal / GEO / Safety
  • Methodology正確
  • Correction / Missing product実体
  • Terms / Privacy / About / Contact placeholder 0
  • canonical / hreflang / metadata / JSON-LD / sitemap集合一致
  • AI crawlerが引用可能なEvidence / updated time / methodology
  • SSRF、redirect、robots、rate limit
  • Skill install / MCP execution 0
  • review role protection
  • source / queue / cost / escalation observabilityとalert
Gate H — One production truth
  • migration head一致
  • deployment ID / image digest / Git SHA対応
  • cache purge後production再取得
  • API / Home count / List / Search / sitemap / JSON-LDのpublic Entity集合一致
  • backup / restore / rollback / incident drill
  • A〜G artifact hash valid
  • deadline met
17. 完成の定義
  • 完成とは、見た目が改善したことでも、件数が増えたことでも、7/8 Gateでもない。
  • 世界供給を継続発見するRegistry、監査可能なSelection、完全なList / Detail / Compare / Universe、Evidence / Freshness / Change / Unknown、Account / Watch / Notification、例外Human Review、Global JA / EN / GEO、非ゲーム化された全要件Acceptanceが、最終main SHAの同一production deploymentで一体として動作し、Authorityの全IN_SCOPE clauseとGate A〜Hが証拠付きでPASSした状態。
  • この状態以外を「全実装完了」と報告してはならない。