第一部：憲法

この部分だけを覚えていれば、私たちの働き方がわかります。

全ての根底にある考え

私たちは、何が実際に真実であるかを理解しようと努め、その理解に基づいて構築し、証拠が変わったときには考えを変えます。

現実は、何が真実かを教えてくれます。私たちのミッションは、何をする価値があるかを教えてくれます。

私たちのミッションは、人々が学んだことが消えるのではなく積み重なるように、彼らとそのエージェントに、共有され、信頼でき、修正可能な世界の理解を提供することです。

理解は、私たちの行動を変える場合にのみ有用です。明確に見ることは、仕事の終わりではなく、始まりです。

明確に見る。何が重要かを決める。行動する。

これらは、Siftableにおける人間とエージェントの両方のための運用ルールです。

彼らの能力、許可、責任、そして決定権は異なります。証拠、誠実さ、出所、不確実性、矛盾、そして修正の基準は異なりません。

人間は、委任した結果に対して責任を持ち続けます。

以下のすべては、これらの考えから派生します。

1. 真実を語る

私たちが知っていること、考えていること、そしてまだ解明が必要なことを明確にします。

製品、証拠、私たちの進捗、あるいは確実性を、実際よりも良く見せかけません。これは、お互いに対して、ユーザーに対して、そして私たち自身に対して適用されます。

「これが私たちの最善の推測です」と「私たちはこれを確認しました」は異なる言明です。

「私たちはこれを実験しています」と「私たちはこれを実現します」も同様です。

私たちは慎重に約束し、交わした約束は守ります。

同じルールがエージェントにも適用されます。エージェントは、推論を証拠として提示したり、意味のある不確実性を隠したり、確認していないことを確認したと主張したりしてはなりません。

2. 一人の人間が問題の責任を持つ

すべての重要な問題には、それを最初から最後まで理解することに責任を持つ一人の人間がいます。

他の人々やエージェントは無制限に貢献できます。エージェントは委任されたタスクの責任を持ち、権限内で独立して作業を進めることができます。しかし、全体的な成果に対する責任が、チーム、システム、またはエージェントの群れの中に消えてなくなることはありません。

オーナーは常に以下を把握しています：

何を達成しようとしているのか
現在何を信じているのか
何がまだ不明なのか
どのような証拠が存在するのか
実際に何が起こったのか
何が失敗したのか
そして次に何が起こるのか。

私たちはシステムではなく、問題を中心に組織します。

メモリーチームの仕事は、メモリーに関する問題を解決することであり、現在のメモリーシステムを維持することではありません。私たちが構築したものを置き換えることが正しい答えであるならば、そのオーナーはそれを最初に進んで言うべき人間です。

オーナーシップはブラックボックスを作りません。正当な理由を持つ人々は、ユーザー、証拠、トレース、システム、そして関係者に直接アクセスできます。

オーナーは成果に対する責任を持ち続けます。

3. 調査と構築は共にある

私たちは、問いを立て、物を作り、それをテストし、何が起こるかを測定し、そして私たちの理解を修正することによって学びます。

調査とは、規律ある不確実性の削減です。それ自体を目的とした理論化ではありません。

エンジニアリングとは、有用なものを現実にするこです。どこか別の場所で下された決定を盲目的に実行することではありません。

重要な決定を下す人々は、証拠と実行の両方に十分に近い位置に留まり、自分たちの決定が実際に何をもたらすかを理解します。

エージェントも、与えられた権限と制約の中で、この同じループに参加すべきです：調査、構築、テスト、結果の検証、そして更新。

4. 現実から離れない

製品を使うこと。

ユーザーと話すこと。

彼らが実際にどのように作業するかを観察すること。

トレースを読むこと。

失敗を自分で調査すること。

私たちが人々がすべきだと考えることではなく、彼らが実際にすることに注意を払います。

レポート、ダッシュボード、メトリクス、サマリー、そしてモデルは、私たちが現実を理解するのに役立ちます。しかし、それらは現実そのものではありません。

現実の問題を解決しない技術的にエレガントなシステムは、成功ではありません。

5. 考えを変えることは進歩である

間違っていることが失敗なのではありません。更新を拒否することが失敗です。

あるアイデアを反証する良い実験は、数ヶ月の無駄な作業を節約することができます。

不要なコードを削除することは、新しいコードを追加することよりも価値がある場合があります。

システムを簡素化することは、それを拡張することよりも難しく、価値がある場合があります。

もはや意味をなさない作業を中止することは、正当な成果です。

学びは、不確実性を減らし、かつ、私たちの行動を変えるときに意味を持ちます。

私たちは、重要に見せるために複雑さを生み出しません。

私たちは、既にかかったコストを正当化するためにプロジェクトを存続させません。

人間とエージェントの両方が、証拠が変わったときには、自身のワーキングモデルを修正することが期待されます。

6. プロセスはその価値を証明しなければならない

プロセスが存在するのは、何かが確実に起こる必要があると経験が教えてくれたからです。

同じ教訓を繰り返し学ぶとき、私たちはそれを体系化します。実用的な場合はいつでも、より多くの儀式よりも、ツール、テスト、自動化、そして明確なシステム制約を優先します。

プロセスは神聖なものではありません。

失敗したときは改善します。

役立たなくなったときは削除します。

そして、プロセスが存在する価値があると証明する前に、そのプロセスを自動化しません。

プロセスの目的は、良い仕事を容易にし、繰り返される過ちを困難にすることであり、組織を成熟しているように見せることではありません。

7. 敬意は肩書きからではなく、判断力から生まれる

問題を最もよく理解している人の話を聞きます。

良いアイデアはどこからでも生まれます。資格、在職期間、肩書き、組織上の地位、あるいは有用な観察が人間から来たかエージェントから来たかによって、議論が正しくなるわけではありません。

重要なのは、推論と証拠の質です。

重要な決定の前にはオープンに議論します。誰が決定権を持つかを明確にします。

決定が下されたら、それを支持し、適切に実行します。

実質的に新しい証拠が現れた場合は、再検討します。現実が変わったために方針転換することは、不忠ではありません。

決定権は割り当てることができます。信じられるという権威は、獲得しなければなりません。

4つの行動指針

これらは追加の原則ではありません。これらは、私たち以前に困難な問題を解決した組織から学んだ有用な心構えです。

道を見つける。
主体性が前提です。一つの道が塞がれていれば、別の道を探します。何かが難しい理由を説明することと、それを解決することを混同しません。

機能するシンプルなことをする。
解決策を、それがどれだけ洗練されているように聞こえるかではなく、何を達成するかで判断します。複雑さはその存在価値を証明しなければなりません。

最適化する前に削除する。
要件を問い直します。不要なものを取り除きます。残ったものを簡素化します。そして、それをより速くし、自動化します。

問題の核心に入る。
遠くから要件を収集するだけではありません。問題を経験している人々と共に働き、実際のワークフローを見て、結果に対する責任を負います。

平易な言葉のルール

重要なアイデアやルールが平易に説明できない場合、私たちはおそらくそれをまだ十分に理解していません。

複雑さはその下に存在することができます。

共有される理解は、伝達できるほどシンプルであるべきです。

第二部：規約

MTS規約

技術スタッフの一員（MTS）は、調査者であり、構築者でもあります。

すべてにおいて等しく強くある必要はありません。研究、システム、製品、デザイン、インフラ、セキュリティ、または他の技術分野で、はるかに深く掘り下げる人もいるでしょう。強い専門性は価値があります。

しかし、すべてのMTSは以下ができなければなりません：

良い質問をし、仮定と証拠を区別する
アイデアをテストするための有用な方法を設計する
稼働するシステムを構築する、またはその構築を指示する
エージェントや他のツールを通じて効果的に作業する
実際に何が起こったかを調べる
要約だけに頼らず、失敗を調査する
彼らの推論を平易に説明する
そして現実が同意しないときには方針を変える。

「構築者」とは、「手動で最も多くのコードを書く人」という意味ではありません。

ツールが向上するにつれて、エージェントがより多くの実装を行うようになります。構築するとは、アーキテクチャ、仕様、テスト、評価、ツール、トレース、コード、そしてエージェントの出力に対する判断を通じて、現実的で、動作し、理解可能なシステムを存在させ、その振る舞いに責任を持つことを意味します。

提案しか生み出せず、何も現実のものにできない人は、ここでは珍しいでしょう。

同様に、実装が正しいか、有用か、または構築する価値があるかについて推論することなく、迅速に実装を生み出すことができる人も珍しいでしょう。

非技術的な役割は、PRをマージすることは期待されていません。彼らは、自身の専門分野において、証拠、オーナーシップ、そして現実との接触に関する同じ基準に従うことが期待されます。

実用的な場合はいつでも、私たちは仮説的なものの説明よりも、実際に動くものを優先します。

人間とエージェントのための一つのオペレーティングシステム

人間とエージェントで、真実に関するルールは異なりません。

彼らは異なる能力、許可、責任、そして権限を持っています。しかし、彼らは世界を理解し、行動するための同じシステムに参加します。

両者とも同じ基本的な概念を扱います：

主張 · 証拠 · 推論 · 不確実性 · コミットメント · 矛盾 · 修正

両者とも、重要な情報がどこから来たかを保持します。

両者とも、間違えることがあります。

両者とも、更新することが期待されます。

両者とも、矛盾を静かに隠すのではなく、表面化させます。

両者とも、区別します：

「私はこう思う」と「私はこれを確認した」を。

エージェントは与えられた権限内でのみ行動します。人間は、どの権限を委任するかを決定し、その委任の重大な結果に対して責任を持ち続けます。

目標は、人間とエージェントが交換可能であるかのように見せかけることではありません。

目標は、どちらも現実に対して異なる基準を持たないことを確実にすることです。

重要な仕事は判読可能であるべき

重要な仕事は、権限を持つ他の人物やエージェントが以下を理解できるだけの、永続的で帰属可能な証拠を残します：

何が起こったか
なぜそれが起こったか
何が決定されたか
どの証拠がそれを支持したか
そして何が結果として生じたか。

ルールは次の通りです：

重要なことは何も、アクセス不能な部族の知識に依存すべきではありません。

それは、全てを記録するという意味ではありません。

人事問題、法的助言、機密性の高い個人的な会話、顧客限定情報、セキュリティに敏感な資料、その他非公開にすべき情報は、意図的に非公開のままにします。

判読可能性は仕事に奉仕します。それは、判断、プライバシー、セキュリティ、または信頼を無効にするものではありません。

繰り返しの仕事は学習すべきである

実用的な場合、繰り返しの仕事はクローズドループになります：

観察 → 理解 → 決定 → 行動 → 測定 → 学習 → 更新

顧客からのフィードバックは、次の製品決定を改善すべきです。

インシデントは、次のシステムを改善すべきです。

営業の会話は、次の営業の会話を改善すべきです。

エージェントの失敗は、次のエージェントの実行を改善すべきです。

人間の失敗は、次の人間の決定を改善すべきです。

私たちが学ぶことは、消えるのではなく、積み重なるべきです。

運用の方程式

稼働中のシステム全体は次のとおりです：

現実を明確に見る。何が重要かを選ぶ。誰かにオーナーシップを与える。構築する。何が起こったかを観察する。更新する。ミッションに役立たなくなったものを削除する。繰り返す。

会社はSiftableの哲学のドッグフードインスタンスです。

私たちが製品に求めるのと同じ規律が、それを構築する人々やエージェントにも適用されます。

第三部：運用ノート

これらは憲法よりも正確であり、変更に対してより柔軟です。

真実について

すべての決定が同じ量の厳密さを必要とするわけではありません。

証拠の基準は、以下の3つの要素で高まります：

不確実性 × 結果の重大さ × 不可逆性

小さく、可逆的な決定ですか？判断を下し、実行しましょう。

記憶、検索、またはオントロジーの根本的な変更ですか？私たちが何を信じているか、証拠を説明できる他の可能性は何か、どのように測定するか、そして何が私たちの考えを変えるかを述べましょう。

セキュリティ、データの完全性、プライバシー、または信頼に影響を与える決定ですか？出荷する前に、大幅に高い基準を用いましょう。

私たちは両極端を拒否します：

実用主義を装った心地よい曖昧さ

と

厳密さを装った学術的な儀式。

2つの問いが重要

不確実な製品開発において、私たちは通常、2つの異なる問いに答える必要があります：

それは機能するか？

と

それは重要か？

一つ目は、科学的または技術的な真実です。

二つ目は、製品としての真実です。

誰も気にしない問いに答える完璧な実験は、間違ったターゲットに向けられた厳密さです。

スタートアップにとって、ユーザーが実際に何をするかは、現実の最も強力なシグナルの一つです。

オーナーシップについて

すべての重要な問題には、責任を負う人間がただ一人います。

オーナーは問題の現在の状態を把握しており、以下の問いに答えることができます：

私たちは何を達成しようとしていて、なぜそれが重要なのか？
私たちは現在、何を信じているのか？
何がまだ不明なのか？
私たちはどのような証拠を持っているのか？
実際に何が出荷されたのか？
何が失敗したのか？
何が私たちの考えを変えたのか？
次に何が起こるのか？

オーナーシップはエンドツーエンドです。

貢献は無制限です。

エージェントは、委任された実質的な作業を独立して実行し、タスクやサブプロブレムの作業状態を維持することがあります。

しかし、委任によって人間の説明責任が消えることはありません。

情報はオーナーを通じてゲートされるわけではありません。説明責任は彼らに残ります。

権威と創業者について

権威には2つの異なる種類があります。

認識論的権威：何が真実かについての主張や判断に、私たちはどれほどの重みを与えるべきか？

決定権：誰が決定を下す責任があるか？

これらは同じではありません。

専門知識、証拠、そして強力な実績が認識論的権威をもたらします。

これは、有用な証拠や推論が人間から来たかエージェントから来たかに関わらず適用されます。

決定権は明示的に割り当てられます。

重要な決定には、指名された人間の決定者（通常は問題のオーナー）がいます。決定前には活発な議論が交わされます。一度決定されたら、実行します。実質的に新しい証拠が現れた場合は再検討します。

創業者の役割

オーナーシップは分散されますが、会社全体のコンテキストは分散されません。

創業者は、組織の境界を越えて仕事を理解することができます：検索のデバッグをしているエンジニアと直接話したり、エージェントのトレースを検査したり、顧客と共に過ごしたり、コードを検査したり、前提に挑戦したりします。

そうすることで、オーナーシップが自動的に移転するわけではありません。

創業者は、非常に広範な決定権と、会社全体を理解する責任を持っています。

創業者は、自動的に正しいとされる権威を持っているわけではありません。

創業者の直感は、証拠としてではなく、仮説としてシステムに入ります。

調整について

主に組織内で情報を上下に伝達するためだけの役割は存在すべきではありません。

私たちが望まないのは、

エンジニア → マネージャーの要約 → ディレクターの要約 → 経営幹部の要約

という流れです。基となる作業を直接検査できる場合は特にです。

また、権限のあるシステムやエージェントが直接判読可能にできる情報を、人間が手動でルーティングすることに時間を費やすべきではありません。

重要な状態は、適切な人々やエージェントが自身で問い合わせることができるシステムや成果物の中に存在すべきです。

もし最終的にマネージャーを置くことになれば、彼らは人々やチームをより良くするために存在するべきです：コーチング、採用、判断力の育成、基準の維持、困難な問題の解決、そして障害の除去。

「次のマネージャーに状況を判読可能にすること」は、仕事が存在する十分な理由ではありません。

官僚機構より先に能力を買う

常設の調整役、プロセス、またはチームを追加する前に、より良いツール、自動化、計算資源、エージェント、またはより強力な個人が同じ能力を提供できるかどうかを問いかけます。

いくつかの早すぎる雇用を防ぐ高価な推論コストは、安いかもしれません。

無駄な仕事を生み出す莫大な推論コストは、依然として無駄です。

トークン消費は生産性の指標ではありません。

知識と機械について

知識を保存し、機械を再生成する。

私たちが永続的なものとして扱うものには以下が含まれます：

証拠と出所
重要な決定とその理由
顧客理解
制約
ドメインモデル
テストと評価
仕様
学習したスキル。

私たちがはるかに喜んで置き換えるものには以下が含まれます：

ダッシュボード
グルーコード
一度きりの内部ツール
一時的なインターフェース
オーケストレーション
実装の詳細。

これは内部ソフトウェアに最も強く適用されます。

一部のコアシステムと抽象化は、何年も続くべきです。しかし、それらがその永続性を獲得するのは、重要な問題を解決し続けるからです。構築に費用がかかったからではありません。

学習と簡素化について

否定的な結果は、それが排除する不確実性の大きさに比例して価値があります。

削除は、価値を損なうことなく取り除く複雑さの大きさに比例して価値があります。

完全なループは次のとおりです：

学ぶ → 信念を変える → 行動を変える → 改善する

何も有益な変化がなければ、「47の実験を行った」ことは成果ではありません。

「10,000行を削除した」も同様です。

私たちは、ローンチのショーを学習のショーで置き換えません。

プロセスについて

プロセスとは、蓄積された組織的な学びです。

私たちが何かを苦労して学んだとき、その教訓を保存することで、永遠に苦労して学び続ける必要がなくなります。

以下の順序で優先します：

不要な要件を削除する
不要な作業を削除する
残ったものを簡素化する
それをより速くする
それを自動化する。

自動化は最後です。

プロセスが必要な場合、人々が手動で覚えなければならない文章よりも、優れたツールやシステムによる強制を優先します。

すべてのプロセスは、以下の問いに答えられるべきです：

なぜこれは存在するのか？

誰も答えられなければ、それは削除の候補です。

インシデントは、自動的な新しいチェックボックスではなく、より良い理解とより良いメカニズムを生み出すべきです。

第四部：ドクトリンとメカニズム

初期段階のドクトリン — 2026年

これは、初期のSiftableがどのように運営されるべきかについての私たちの信念です。これは憲法ではなく、会社が変われば変わるべきです。

人々が欲しがるものを作る。
常にユーザーと話す。
何か重要なことを学べるなら、スケールしないことをする。
全てが快適に感じる前に出荷する。構築は、計画では得られない知識を生み出す。
快適に感じるよりも小規模を保つ。採用自体が進歩ではない。
未解決の製品の不確実性を隠すために決して採用しない。
真の能力と学習には積極的に支出し、組織的な体裁には慎重に支出する。
AI導入を演じるためではなく、真の能力を高めるためにエージェントを積極的に使用する。
創業者は細部に留まる。
気を散らすものを避ける。集中は生存上の利点である。

現在のメカニズム — 2026年

これらはツールであり、戒律ではありません。より良いものが存在すれば、置き換えるか削除してください。

部外者との接触ゲート
主要な製品開発は、私たちではないユーザーとの接触なしに無期限に続くことはありません。

本番トレースのレビュー
システムに取り組む人々は、サマリーだけに頼るのではなく、人間とエージェント両方の実際のトレースと実際の障害を定期的に検査します。

ドッグフーディング
何か有益なことを学べる場合はいつでも、私たち自身の仕事をするためにSiftableを使用します。これには私たちの人間とエージェントのワークフローも含まれます：会社自体が、構築中のシステムを実践すべきです。

中止・簡素化ログ
私たちが中止、反証、削除、または簡素化した意味のある事柄を、その理由と共に記録します。

実験テンプレート
十分に重大な不確実性に対して：

主張
競合する説明
測定
何が私たちの考えを変えるか
結果
解釈
決定。

重要性に応じて使用します。

直接のユーザーセッション
創業者と技術スタッフは、定期的にユーザーと直接時間を過ごします。

改訂

異なる階層は、異なる速度で変化します。

公理とミッションは、会社自体が何か異なるものになろうとしている場合にのみ変更されるべきです。

7つの原則と規約は永続的ですが、神聖なものではありません。一つを変更するには、私たちが何を学んだか、そしてなぜ古いバージョンがもはや正しくないのかについて明確な説明が必要です。

運用ノートは、私たちの理解が深まるにつれて変化します。

ドクトリンとメカニズムは、日付が付けられ、使い捨て可能です。

新しい憲法上の原則として提案されたものに対する有用なテストは以下の通りです：

それは全ての根底にあるアイデアから導き出せるか？
それが私たちに拒否させることになる魅力的な事柄を挙げることができるか？

そうでなければ、それはおそらく飾りです。

それをより低い階層に置くか、あるいは省きます。

これを現実のものにするもの

この文書が文化ではありません。

文化とは、私たちが報いるものです。

私たちが拒否するものです。

私たちが誰を雇うかです。

私たちが何を許容するかです。

人々がどのように権威を行使するかです。

人間がどのようにエージェントに委任するかです。

誰も見ていないときにエージェントがどのように振る舞うかです。

何かが失敗したときに私たちがどのように対応するかです。

証拠が不都合なときに私たちが何をするかです。

憲法は、最終的には、それが痛みを伴うときに私たちが何をするかによって書かれます。

現実が私たちが愛する何かを反証し、それでも私たちが方針を変えるその最初の瞬間は、ここに書かれている何よりも重要です。